Что такое хорошо документированная, стабильная, безопасная и масштабируемая структура веб-приложений?

Мы создаем RESTful API для нашей компании, который будет предоставлять XML, JSON и, возможно, другие типы контента.

Моя команда ищет фреймворк, который (в порядке приоритета):

  1. Well Documented
    • Ideally with good tutorials, and a thriving community and knowledgebase
  2. Follows rational design patterns
    • Mostly we want consistency in the framework. Naming conventions that don't change based upon which method call you're calling.
  3. Secure
    • Focused on forcing the developer to perform some form of validation of the GET, POST, PUT and DELETE Variables
  4. Stable
    • Part of this is maturity, in the sense that the framework isn't changing too often
    • Другая часть - это хорошо документированный список ошибок, который не так уж велик.
  5. Scalable/Performance Oriented
    • We have over 50K users who require significant high availability all around the world. IF our App goes down, people do not have internet in their home. So it's a highly critical environment.
    • В идеале мы могли бы запустить ту же кодовую базу на 10 серверах и просто продолжать добавлять балансировщики нагрузки. Мы не хотим определять, какой сервер на каких методах ...
  6. Integrates well with a Linux/MySQL Environment
    • We don't have a single MS server. We're not changing that. Sorry .Net fans :-D

Я понимаю, что это туманная цель. Не будет какой-либо единой структуры, которая удовлетворяла бы всем этим потребностям, на самом деле, вероятно, будет множество, которые удовлетворяли бы их различными способами, формами и формами.

Это не зависит от языка. У нас уже есть опыт работы с PHP, но у нас также есть разработчики, которые никогда в жизни не писали веб-приложения, поэтому изучение Python, Ruby или Java является приемлемым.


web-frameworks language-agnostic
person Zee Spencer    schedule 21.05.2009    source источник
comment
до флеймовой войны. Также wiki.   -  person    schedule 21.05.2009
comment
Этот список в порядке приоритета? Кроме того, как бы вы измерили некоторые из них, например что делает использование выкройки рациональным?   -  person JB King    schedule 21.05.2009
comment
Сильно субъективный / аргументированный и расплывчатый. Ни один серьезный фреймворк каким-то образом не соответствует ни одному из ваших 5 пунктов, иначе он бы (не продолжал) существовать. Намек на RoR или CakePHP полезен, но вам не нужно идти дальше и описывать относительные требования к скорости разработки, производительности приложений, поддержке инструментов и т. Д.   -  person annakata    schedule 21.05.2009
comment
Да, я понимаю, что это довольно субъективно. Позвольте мне дать еще немного предыстории ...   -  person Zee Spencer    schedule 21.05.2009
comment
Это более чем субъективно, это аргументированно.   -  person Daniel A. White    schedule 21.05.2009
comment
Как я могу перефразировать, чтобы быть менее аргументированным? Я не собираюсь начинать драку ... Я избавляюсь от большей части в названии   -  person Zee Spencer    schedule 21.05.2009

Ответы (14)


arrow_upward
5
arrow_downward

Я рискну и предложу Ruby с Sinatra.

