Отзывы о различных бэкэндах для GWT - PullRequest
4 голосов
/ 24 марта 2011

Мне нужно переделать существующее приложение, которое использует Pylons (Python) на бэкэнде и GWT на интерфейсе.
В ходе этого редизайна я также могу изменить бэкэнд-систему.
Я пытался прочитать о преимуществах и недостатках различных бэкэнд-систем (Java, Python и т. Д.), Но я был бы благодарен за отзыв сообщества.

Существующее приложение:

Существующее приложение было разработано с GWT 1.5 (теперь работает на 2.1) и является настройкой для нескольких хостов.
Платформа Pylons MVC определяет набор контроллеров / хост-страниц, в которые встроены виджеты GWT («классический сайт»).

Данные хранятся в базе данных MySQL и доступны бэкэнду с помощью SQLAlchemy / Elixir. Связь между сервером и клиентом осуществляется с помощью RequestBuilder (JSON).

Приложение не является типичным бизнес-приложением со сложным функционалом CRUD (транзакции, блокировка и т. Д.) Или сложной системой разрешений (хотя требуется простой ACL).

Приложение используется для визуализации (графики, таблицы) научных данных. Клиентский интерфейс в основном используется для отображения данных в режиме только для чтения. Может быть некоторая функциональность CRUD, но это не основной аспект приложения.
Только подмножество научных данных будет передано на интерфейс клиента, но это подмножество создается из больших наборов данных.
Существующий бэкэнд использует numpy / scipy для чтения данных из db / файлов, создания матриц и их фильтрации.
Количество пользователей, получающих доступ к приложению или использующих его, относительно невелико, но нагрузка на бэкэнд для каждого пользователя / запроса довольно высока, поскольку ему приходится считывать и фильтровать большие наборы данных.

Требования к новой системе:

Я хочу перейти от настройки страницы с несколькими хостами к архитектуре MVP (одна страница хоста).
Таким образом, бэкэнд обслуживает только одну страницу хоста и служит источником данных для вызовов AJAX.
Данные будут по-прежнему храниться в реляционной базе данных (PostgreSQL вместо MySQL).
Будет простой ACL (определяет, кто может видеть, какие данные) и, возможно, некоторая функциональность CRUD (но это не приоритет).
Размер наборов данных будет увеличиваться, поэтому нагрузка на бэкэнд, вероятно, будет выше. Не будет много одновременных запросов, но несколько из них должны быть обработаны бэкэндом быстро. Оборудование (ОЗУ и ЦП) для внутреннего сервера не является проблемой.

Возможные серверные решения:

Python (SQLAlchemy, Pylons или Django):

Преимущества:

  • Быстрое прототипирование.
  • Повторное использование частей существующего приложения
  • Numpy / Scipy для обработки больших наборов данных.

Недостатки:

  • Слабо типизированный язык -> отладка может быть болезненной
  • Связь между сервером и клиентом (разбор JSON или использование сторонних библиотек).
  • Python GIL -> масштабирование с одновременными запросами?
  • Язык сервера (python) <> язык клиента (java)

Java (Hibernate / JPA, Spring и т. Д.)

Преимущества:

  • Один язык для клиента и сервера (Java)
  • «Легче» отлаживать.
  • Связь между сервером и клиентом (RequestFactory, RPC) проще в реализации.
  • Производительность, многопоточность и т. Д.
  • Граф объектов может быть передан (RequestFactory).
  • CRUD "легко" внедрить
  • Многозвенная архитектура (особенности)

Недостатки:

  • Многозвенная архитектура (сложность, требует много настроек)
  • Обработка массивов / матриц (не уверен, есть ли в java подвеска для numpy / scipy).
  • Не все функции используемых слоев / фреймворков веб-приложений Java (слишком много?).

Я не упомянул о каких-либо других внутренних системах (RoR и т. Д.), Потому что я думаю, что эти две системы являются наиболее жизнеспособными для моего варианта использования. Честно говоря, я не новичок в Java, но относительно новый в платформах веб-приложений Java. Я знаю, как обходиться с Pylons, хотя в новой настройке будет использоваться не так много функций Pylons (MVC, шаблоны), потому что они, вероятно, служат только как AJAX-бэкэнд.

Если я использую бэкэнд Java, мне нужно решить, следует ли выполнять RESTful-сервис (и четко отделять клиент от сервера) или использовать RequestFactory (более тесная связь). Нет никаких особых требований для "RESTfulness". В случае бэкэнда Python я бы, вероятно, пошел с бэкэндом RESTful (так как в любом случае я должен позаботиться о взаимодействии клиент / сервер).

Хотя в основном будут отображаться научные данные (не являющиеся частью какого-либо графа объектных объектов), на клиенте также будут отображаться соответствующие метаданные (это будет способствовать RequestFactory).
В случае Python я могу повторно использовать код, который использовался для загрузки и фильтрации научных данных.
В случае Java мне пришлось бы заново реализовать эту часть.

Обе бэкэнд-системы имеют свои преимущества и недостатки. Буду благодарен за любые дальнейшие отзывы.
Может быть, у кого-то есть опыт работы с бэкэндом и / или с этим вариантом использования.

заранее спасибо

1 Ответ

1 голос
/ 24 марта 2011

У нас была та же самая дилемма в прошлом. Я занимался проектированием и созданием системы, которая имела внешний интерфейс GWT и внутренний интерфейс Java (Spring, Hibernate). Некоторые из наших (связанных) систем были построены на Python и Ruby, так что опыт был там, и возник вопрос, такой же, как у вас.

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

Мы использовали RPC, который, как вы упомянули, определенно облегчил реализацию связи с / с. Не могу сказать, что мне это очень понравилось. REST + JSON кажется более правильным и, по крайней мере, создает лучшую развязку между сервером и клиентом. Я полагаю, вам придется решить, исходя из того, ожидаете ли вы, что вам может понадобиться повторно внедрить клиент или сервер в будущем. Если это маловероятно, я бы использовал принцип KISS и, следовательно, RPC, который в данном конкретном случае делает его простым.

Относительно недостатков Java, о которых вы упомянули, я склонен согласиться с принципом (я предпочитаю сам RoR), но не с деталями. Многоуровневая и конфигурируемая архитектура на самом деле не проблема IMO - Spring и Hibernate в наше время достаточно просты. IMO преимущество использования Java между клиентом и сервером в этом проекте превосходит относительную простоту использования python, плюс вы будете вносить сложности в интерфейс (то есть, делая REST по сравнению с нативным RPC).

Я не могу комментировать Numpy / Scipy и любые альтернативы Java. У меня там нет опыта.

...