На чем писать бекенд?

Question

[Александр Флоринский]

Всем привет.
Я давно увлекся фронтэндом и на бекенде не писал уже года 2. До этого писал под Битрикс.
Сейчас хочу написать свой проект и нужен бекенд с REST апи.
Подскажите что будет менее затратным по времени и по порогу вхождения ?

Проект не коммерческий, просто для души.

фронтэнд будет на Angular.
Бекенд выбираю из Laravel , Django, RoR

PS
Всем спасибо за ваши мнения и рассуждения.

Answer 1

[Mikhail Osher]

Мы используем Ruby on Rails + AngularJS.
Авторизация на стороне сервера.
Рельсы, в основном, отдают базовый шаблон, и предоставляет API.

Comments

[Юрий Ярош]

А ещё они дохнут при 16K RPS без нормального кэширования, и асинхронности без костылей в них нет ...

[Mikhail Osher]

Юрий Ярош: а еще никто не упоминал псевдо-highload.

[Юрий Ярош]

Mikhail Osher согласен, у кого-то Highload это 50Мбит http трафика (без статики) на приложение :)

Answer 2

[Andrey K]

Все просто. В чем лучше разбираетесь, на том и пишите.

Answer 3

[Юрий Ярош]

Видел 100500 примеров как не надо писать RESTful сервисы.
Главное понимать задачи DataMapper'ов в рамках RESTful сервисов и AAA.
"Одна табличка - один CRUD контроллер с логикой" - путь в никуда.

Из бэкендов сейчас стоит двигать в сторону Typesafe Stack или Groovy Grails, и забыть про этот тупой РНР ширпотреп.

Play2 - прост как дверь, и достаточно быстрый, не без overhead'ов, но и выбирать сейчас особо не с чего :(
Если Scala не является препятствием можно двигать к Xitrum'у, но у него нет энтерпрайсной поддержки.
На Grails оч удобно реализовывать RAD приложения, правда производительность не очень. Но сравнивать можно только с jRuby или jyton'ом.

Python / PHP / Ruby / Node.js не подходят для реактивных приложений, и долгосрочная поддержка просто сущий ад. В общем рано или поздно приходится пилить Push нотификации и асинхронности и там обычно прикручивают Celery / Gearmand / Benstalk / RabidMQ etc естественно работает это не ахти ввиду накладных расходов на коммуникацию.

p.s. А, да, точно и зачем русским РНР программистам говорить о важности TDD/BDD ?...

Comments

[kazmiruk]

Юрий Ярош: ничего не имею против typesafe, сам в него последнее время влюблен, но все таки мне кажется, что Вы не правы. Play2 на scala еще не достиг уровня django\ror хоть и идет к этому семимильными шагами. В плане поддержки - код на Play2 по сути состоит из кучи лямбд (если мы о реактивных приложениях), которые в плане поддержки тоже не очень легки. Да, это все можно организовать в более красивый код, но требует значительно больше усилий, чем на django\ror. Ну и про накладные расходы - разница настолько незначительная при реализации сокет сервера на gevent (по сути повторяет логику akka), к примеру, что говорить об этом не стоит (все равно все упрется в операции записи\чтения). А так как вопрос был "Подскажите что будет менее затратным по времени и по порогу вхождения", то play2 сливает моментально django\ror, которые в свою очередь сливают разным пхпшным фреймворкам, на которых можно написать первые "суперсайты" уже после первой статьи "как написать вконтактик за 21 день"

[Юрий Ярош]

kazmiruk
Берём jMeter или Яндекс.Танк, и меряем что где и кого сливает.
По производительности что CPython что Ruby ужасно слоупочны, просто вам видимо не приходилось гонять нагрузочные тесты.

Не знаю мне в Play2 особо всякие методы для Future/Promise типа .forEach() .map() и т.п. не часто были нужны, да и пишу я в основном под Play на Java, больше 2-3 вложенных promise обычно не встречалось. А поддержка сводится к приёмочному, нагрузочному и модульному тестированию, иногда фазингу... она не особо отличается от поддержки проектов на node.js. Это скорее вы просто не привыкли к особенностям тестирования модели актёров.

gevent не повторяет Akka, у неё совсем другая модель передачи сообщений между актёрами, и она скорее похожа на OTP с erlang'a.

В RoR есть нормальный scaffolding, который ведёт к довольно странным костылям, на этом его преимущества заканчиваются. У Django тоже достаточно хорошо развито сообщество, но опять же не ясно как будут обстоять дела с долгосрочной поддержкой.