Почему?

  1. Синатра не «хорошо документирован», но «хорошо задокументирован». Учитывая, что это намного проще, чем другие фреймворки, не нужно так много документации, и, поскольку он построен на Rack в качестве веб-сервера, он разделяет с ним некоторую общую документацию. Но все, что вам нужно знать, есть на веб-сайте, и он хорошо написан и не содержит ошибок, которые я обнаружил (IE, все в актуальном состоянии).

    Большая часть того, что вам нужно знать, содержится в книге Sinatra, Readme и FAQ. Несмотря на то, что книга находится в стадии разработки, ее содержание очень точное и полезное. А если у вас все еще есть вопросы, загляните в IRC-чат freenode.net # sinatra.

  2. Sinatra может использоваться в методе функциональной логики / маршрутизации или путем переопределения объекта Sinatra :: Application. Вы можете либо использовать, либо разделить свою логику и методы по разным файлам, либо сохранить все в одном. Это все зависит от вас.

  3. Синатра сам по себе в безопасности. Вы ДОЛЖНЫ проверять все переменные, отправленные пользователем, потому что, помимо их анализа и передачи вам, Sinatra не заботится о том, насколько они действительны. Следовательно, вы либо обеспечиваете достоверность своих переменных, либо сожалеете об этом. ;-)

  4. Sinatra не изменилась ни разу за последние четыре месяца, но, безусловно, имела техническое обслуживание и незначительные обновления. Кроме того, я не считаю список ошибок большим или опасным. В нем есть практически все, что мне нужно для создания моих приложений.

  5. Sinatra не обязательно развертывать вместе с Passenger, но ее можно легко настроить для быстрой работы. Если вы используете такие вещи, как Enterprise Ruby и Thin, вы можете использовать прокси для Nginix или LightHTTPd. Если вы взяли два сервера, вы можете сделать один основным (с прокси-сервером и несколькими потоками), а второй - сервером базы данных (с MySQL и несколькими потоками) и отпустить их. Таким образом задачи распределяются по серверам. Это даст вам больше контроля, чем я думаю, Пассажир. (Не говоря уже о лучшей производительности.)

    Я считаю, что Passenger (на Dreamhost) дает относительно низкую производительность по сравнению с запущенными потоками Rack, Mongrel или Thin. Тем не менее, после загрузки приложения реагируют даже в этой среде. Если бы я предсказал это, у вас не было бы проблем с масштабированием приложения, так как вам просто пришлось бы повторно развернуть свой код и перезапустить потоки - ничего, что нельзя было бы поместить в Capistrano.

  6. Ruby для Linux работает быстро, и его не сложно реализовать. MySQL с Ruby достаточно прост, и есть несколько действительно хороших пакетов ORM, таких как ActiveRecord и Продолжение. Синатра не заставит вас выбрать тот, который вы ненавидите.

Помимо ответов на ваши вопросы, у меня есть еще несколько причин.

  1. У Sinatra легкая кривая обучения, и ее очень легко освоить. Самая большая проблема, с которой я столкнулся, заключалась в том, чтобы загрузить его на мой сервер Dreamhost, поскольку Rack была более старой версией, но с версией Rack, поставляемой производителем, проблема исчезла. Если бы я мог, я бы переписал свой последний проект Rails в Sinatra с помощью ActiveRecord, чтобы облегчить себе обслуживание; на это уже было потрачено слишком много усилий.

    Благодаря простоте использования и легкости обучения, я обнаружил, что в Sinatra без генераторов кода я работаю более продуктивно, чем в Rails со всеми генераторами кода. И это о чем-то говорит.

  2. Sinatra поддерживает промежуточное программное обеспечение для Rack, и поэтому очень гибок в том, что вы можете с ним делать.

  3. Если бы я оценил полезность сообщества Sinatra в IRC, я бы сказал, что они более осведомлены о структуре, чем средний пользователь Rails, просто в качестве беглого сравнения. Причина в том, что Rails более доступен для новичков и людей, у которых просто нет бизнес-программирования.

  4. Sinatra будет поддерживать Ruby 1.9. Я все еще не совсем уверен, сколько поддержки 1.9 в настоящее время есть в Sinatra, но я знаю, что они изначально ждали Rack. По состоянию на 25 апреля это не больше проблема, так что предположительно Синатра уже подготовлен к 1.9; Я точно знаю, что поддержка 1.9 находится в стадии разработки в середине 2009 года, но я не знаю, как долго это продлится.

    Предполагая, что вы можете заставить Sinatra работать с Ruby 1.9 с небольшими усилиями (версия 0.9.2 уже поддерживает Rack 1.0 и прокси 1.9 в коде Rack), до общедоступной версии 1.0 с поддержкой 1.9 ваша производительность на стороне Ruby была бы звездной. . Даже если вы не можете этого сделать, Enterprise Ruby поможет скорости.

person Robert K    schedule 22.05.2009
comment
Грр, не могу исправить ссылку. Мое сообщение забивается ОДНОЙ некорректной ссылкой! - person Robert K; 23.05.2009
comment
Недавно я влюбился в Синатру. Спасибо за совет :). Идеально подходит для фреймворков REST! - person Zee Spencer; 05.09.2011

arrow_upward
4
arrow_downward

И Django, и Rails довольно близко подходят к большинству ваших критериев, за исключением того, что я думаю, что документация Django намного лучше, чем у Ruby on Rails '; документация по Django просто потрясающая (и я не преувеличиваю здесь).

