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

Question

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

Моя команда ищет систему, которая (в порядке приоритета):

1. Хорошо документировано
   • В идеале с хорошими учебными пособиями, процветающим сообществом и базой знаний
2. Следует рациональным шаблонам проектирования
   • В основном мы хотим последовательности в рамках. Соглашения об именах, которые не меняются в зависимости от вызова метода, который вы вызываете.
3. Secure
   • Сосредоточена на , заставляя разработчика выполнить некоторую форму проверки переменных GET, POST, PUT и DELETE
4. Стабильный
   • Частично это зрелость, в том смысле, что структура не меняется слишком часто
   • Другая часть - это хорошо документированный список ошибок, который не очень велик
5. Масштабируемый / Ориентированный на производительность
   • У нас более 50 000 пользователей, которым требуется значительная высокая доступность по всему миру. Если наше приложение не работает, люди не имеют интернет в своем доме. Так что это очень критическая среда.
   • В идеале мы могли бы запустить одну и ту же кодовую базу на 10 серверах и просто продолжать добавлять балансировщики нагрузки. Мы не хотим определять, какой сервер и на каких методах ....
6. Хорошо интегрируется с Linux / MySQL.
   • У нас нет ни одного MS-сервера. Мы не меняем это. Извините фанаты .Net: -D

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

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

Answer 1

Я пойду на ветку и предложу Руби с Синатра .

Почему?

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Синатра будет поддерживать Ruby 1.9. Я до сих пор не совсем уверен, насколько сильна поддержка 1.9 в настоящее время в Синатре, но я знаю, что они изначально ждали на 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 поможет вам.

Answer 2

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

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

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

Answer 3

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

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

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

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

PS: Кстати, Seaside не RESTful.

Answer 4

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

Answer 5

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

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

Answer 6

Для ответа 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 лет спустя.

Answer 7

Попробуйте cppcms

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

Answer 8

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

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

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

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

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

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

Answer 9

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

Теперь оттуда действительно желанным ....

Answer 10

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

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

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