(TL; DR ... извините!)
Я работаю над проектом, очень похожим на G-WAN. Изначально я писал сервлеты API, которые работали достаточно хорошо, но не использовали все возможности G-WAN. С некоторыми указателями из поддержки G-WAN я начал изучать использование обработчиков; Я перенес свои сервлеты API в процедуру перезаписи URL в обработчике (подавляющая часть контента, возвращаемого для запроса API, является статическим / предварительно обработанным контентом). Сейчас я работаю над процедурой 404-обработчика, чтобы отлавливать случаи, когда у нас (еще) нет предварительно обработанного контента, превращая их в запросы рендеринга по требованию и динамически выстраивая ответ.
Со стороны клиента все выглядит полностью динамично. Но, выполняя перезапись URL-адресов на статические пути и позволяя G-WAN отправлять наши запросы по запросу, это сокращает объем кода, который нам нужно написать, И использует некоторые высокооптимизированные функции в G-WAN. Я упоминаю эти детали как пример того, что Гил назвал «ломкой стереотипов». Первоначально наш подход выглядел очень похоже на реализацию с nginx (за исключением того, что нам не нужен был такой шлюз, как fcgi). Это было значительным улучшением, когда мы отказались от требований и отказались от многих предположений о том, как должны быть созданы веб-сервисы.
Одно предостережение, если вы планируете заниматься разработкой на C ++. Связь G-WAN с внешними библиотеками осуществляется на «C», а не на «C ++». Они сделали это из соображений производительности и занимаемой памяти (хороший выбор), но я не думал об этом полностью, когда начал писать некоторые библиотечные подпрограммы на C ++, на которые я намеревался ссылаться из своих сервлетов и обработчиков G-WAN в дополнение к тому, что ссылки из различных приложений C ++. Это не шедевр - множество библиотек "C", которые прекрасно работают с приложениями C ++. Но было бы обременительно ссылаться на динамическую библиотеку классов C ++ (.so) через связь «C» через G-WAN из сервлета. (Мое простое решение заключалось в том, чтобы переместить мой «общий» код C ++ в файлы .h и просто включить их в мои обработчики и сервлеты G-WAN, а также в мои приложения C ++. Не чисто, но целесообразно.)
К вашим 5 конкретным пунктам с точки зрения G-WAN:
В зависимости от вашего определения «анализировать» и «необычно» это можно легко сделать на C / C ++ в обработчике протокола, или вы можете использовать внешние библиотеки. Есть несколько способов сделать это асинхронным, либо как отдельные процессы, либо, возможно, просто неблокирующий ввод-вывод, если блокировка является проблемой.
Также легко управляется из обработчика.
То же.
да. :) Зависит от желаемого уровня поддержки. Бесплатно, если вы полагаетесь исключительно на поддержку SO и других сообществ. Мы выбрали недорогую подписку на поддержку, и отзывы превзошли наши ожидания.
Ах, да! Мы подтвердили это в первые дни.
О, и последнее: после того, как вы потратили час или два на написание некоторых сервлетов G-WAN, вам может быть трудно вернуться к другим механизмам веб / приложений / служб. С сервлетами я просто сохраняю свои изменения из редактора и нажимаю обновить в окне браузера, чтобы увидеть новый результат (попробуйте это с реализацией fcgi!). У меня есть несколько экземпляров G-WAN, запущенных на моем сервере (настроенных для разных IP-адресов и номеров портов), поэтому на одном компьютере у меня есть несколько этапов разработки баз кода, а также производственный сервер. Для разработки я запускаю G-WAN в сеансе терминала (не в качестве демона) и могу использовать printf (...) в коде сервлета и обработчика, чтобы увидеть, что происходит на сервере и что происходит в окно моего браузера.
Для получения дополнительной информации:
Удачи!
Кен
person
Kenigmatic
schedule
29.05.2015
