![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Прошу помощи веб-девелоперского зала
Поставил себе недавно производственную задачку и вот уже неделю сижу обдумываю, никак решиться не могу.
Дано: линуксовая система с жадным до памяти софтом с C++ API.
Надо: прикрутить сверху Web UI поверх Apache, чтобы всё красиво конфигурить, смотреть всякие результаты: таблично и графически, плюс сваять своё подобие портальной системки чтоб уметь строить страницы с наборами своих виджетов.
Вот и думаю - как бы всё это задизайнить правильно и с перспективой? Собственно вопрос архитектуры распадается на два связанных вопроса: 1) на чём писать клиентскую сторону? и 2) на чём писать серверную сторону?
Клиент. Есть большой соблазн взять какой-нибудь ExtJS или Dojo (или SproutCore, или dhtmlx, или SmartClient, или на базе jQueryUI что-то своё) и построить в браузере монолитное веб-приложение со всеми рюшечками. Заманчиво конечно замахнуться на такое ультра-современное решение ибо и HTML5 на пороге, веб-приложения проникают везде и повсюду, да и демки все выглядят захватывающе. Отдельный плюс - серверная компонента сокращается до тоненькой прослойки над C++ API, которую можно написать на чём угодно, хоть на C++ сделать модуль к Апачу. Однако мне кажется что риск слишком велик. Написание приложений на JS - дело относительно молодое, подходы не устоялись, API всё ещё гуляют, плюс зоопарк браузеров просто вразнос пошёл. Опять же - непонятно, где искать JS-программистов соответствующего уровня? (Да даже оценивать JS-программистов - уже задача нетривиальная!) И сколько займёт процесс изучения конкретного выбранного JS-фреймворка, даже если у него такая неплохая документация как у Sencha? В общем, технологически - амбициозно, а вот организационно - всё же рисковано.
Сервер. Здоровая альтернатива - делать всё более-менее традиционно: MVC-фреймворк на сервере, те же jQueryUI или Dojo для оживляжа страниц, и JSON/XML для транспорта. Подводных камней видится гораздо меньше, но проще всё равно не становится. Всё равно надо думать - для начала о серверной платформе. Попробуем решить задачу перебором...
Мне так кажется, что на один бокс сажать Java с другими прожорливыми компонентами - нерационально. Прожорливость + непредсказуемость GC = проблемы. Так что отпадают многочисленные Java-фреймворки (Spring, Stripes, Play, и др.), химерный GWT и JVM-based Scala (Lift) и Groovy (Grails). При всей моей трогательной любви к Perl реальных перспектив у него не вижу ни с Perl5 ни с Perl6 несмотря на Ренессанс, да и TIMTOWTDI в командной разработке не будет помогать. Так что отпадают Catalyst, Mojo, Dancer. PHP сразу нет, потому что дикая эклектика и вообще плохо пахнет. ASP - нет, потому что среда линуксовая и Microsoft сюда тянуть себе дороже.
Насчёт написания веб-компонента на C++ пока не могу даже определиться - сумасшествие это или реальный вариант. Гугление вроде бы выдаёт некоторую информацию, но стоит ли бросаться в этот омут? Наверное всё же - нет.
Итого что у нас остаётся: модный Ruby и кошерный Python. То есть Rails и что-то из Django, Pyramid, TurboGears. Rails я на зуб пробовал - мне понравилось. И общая архитектура, и инструментарий для тестирования, и динамичность сообщества разработчиков. Однако несколько смущает сам Ruby: во-первых, непонятно где искать рубистов, а во-вторых опять же может выйти TIMTOWTDI. Питоновые фреймворки руками не щупал, но верю что там тоже всё должно быть примерно аналогично (и даже более однозначно из-за the python way). Есть правда озабоченность моментом Python 2.x против Python3K... А точнее пока непонятно как сравнивать.
Так что судя по всему, придётся выбирать между Rails, Pyramid и TurboGears. Методом тыка и прототипирования.
Коллеги, веб-девелоперы - скажите своё слово, поделитесь советом, а?
no subject
Делать web-компонент на C++ я бы не стал - неудобно да и опасно. Максимум - сделать себе удобное API поверх существующего, а обрабатывал бы запросы и генерировал HTML на чем-то другом.
no subject
no subject
Если брать ExtJS то на сервере будет вообще простая обработка запроса, работа с базой и возврат json, xml данныех, тут может и Rails лишним быть, я бы посоветовал взять может, что потоньше Sinatra или Padrino, хотя бы попробовать, тесты всё тоже есть и очень просто разобраться, минимум магии. Если уж начнёт расти, то можно думать и о Rails.
no subject
А разве в JS-компонентах есть хорошие способы модуляризации? Поянтно что архитектуру можно выстроить любую. Я про то, что приложение всё равно будет монолитным - раз оно загрузилось, отгрузить неиспользуемые модули всё равно нельзя.
no subject
no subject
(Anonymous) 2011-09-28 10:17 pm (UTC)(link)На данный момент их модуляризация и компонентизация на высоте, так же как help и online demos. У меня заняло всего неделю разобраться со всем и я остался доволен.
На протяжении двух лет пользуемся, особых проблем не было, скорость разработки выросла в 5-6 раз.
no subject
Если критична скорость ввода информации оператором(касир в банке), то лучше отказаться от клиента в барузере. Если не критична, например у телефонные опросы через колцентр, то ExtJS вполне справляется.
Могу порекомендовать контору где работал, они не первый год делают UI на ExtJS.
no subject
no subject
no subject
Мое ламерское имхо
Re: Мое ламерское имхо
Re: Мое ламерское имхо
Аргумент - вроде как перл влёгкую связывается с С++
Ну и на слуху он, лучше собаководы советуют....
Re: Мое ламерское имхо
Re: Мое ламерское имхо
Re: Мое ламерское имхо
PS И питон легче джавы, и руби.
no subject
no subject
no subject
no subject
no subject
Но дело-то скорее в самом перле. Я совершенно не представляю перловое будущее на, скажем, пять лет вперёд. Я не говорю что его нет - я просто не представляю. Язык он красивый, но морально устаревший. А бизнесу хочется предсказуемости.
no subject
no subject
no subject
Туда активно мигрируют с пилонса, и вроде бы на нем же собираются делать TG3.
Плюсы -- оно storage agnostic (используй хоть SQL, хоть zodb, хоть файловую систему), оно в общем template agnostic (там в комплекте chameleon и mako, и отдельными модулями идут jinja2 (django-style) и genshi).
Умеет routing и traversal (и даже оба сразу)
Умеет конфигурить-собирать приложение тремя способами (двумя с половиной на самом деле -- zope style требует отдельного pyramid_zcml потому что слишком много zope.* пакетов тащит)
Ну и там под капотом zope.interfaces и это есть хорошо и правильно.
Минусы -- оно "молодое", поэтому такой большой свалки компонентов как у джанги пока просто не наросло.
no subject
no subject
Сложилось ощущение, что он делался для какого-то внутреннего применения в энтерпрайзе, а потом его почему-то выложили в паблик.
Там очень много внешних библиотек тупо втянуто во внутрь, оно не использует стандартные средства развертывания (virtualenv/buildout), ORM там собственный, готовых компонент нет совсем.
no subject
no subject
У пирамиды их уже десятка полтора два, и это учитывая, что она появилась в глазах широкой публики меньше года назад.
Магия она как раз в zope (ну и некий ее кусок унаследовался пирамидой) -- это context based view lookup.
no subject
no subject