Накладные расходы на коммуникацию даже между TCP и UNIX сокету - 30 к 1.
Про разницу между монолитной и межпроцессной коммуникацией история вообще умалчивает.
Будете гонять больше 100Мбит трафика на ноду - поймёте о чём я вообще говорю.

Реализуйте реактивный RESTful SOA с CQRS-ES и ААА сервисами - совсем по другому будете смотреть на большинство прикладных задач.

[kazmiruk]

Юрий Ярош: интересно что у Вас за задачи такие, что основные расходы это код на ЯП и подключение к сокету. У меня все проекты упирались в базу. И если перестать гонять нагрузочные тесты на синтетике, то резко значения выравниваются. Ну и я говорил, что сливают не по скорости работы, а по скорости разработки. Долгосрочная поддержка зависит от архитектуры, тестов, качества, что никак не зависит от фреймворка (за некоторым исключением). По поводу OTP - там вообще Behavior-like подход, который ни на akka, ни на gevent не похож. Ну и опять же Вы отвечаете не на вопрос автора, а просто решили устроить холиварчик про "typesafe круче всех"

[Юрий Ярош]

kazmiruk С сокетами накладные расходы на сериализацию/десериализацию и проброс через TCP, избыточный контроль ошибок и т.п. Для больших объёмов трафика это очень критично. БД не является узким местом, так как обычно всё кэшируется в offheap кэш. OTP - это FSM подход, который как раз таки в Akka и реализован в Typed/Untyped актёрах и STM / FSM. Typesafe не круче всех, в нём тоже есть куча оверхедов. Даже по сравнению с Xitrum'ом он во многом ему проигрывает.

[asd111]

Юрий Ярош: А что скажете о Spring MVC и его REST или об использовании JAX для REST ? Я планирую начать изучение Java поэтому интересно узнать какие сейчас тенденции в вебе на Java.

[Юрий Ярош]

asd111: Я вообще не люблю сервлеты - слишком ужасные оверхеды. Если запускать сервлет под Netty - можно получить очень большой прирост производительности по сравнению с jBoss или WebSphere... А так как Spring в целом J2EE ориентированый он мне не оч нравится. По поводу JAX-RS на Jersey или Spring Data могу сказать одно - это не DDD. Мне нравится DDD подход так как он способствует построению SOA - берём модельку БД и по её схеме получаем доступ через специальный абстрагированный DataMapper, в итоге один достаточно большой сервис - на любое количество таблиц, который принимает правила авторизации и валидации, хотя часть правил валидации можно генерировать по схеме БД. Также этот сервис предоставляет callback'и и интерфейсы для реализации учёта и аутентификации. Потом можно отправлять JSON-WSP или JSON-Schema в браузер, для автоматического построения формочек и автоматического построения браузерной валидации в богатом фронтэнде ... А так по "классике" у нас получается "одна табличка - один CRUD контроллер", которые потом при большой БД в 50-60 табличек ещё потом как-то нужно поддерживать, и не факт что выползут побочные эффекты или опечатки от вагонов копипасты.

Этот подход сформировался у меня в процессе работы с реактивными приложениями и был реализован в рамках нескольких больших проектов. Очень хорошо зарекомендовал себя при работе с очень большими схемами БД - порядка 80-100 табличек. Сейчас хочу опубликовать под OpenSource для РНР / Java / Golang / Python и отдельно написать статейку на хабр "RESTful Services - you're doing it wrong".

[Tyranron]

Юрий Ярош: с нетерпением ждем и статьи, и публикации либ/примеров/сниппетов. Очень интересно глянуть и пощупать после Ваших слов.

[Юрий Ярош]

Tyranron нужно писать статьи что бы американцы их на американский переводили, а не так как сейчас... один ширпотрёп да дилетантство повсюду - только и умеют что потреблять чужие продукты.

Answer 4

[FanatPHP]

что будет менее затратным по времени и по порогу вхождения ?

ничего

Answer 5

[Максим Васильев]

Есть www.django-rest-framework.org
Создание CRUD API можно зачастую свести к нескольким строчкам:

class FooSerializer(serializers.ModelSerializer):
    class Meta:
        model = Foo

class FooViewSet(ModelViewSet):
    queryset = Foo.objects.all()
    serializer_class = FooSerializer

Comments

[mihailos]

Это в models.py?

[Максим Васильев]

нет

Answer 6

[Илья]

На golang, если кроме RESTful ничего не будет. По скорости работы делает всё вами перечисленное в разы. Но правда батареек мало.

Answer 7

[_ _]

Посмотрите на Grape, API-centric фреймворк для руби.

Answer 8

[Randewoo]

Мог бы посоветовать Lua, при грамотной оптимизации кода и настроек сервера дает очень уж хороший результат.