Прошу помощи веб-девелоперского зала
Sep. 26th, 2011 01:33 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
recoderПоставил себе недавно производственную задачку и вот уже неделю сижу обдумываю, никак решиться не могу.
Дано: линуксовая система с жадным до памяти софтом с 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. Методом тыка и прототипирования.
Коллеги, веб-девелоперы - скажите своё слово, поделитесь советом, а?
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2011-09-26 06:46 am (UTC)Делать web-компонент на C++ я бы не стал - неудобно да и опасно. Максимум - сделать себе удобное API поверх существующего, а обрабатывал бы запросы и генерировал HTML на чем-то другом.
no subject
Date: 2011-09-26 08:14 am (UTC)Если брать ExtJS то на сервере будет вообще простая обработка запроса, работа с базой и возврат json, xml данныех, тут может и Rails лишним быть, я бы посоветовал взять может, что потоньше Sinatra или Padrino, хотя бы попробовать, тесты всё тоже есть и очень просто разобраться, минимум магии. Если уж начнёт расти, то можно думать и о Rails.
no subject
Date: 2011-09-26 10:09 am (UTC)Если критична скорость ввода информации оператором(касир в банке), то лучше отказаться от клиента в барузере. Если не критична, например у телефонные опросы через колцентр, то ExtJS вполне справляется.
Могу порекомендовать контору где работал, они не первый год делают UI на ExtJS.
Мое ламерское имхо
Date: 2011-09-26 12:46 pm (UTC)Re: Мое ламерское имхо
Date: 2011-09-26 04:29 pm (UTC)Re: Мое ламерское имхо
Date: 2011-09-26 04:30 pm (UTC)no subject
Date: 2011-09-26 04:31 pm (UTC)no subject
Date: 2011-09-26 04:34 pm (UTC)А разве в JS-компонентах есть хорошие способы модуляризации? Поянтно что архитектуру можно выстроить любую. Я про то, что приложение всё равно будет монолитным - раз оно загрузилось, отгрузить неиспользуемые модули всё равно нельзя.
no subject
Date: 2011-09-26 04:35 pm (UTC)no subject
Date: 2011-09-26 04:36 pm (UTC)Re: Мое ламерское имхо
Date: 2011-09-26 04:38 pm (UTC)Re: Мое ламерское имхо
Date: 2011-09-26 05:16 pm (UTC)Аргумент - вроде как перл влёгкую связывается с С++
Ну и на слуху он, лучше собаководы советуют....
no subject
Date: 2011-09-26 05:54 pm (UTC)no subject
Date: 2011-09-26 06:03 pm (UTC)no subject
Date: 2011-09-26 09:40 pm (UTC)no subject
Date: 2011-09-26 09:51 pm (UTC)no subject
Date: 2011-09-26 09:55 pm (UTC)no subject
Date: 2011-09-28 10:17 pm (UTC)На данный момент их модуляризация и компонентизация на высоте, так же как help и online demos. У меня заняло всего неделю разобраться со всем и я остался доволен.
На протяжении двух лет пользуемся, особых проблем не было, скорость разработки выросла в 5-6 раз.
no subject
Date: 2011-09-29 07:27 pm (UTC)no subject
Date: 2011-09-30 03:57 am (UTC)Но дело-то скорее в самом перле. Я совершенно не представляю перловое будущее на, скажем, пять лет вперёд. Я не говорю что его нет - я просто не представляю. Язык он красивый, но морально устаревший. А бизнесу хочется предсказуемости.
Re: Мое ламерское имхо
Date: 2011-10-01 07:52 pm (UTC)PS И питон легче джавы, и руби.
no subject
Date: 2011-10-01 07:55 pm (UTC)no subject
Date: 2011-10-01 07:57 pm (UTC)no subject
Date: 2011-10-01 08:18 pm (UTC)Туда активно мигрируют с пилонса, и вроде бы на нем же собираются делать TG3.
Плюсы -- оно storage agnostic (используй хоть SQL, хоть zodb, хоть файловую систему), оно в общем template agnostic (там в комплекте chameleon и mako, и отдельными модулями идут jinja2 (django-style) и genshi).
Умеет routing и traversal (и даже оба сразу)
Умеет конфигурить-собирать приложение тремя способами (двумя с половиной на самом деле -- zope style требует отдельного pyramid_zcml потому что слишком много zope.* пакетов тащит)
Ну и там под капотом zope.interfaces и это есть хорошо и правильно.
Минусы -- оно "молодое", поэтому такой большой свалки компонентов как у джанги пока просто не наросло.
no subject
Date: 2011-10-06 08:44 pm (UTC)no subject
Date: 2011-10-06 09:04 pm (UTC)Сложилось ощущение, что он делался для какого-то внутреннего применения в энтерпрайзе, а потом его почему-то выложили в паблик.
Там очень много внешних библиотек тупо втянуто во внутрь, оно не использует стандартные средства развертывания (virtualenv/buildout), ORM там собственный, готовых компонент нет совсем.
no subject
Date: 2011-10-06 09:08 pm (UTC)no subject
Date: 2011-10-06 09:14 pm (UTC)У пирамиды их уже десятка полтора два, и это учитывая, что она появилась в глазах широкой публики меньше года назад.
Магия она как раз в zope (ну и некий ее кусок унаследовался пирамидой) -- это context based view lookup.
no subject
Date: 2011-11-27 06:18 am (UTC)no subject
Date: 2011-11-28 03:54 pm (UTC)