Однако я не знаю о масштабируемости Django. Я знаю, что Rails достаточно хорошо масштабируется (до определенного момента), но не знаю, можно ли то же самое сказать о Django. (Я не говорю, что не может; я просто говорю, что честно не знаю, поскольку я никогда не писал большой < / em> приложение с использованием Django.)

У Django также есть пони, на случай, если вы втайне этого тоже захотите.

person mipadi    schedule 21.05.2009
comment
Фактически, масштабируемость Rails широко ставится под сомнение. У Django лучший отчет в этом аспекте; но у любого фреймворка определенно есть «стена» в определенный момент. - person Javier; 21.05.2009
comment
Вот почему я сказал до определенной степени, хотя я думаю, что проблемы масштабируемости Rails преувеличены. Для большинства сайтов, даже больших, это нормально. Проблемы Twitter с Ruby привлекли много внимания, но у Twitter также есть некоторые сумасшедшие внутренние вещи, с которыми не приходится иметь дело большинству сайтов (даже больших). - person mipadi; 21.05.2009
comment
Мы решили пойти с Django, но с CodeIgnitor это было не так. Поддержка сокетов Python и его дизайн как язык для разработки приложений означают, что большая часть нашего другого серверного кода в конечном итоге может быть перенесена на Python, начав процесс стандартизации для перехода на один язык вместо 4+, который у нас есть сейчас. Спасибо вам всем! - person Zee Spencer; 28.05.2009

arrow_upward
3
arrow_downward

Что ж. Масштабируемость получить нелегко. Для времени ответа, подобного Google, вам понадобится что-то вроде MapReduce. В порядке. Не обманывайте себя, супер-масштабируемость - ничто для новичков.

Что касается всех остальных пунктов, очевидно, лучше всего подходит Seaside. Что касается безопасности, посетите Seaside.st, чтобы узнать, почему он по своей сути более безопасен, чем все другие известные мне фреймворки (например, Rails и Seam). Побережье достаточно хорошо задокументировано, но также посмотреть на его внутреннюю часть настолько легко и удобно, что вряд ли у сообщества остается открытым вопрос, на который он может ответить, что обычно делает быстро. Сисайд уже много лет стабилен, так что я думаю, вам это понравится.

Что касается ориентации на производительность: запустите коммерческую Seaside, GLASS, и вы получите потрясающую производительность по сравнению с LAMP- как и установка, благодаря гораздо более быстрому интегрированному решению базы данных, а также структуре, которая жертвует памятью на скорость и получает большую скорость.

Архитектура Seaside настолько удачна, что многим людям проще писать приложения Seaside, чем настольные приложения. Попробуйте, вам понравится.

PS: Для справки, Seaside - это не RESTful.

person nes1983    schedule 21.05.2009

arrow_upward
2
arrow_downward

Вы можете взглянуть на Django, фреймворк Python. Это очень хорошо документированный фреймворк, у него есть автоматический интерфейс администратора CRUD в базе данных, а также есть бесплатная онлайн-книга, которую, конечно, вы можете купить по-настоящему :)

person Patrizio Rullo    schedule 21.05.2009

arrow_upward
1
arrow_downward

Попробуйте их все, чтобы узнать правильный ответ!

Что ж, люди, которые будут предлагать «единый фреймворк, чтобы управлять ими всеми», тоже не испробовали бы их все!

person Neil Trodden    schedule 21.05.2009

arrow_upward
0
arrow_downward

Думаю, если бы такой фреймворк был, он был бы один-единственный.

person Arnis Lapsa    schedule 21.05.2009
comment
Я считаю, что антиголосование жесткое: я согласен с тем, что если бы был четкий выбор, то это был бы четкий выбор. - person annakata; 21.05.2009
comment
Есть вопрос, я дал ответ, в который верю. Я не прошу голосовать "за", но и не вижу смысла голосовать "против" за свой ответ ... :) - person Arnis Lapsa; 21.05.2009
comment
@arnis - я лично считаю, что отрицательные голоса по субъективным темам должны быть отключены, но, к сожалению, это не было сделано через голосование пользователей - person annakata; 21.05.2009
comment
@annakata Вы должны предложить эту идею команде stackoverflow, если вы еще этого не сделали. - person Arnis Lapsa; 21.05.2009

arrow_upward
0
arrow_downward

