ReCoder (recoder) wrote,
ReCoder
recoder

  • Mood:

Прошу помощи веб-девелоперского зала

Поставил себе недавно производственную задачку и вот уже неделю сижу обдумываю, никак решиться не могу.

Дано: линуксовая система с жадным до памяти софтом с 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. Методом тыка и прототипирования.

Коллеги, веб-девелоперы - скажите своё слово, поделитесь советом, а?

coding

Tags: coding
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 30 comments