На каком языке(фреймворке) лучше писать бекэнд для сервиса бронирования?
Добрый день,
мы сейчас находимся на стадии разработки сервиса и встал вопрос, на каком языке (фреймворке) лучше писать серверную часть. Тут мнения разделились, многие рекомендуют ruby и рельсы, говоря о том, что много разработчиков можно найти. Кто-то рекомендует джанго и пейтон. Кто-то считает, что лучше не париться и сделать все на php, так как и на нем можно найти хорошие высоконагруженные фреймворки. А кто-то мне даже рекомендовал сделать его на java. От чего зависит, какой язык выбрать для проекта? Соответственно после него буду брифовать и искать кодеров, которые напишут всю серверную часть с админкой.
Спасибо!
FanatPHP: профессиональные знания это и есть дело вкуса, если между машинными кодами и пхп большая разница то между пхп руби и питоном минимальная и полностью зависит от вкуса
183614956: эти отличия в архитектуре могут статься незначительными, в зависимости от задачи. Этот сервис бронирования можно с одинаковым успехом написать как на Python, так на Ruby, хоть на PHP. Поэтому можно сказать, что «дело вкуса» вполне тут применимо, если под этим подразумевается тесное знакомство со своим любимым языком.
Сейчас требования на рынке возросли в 3-4 раза по сравнению с тем что было 2-3 года назад. PUSH-нотификации по вэбсокетам (или comet'у) и в мобильные приложения требуют асинхронности и в случае с PHP / Python / Ruby реализовуются довольно костыльно - прикручивают очереди Celery / Beanstalkd / Gearmand / RabbitMQ. В итоге умирает вертикальное масштабирование решения в рамках одного сервера из-за накладных расходов на коммуникацию. Микросервисную архитектуру стоит внедрять в рамках нескольких машин, и профилировать накладные расходы на коммуникацию.
Также существует очень много проблем с PHP / Python / Ruby / Node.js c долгосрочной поддержкой - слишком часто отваливается обратная совместимость у существующих библиотек и зависимостей. Часто меняется API самой платформы.
Из фреймворков сейчас веселее всего с Play2 / Xitrum / Grails.
У них есть свои недостатки, но они будут шустрее всего остального в десятки,а в случае с рельсами - в сотни, раз.
С Node.js куча проблем.
Опять же там много заморочек с архитектурой - нужно внедрять SOA и CQRS-ES для реактивностей, и это уже не банальное MVC к которому все так привыкли. Подобный подход просто требует TDD/BDD и приёмочных тестов для фронтенда.
Юрий Ярош: Вы еще забыли про Twitter, который переехал с рельс на джаву.
Джава, как мне кажется, это хороший язык для отдельной категории веб-разработки: уберхайлоад. Но, объективно, делать на джаве "очередной интернет-магазин" — это накладно не только с точки зрения времени, но и с точки зрения стоимости разработчиков.
Для проекта, у которого не будет миллионов ДАУ, джанга/рельсы/симфони — это отличный быстрый вариант.
kzlv ну не надо уж так генерализировать - я не вижу особой разницы в сложности разработки ни между rails/django/symfony, не между Typesafe Stack или Grails. Переучивал джангистов на Grails - все остались довольны. Опять же работал со всем - прикрутить scaffolding не проблема. Другое дело что нужно избавится от предрассудка "одна табличка - один СRUD контроллер", и разобраться с DDD и SOA подходами... я вот думал опубликовать статью на хабре, но после комментов к предыдущей как-то передумал.
Юрий Ярош: не хотел бы с вами спорить, потому что я менеджер в основное время и программист-любитель в свободное время, у меня знаний дальше питона и жс нет. Но то, что я встречал на самом хабрахабре и прочих ресурсах, однозначно говорит о том, что development speed у джавы ниже, чем у языков, вроде пхп, и очень-очень ниже, чем у питона и руби.
kzlv имеется ввиду J2EE решения - в них очень много заморочек с организацией бизнесс процессов, и они спроектированы с целью максимально чётких формулировок функционала и разработки по заранее подготовленным спецификациям - там исторически сложилось. В общем нужно сначала писать как хотелось бы что бы код работал, как хотелось бы что бы этот код взаимодействовал с другим... и только потом сам код.
Но MVC оно и в Африке MVC - между фреймворками разница реально минимальна, единственное что отличается так это работа с базой, асинхронности да проверка пользовательских форм.
Объём работы реально почти один и тот же, объём Java кода в 1.5-2 раза больше, но не в случае с Groovy/Scala - там много примочек функционального и динамического программирования как в том же python или ruby.
Юрий Ярош: Самое прямое, MVC это не просто разделение, но и то как эти части взаимодействуют, если вы разберетесь что это на самом деле - тогда вопрос отпадет сам.
Назар Мокринский слова дилетанта: объяснить не могу, но ты тупой и сам ничего не понимаешь.
Если MVC "нет", то о каком шаблоне проектирования идёт речь ? MVP - хорошо подходит для десктопа, а не для вэба - в нём нужно было бы прописывать делегаты для всех сущностей базы, а MVVM является проекцией различных REST API на модель представления информации в браузере.
Берём Play2 - все запросы Stateless, отдельно выделяется модель-вид-контроллер, и создатели обзывают его MVC-фреймворком. Ну так чего же я не понимаю ?
Назар Мокринский: я и не отрицаю что есть 5-7 уточнений MVC для различных задач. В случае с MVC состояние хранится в связке View-Model - так написано в статье, которую вы, наверное, неправильно поняли, а состояние запросов то тут не причем.
Как по мне, уже давно пора слазить в реактивности и CQRS-ES'ом - там MVC и не пахло.
Юрий Ярош: Но свзки View-Model нет в вебе. View - это то, что в браузере, а Model, очевидно, на сервере. И между запросами они не связаны никак. Можно, конечно, нагородить WebSocket-ы, и сделать что-то вроде постоянной связи, но мы же понимаем, что это далеко не то, что имеют ввиду абсолютное большинство фреймворков. Разделение логики и представления - в целом соглашусь, но MVC как такого там нет полноценного.
Я перелез в веб-компоненты для View - теперь оно на самом деле отделено, и связано с исходным HTML который сгенерировал движок чуть больше чем никак.
Назар Мокринский опять же слова дилетанта - прочитайте внимательно статью которую сами мне и предложили. MVC Is Stateful. It only makes sense if the View, as well as the View-Model binding is stateful (so the Model can update the View when it changes)
Представление может быть как и в браузере так и на сервере.
В большинстве MVC проектов, к примеру на том же Symfony, данные загружаются с модели БД или кэша, и передаются как состояние в шаблоны Slim, которые находятся на сервере. Потом всё это отправляется в браузер... а в браузере могут использоваться совсем другие состояния, к примеру, для валидации форм.
В случае с богатым фронтнедом, мобильными приложениями и различными REST API ситуация сложнее - там точно нет MVC. Но не нужно генерализировать это на "весь вэб" и "в вэбе нет MVC" - это бредни из-за недопонимания.
Юрий Ярош: И как написанное вами вписывается в "so the Model can update the View when it changes"? После отправки в браузер всяческая связь теряется, а в случае с PHP процесс, который создал View, вообще умер. Как View в браузере обновит Model, данные которой сейчас в ней? Как раз сложные приложения, которые грузятся со статическим HTML и поднимают WebSocket соединение с сервером и только тогда начинают работу с двухсторонней передачей данных и событий и могут вписаться в эту архитектуру.
Красивее, быстрее, приятнее.
Если вам нужно побыстрому накодить, что-то не красивое то берите пхпи его фреймворки.
Все большие проекты пишутся теперь или на джанге или на рельсах
youtube
instagram
Это, то что сразу в голову пришло, написаны они на джанго, так же большое кол-во проектов на рельсах.
Владимир Боруткин Берём Grails - красиво, в 20 раз быстрее питона, большая часть кода генерируется автоматом.
Пробуйте разные инструменты. В больших конторах с рельсов и питона слазят на Go и J2SE Java - получают прирост производительности в 20-30 раз... Ну не спроста же.
Оправдывать нежелание изучать новые подходы и технологии "приятностью питона" очень глупо.
Да, но сравниваются достаточно непроизводительные подходы для того же Play, у Slick / Anorm много overhead'ов, даже рендер шаблонов на Scala реализован в Play без какого-либо вменяемого кэширования... в дизайне Play3 эти вопросы уже решены, но он выйдет в конце 2015го.
Node.js поддерживать реально сложно - раздувается код, отваливаются зависимости, а отладка вообще полный ад. Возможно порог вхождения у него и ниже, но побочных эффектов просто масса.
По камьюнити сравнивать Play2 и Node.js нельзя, так как node.js - это платформа, а Play2 - фреймворк. И понятное дело что у node.js количество пользователей будет гораздо выше. Node.js можно сравнивать, допустим, со Scala. Если бы Scala нормально утилизировала существующие средства оптимизации байткода, типа Project Graal, то можно было бы производительность сравнивать с каким-то C++, а так приходится только надеяться на "магию" HotSpot'a, да на острый ум Мартина.
Если сравнивать производительность на ресурсоёмких задачах, особенно математических - node.js просто не работает, и не в какое сравнение c JVM решениями не идёт. А копирование с буфера в буфер и на паскале будет быстро работать...
Сомниваюсь что вам придеться обрабатывать по <60 RPS, так шо Django самое лучшее так как им проще делать проекты, разработчиков тоже достаточно, и он расширяем! Его использует quora :)!
Средний