Что касается PHP, мне понравился фреймворк Zend (хотя для меня это не совсем фреймворк). Одна из его лучших особенностей - то, что каждый компонент не зависит от других ... Так что, если какая-то часть вам не нравится, просто не используйте ее. Также вы упомянули JSON ... Zend полностью поддерживает JSON в обоих направлениях ....

person dicroce    schedule 21.05.2009

arrow_upward
0
arrow_downward

Ruby on Rails широко документирован с множеством плагинов и уже протестирован на масштабируемость (см. BaseCamp и другие решения, созданные на рельсах)

person Konstantinos    schedule 21.05.2009

arrow_upward
0
arrow_downward

Глядя на ваш список приоритетов, трудно сказать, что какой-то один маршрут является «правильным». Что касается PHP, я потратил значительное количество времени на CakePHP, который выполняет многое из того, что вы ищете. Но, будучи парнем, который ненавидит PHP, я бы посоветовал держаться подальше от всего в этой сфере.

Все дело в стиле и опыте. Я использовал Ruby On Rails, не самый элегантный из языков, но он отлично справляется со своей задачей. Он не настолько развит, как использование стека Spring / Hibernate на Java или использование .Net, который обрабатывает почти все прямо из коробки, но выполняет свою работу исключительно хорошо. Я предпочитаю проекты на основе Java / .Net, потому что они намного лучше подходят для того, как я люблю программировать.

Нет "правильного" ответа, только много хороших. Например, ASP.Net MVC - хороший выбор. Всегда назад я использовал Spring на Java, который также довольно эффективно справлялся со своей задачей. Даже PHP - правильный выбор. Ruby On Rails, с которым я работал только над двумя проектами, очень легко освоить, и он делает некоторые довольно сложные задачи на других языках довольно простыми.

person thaBadDawg    schedule 21.05.2009

arrow_upward
0
arrow_downward

Я думаю, что по объему документации вы не сможете превзойти J2EE. Он также считается безумно масштабируемым и стабильным.

Теперь, от того, что действительно желательно ....

person Javier    schedule 21.05.2009

arrow_upward
0
arrow_downward

Если вы рассматриваете Java, я бы порекомендовал Jersey, он отлично работает и, я думаю, достигает всех ваших 5 целей. ..

person adrian.tarau    schedule 21.05.2009

arrow_upward
0
arrow_downward

Если Java есть в вашем наборе инструментов, посмотрите Stripes.

Рок стабильный, полный энтузиазма, хотя и не впечатляюще большое сообщество. Хорошая документация, некоторые устаревшие, но система настолько стабильна, что даже "старые вещи" актуальны. Очень хорошая, недавняя (конец прошлого года) книга. Полосы достаточно малы, чтобы книга могла «покрыть все».

Это структура действий, которая мало что делает в области презентации (в основном, за исключением форм, и имеет полностью необязательную возможность создания шаблонов / макетов). Вы можете использовать JSP, FreeMarker или что-нибудь еще. Он также может выполнять веб-службы (хотя и не так хорошо, как Джерси).

Он не зависит от серверной части, но для него есть проект интеграции с JPA.

Наконец, вы можете использовать, если хотите, весь другой набор Java / Java EE, если хотите. Поскольку Stripes не использует весь стек, у вас есть большая гибкость в выборе нужных вам частей. Полная версия Java EE, транзакции, сессионные компоненты, JMS. Работает со Spring (он «осознает» Spring и имеет хорошую интеграцию) JPA, iBatis, Hibernate, raw JDBC, Lucene, JSR-170 Content Repository, что угодно.

Это отличный комплект.

person Will Hartung    schedule 22.05.2009

arrow_upward
0
arrow_downward

В качестве ответа 2014 года я бы порекомендовал Laravel / Slim Framework (PHP), Ruby on Rails / Sinatra (Ruby), Django / Flask (Python), Grails (Groovy, язык на основе JVM), Play! Framework (Java / Scala) или Sails.js / Kraken.js (Javascript).

Если первый упомянутый фреймворк немного больше, а второй немного меньше для языков, где я упоминаю 2 фреймворка с использованием «/».

Надеюсь, это поможет людям, у которых возникнут похожие вопросы 5 лет спустя.

person Ms01    schedule 10.06.2014

arrow_upward
-1
arrow_downward

Попробуйте cppcms

это высокопроизводительный фреймворк для веб-разработки

person Softmixt    schedule 14.08.2013