×Закрыть

Ніша Play Framework

Цікаво було б почути відповіді з жителів форуму про те, як використовували або використовують Play Framework в продакшені.
Особливо цікавить наступне: якщо Play + Java, як справи з використанням Ebean в реальних проектах? Чи все-таки краще якийсь Hibernate?

І у випадку Play + Scala, можна спокійно використовувати Slick чи варто придивитись на Anorm?

І ще раз наголошую, що цікаво почути думки тих, хто використовував вище описане в бойових проектах, пачку проектів рівня ’hello, world’ передивився, але конкретних висновків і цифр не знайшов.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Самая свежая тема по Scala))
У меня есть огромное желание перейти на этот язык , и понимаю, что кроме практики ничто не поможет освоить его, думать на нем, решать поставленные задачи. Есть опыт на java, ищу вариант перехода в боевой проект на scala — готов на позицию джуна. Открыт для предложений...заранее ,спс))

Используем Play 2.3/2.4 + Scala + Slick. В целом никаких нареканий нет.
Но если писать на Java , то я бы все таки выбрал Spring.

если писать на Java , то я бы все таки выбрал Spring
кстати, очень интересно — почему?
Так, надо завершать писать в этом трэде, а то получается какой-то Play головного мозга
если писать на Java , то я бы все таки выбрал Spring
кстати, очень интересно — почему?
Не правильно поставлен вопрос.
Правильно спрошивать: Почему (С чего бы это) вы решили использовать маргинальную технологию (плей) вместо мейнстрима (спринг)?

Здесь скорей все таки нужно иммет ввиду для каких целей выбирается технология, и сможет ли она соотвестовать бизнец требованиям. Если нужны такие слова как:

функциональное программирование, stateless, async и message driven :
+ работа с акторами, то Play без Scala, все таки вам это не даст, точней даст но не в полном обьемы и прийдется писать намного больше кода.
Что касается Java, то с выбом Spring вы получаете не только фреймоврк, но и огромную инфрастуру для постоения приложений (посмотрите количество spring проектов), да и не мало важно что спринг, считай, стандарт де-факто, и количество разработчиков которые могут на нем писать превышает тех кто знает Play.
даст но не в полном обьемы
Может когда-то так и было, но сейчас Java и Scala API уже эквивалентны
прийдется писать намного больше кода
Тоже не совсем согласен. Может кейс приведёте когда на Scala меньше кода чем на Java 8. Тем более сейчас когда появился Javaslang.
Тоже не совсем согласен. Может кейс приведёте когда на Scala меньше кода чем на Java 8. Тем более сейчас когда появился Javaslang.
Какое-то странное заявление, с которым явно трудно согласится. Мне даже кажется, что человек который не любит Scala, все равно согласится что хоть с Java 8 синтаксих стал намного лучше, и возможности стали обширней, но до Scala ой как далеко. Первая же ссылка с Google:
kukuruku.co/...es-and-mutual-innovations
При желание, можно привести еще кучу примеров.
Может когда-то так и было, но сейчас Java и Scala API уже эквивалентны
Хорошо. Открываем два репозитория:
— Java: github.com/...lers/AsyncController.java
— Scala: github.com/...ers/AsyncController.scala
Здесь конечно больше в плане удобства использование API, но Scala явно выглядит лучше.

И еще раз повторяюсь, все зависит от требований. И в большинстве случает, большие количество символов все таки лучше, чем поиск разработчиков которые знает технологию X.

Так

kukuruku.co/...es-and-mutual-innovations
ведь подтверждает сказанное — нет такой вещи что можно делать на Scala и нельзя на Java. Да, на Java будет гораздо больше символов, но всё равно того же эффекта добиться можно. Даже DSL — он на Java тоже строится. Да, не такой удобный и красивый как на Scala, да без инфикса, но строится.

Для бизнеса было критично решать их задачу параллельно и с минимальной платой за эту параллельность. (Решается наура через Akka) Общаться с этой подсистемой планировалось через HTTP — нужен был HTTP-frontend. Typesafe (на то время — сейчас Lightbend) предлагали Play как самое удобное решение. Так и получилось.
Я же напарился с сервлет-контейнером и больше не хотелось иметь с ним дело — Play на Netty отлично обходит использование контейнера при той же функциональности.

Для бизнеса было критично решать их задачу параллельно и с минимальной платой за эту параллельность
Не правда. Бизнесу на...неинтересно как (технически) вы будете решать задачи. Акка или тредпул, или очереди, или банально поставить солярку и спокойно держать 100500 тредов — это бизнес не интересует.
Я же напарился с сервлет-контейнером и больше не хотелось иметь с ним дело — Play на Netty отлично обходит использование контейнера при той же функциональности.
То есть ответ такой:
Потому что __вы__ захотели попробовать что-то другое.
И при этом вы или осознавали что это проект из серии «написали и забыли», или не осознавали что __бизнесу__ потом прийдется искать людей для поддержки этого проекта (см тред ниже)
Не правда.
Почти. Бизнесу действительно в идеале бы заказывать ЧТО а не КАК. Но идеал есть не всегда.
Например от на то время CTO приходит задача:
— Нам нужно на каждый реквест запускать процесс A и получать результат его работы в ответе. Но у процесса A есть особенность: на самом деле это множество процессов A/n. Думаю запускать их последовательно будет долго так что найди параллельное решение. Да такое чтоб по меньше по граблям ходить.
Я: — Yes, sir!
Голый тред пулл — очень много граблей генерит при незнании. Такой враппер над ним как Akka — существенно уменьшает их количество.
С очередями другая проблема — зачастую нужно самим писать подсистему которая узнаёт, а закончилась ли обработка и собирает ответ. В Akka это уже из коробки (это же и есть очереди если взглянуть на мейлбоксы)
банально поставить солярку и спокойно держать 100500 тредов
дорого. И снова таки проблема синхронизации потом этих трэдов. Akka отлично работает на мелких серверах с SE.
То есть ответ такой: Потому что __вы__ захотели попробовать что-то другое.
И при этом вы или осознавали что это проект из серии «написали и забыли», или не осознавали что __бизнесу__ потом прийдется искать людей для поддержки этого проекта (см тред ниже)
Скорее потому что нашёл такой инструмент. Касательно стаффинга — нет, таки не бизнесу а мне. Не искали, решили растить. Но здесь мне повезло — попался парень который умеет и любит учится. За полтора месяца уже стал спокойно выполнять задачи на этом стэке.
С очередями другая проблема — зачастую нужно самим писать подсистему которая узнаёт, а закончилась ли обработка и собирает ответ. В Akka это уже из коробки (это же и есть очереди если взглянуть на мейлбоксы)
Какие не убедительные причины использовать Akka.
Java’воский ExecutorService в комплекте с CompletableFuture отлично ложится на описание задачи.

Не совсем. С

ExecutorService
вам придётся самому следить за количеством потоков (не запускать больше ранаблов чем планировали). Akka внутри тоже использует ES, но только после того как система убедилась что в пулле есть место (ранаблов работает меньше чем сконфигурено). До этого месседжи из мейлбокса не вытягиваются, треды не запускаются. Опять таки, с голым ES всё это пришлось бы писать руками.

Для этого же придумали FixedThreadPool, а бенефиты акки как раз лежат немного в другой плоскости.

Скорее newCachedThreadPool потому что с фикседом придётся самому парится с RejectedExecutionException или самому контролировать сколько чего обрабатывать. А так из коробки такой себе микс кэшд, фиксед и ещё и с WorkStealing’ом.
Да, основные бенефиты — горизонтальное масштабирование почти задаром из коробки и вертикальное ну чуть дороже. Очень приятная особенность если работать на нескольких слабых машинках. Но и во внутренней структуре в этой библиотеке есть много того почему можно выбрать её, а не голый стандартный апи.

Play и Hibernate хорошо работают для простых проектов типа REST+CRUD. И то, если команда хорошо понимает что под капотом. Как только начинается что-то более сложное, сразу возникают проблемы. Поэтому Spring+JDBC Template для проектов средней сложности и нагруженности вполне себя оправдывают.

Мне казалось что использовать Play

для простых проектов типа REST+CRUD
это какая-то кастрация. Этот стэк отлично взаимодействует с вещами построенными на CQRS+ES — фреймворк отлично ложится на подобные архитектуры. Используя его как HTTP прослойку к Akka, которая предоставляет транспорт и масштабирование для бизнес логики можно наоборот получить такие гибкие решения которые с современными Spring+Hibernate получить если и возможно то крайне трудно. Модель акторов естественным образом уводит от постоянного навязчивого желания реализовать SOA+AnemicDomainModel, так любимые Spring+Hibernate адептами. А Play без Akka не имеет смысла — для CRUD хватило бы и голого Netty.
Посмотрим что будет в новом спринге когда они реализуют начинания в Reactive Manifesto и Reactive Streams. Хотя и тогда, скорее всего, оверхедом будет пихать EE стэк туда где SE за глаза хватит.

Hibernate по словам многих как вы сказали «адептов» тоже неплохо справляется с ORM. Но вот как только начинаются более-менее серьезные задачи, сразу возникают проблемы. После чего вместо написания бизнес-логики проект превращается в решение проблем Hibernate, особенно, если присутствует джуниорный или даже мидловый состав.
И второй немаловажный момент это стафинг. Девелоперы об этом конечно особо не думают, но вот PM и заказчик потом бегают с круглыми глазами в поисках знатоков Scala+Play+Akka+Slick+CQRS+ES. И не просто знатоков, а людей, которые, как вы сказали, понимают и любят функциональное программирование, stateless, async и message driven :) Иначе весь этот стек теряет смысл.
Я это не раз пережил, поэтому мое мнение, что как бы там ни было, для даже средних проектов лучше использовать мейнстрим.Для небольших проектов и стартапов можно действительно попробовать что-то экзотическое.

Согласен.

стафинг
и нехватка
людей, которые понимают и любят функциональное программирование, stateless, async и message driven
на сейчас, пожалуй, основные причины которые осанавливают мир web-разработки перед скачком из CRUD и data-driven в Stream и action-driven. А без этого скачка действительно
весь этот стек теряет смысл
Может с приходом нового спринга, который Play в этом плане будет только догонять и появится больше людей готовых к таким изменениям.
но вот PM и заказчик потом бегают с круглыми глазами в поисках знатоков Scala+Play+Akka+Slick+CQRS+ES.
Потому что не хотят вкладываться в обучение. И не умееют удерживать людей. Всему этому любой синьор жава девелопер сможет обучиться менее чем за месяц, особенно если у вас есть знающие люди. Никакого рокет сайенса там нет, если только искусственно не создавать себе сложности с scalaz.

Может то он может. Да только нафик синьору это все?

Вот поэтому Скала не стала мейнстримом, трендом, в мире Джава. Как то и я говорил в году 2009.

Перефразируя с учетом того что вы сказали

ЯП для синьоров не имеет перспектив стать популярным не потому что в популяции синьоров меньшинство, а потому что он окажется невостребованным и большинством синьоров.

Ну а Play — обречён тем более. RAD фреймворк для синьйорского ЯП? Абсурд. Потому что, утрировано, RAD фреймворки нужны для формошлепства.

RAD фреймворк для синьйорского ЯП? Абсурд

Это да. Потому во втором плее все на скала и ориентировано. Но тут уже другая проблема — популярность нового языка, которая равна почти нулю. В итоге никто его не учит, потому что нет работы. А откуда возьмется работа, если когда типичный мелкий заказчик рапид языка когда думает о вебе то сразу о пхп. В итоге каким бы пхп не был ... и каким бы новый язык не был няшкой — ничего не поменяется. Именно потому сейчас если делают что то новое авторы популярных вещей то они не берут новое название а берут уже успешное и изменяют его. Так есть с ангуляром, так с асп нетом новым, ну и полагаю еще есть много примеров. Тупость порождает глупый маркетинг и затормаживает прогресс. Жизнь боль :(

Теория красива. А практика печальна. Я тоже так думал на первом проекте. Но реально нужно этим проникнуться и нужно, чтобы это было интересно и перспективно. На практике ничего этого нет.
Насчет того, что не хотят вкладываться в обучение — это мягко выражаясь ошибочное мнение. Любая крупная компания, в том числе и наша, имеет кучу внутренних курсов. И готова вкладывать деньги в обучение, если это себя окупит. Но вот статистика показывает, что ни сами разработчики не хотят эти курсы проходить, ни клиентов особо нет. Вот круг и замыкается.
Если взять тот же Groovy, то на нем действительно может писать любой синьйор, и даже джуниор, причем без всякого обучения. И с течением времени добавлять специфические конструкции. Со Scala такой фокус не пройдет.

Но и снова таки — проблемы стаффинга были бы актуальны если бы под мэйнстрим стэк можно было без особых усилий найти готового спеца. А сколько существует примеров когда вакансии под более чем мэйнстрим стэк не закрываются (не важно, касается ли этот стэк JVM или нет). Тогда единственный выход — учить под себя. А если всё равно учить — не лучше ли тогда выбрать тот инструмент что удобнее не оглядываясь на мэйнстримы?

Эти вакансии не закрываются по другим причинам, а не потому что не могут найти спецов под мейнстрим. А вложить деньги и время в обучение в расчете на то, что может быть когда нибудь появится под это один клиент, думаю решится не каждая компания.

В продакшене юзаю уже длительное время, нарадоваться не могу. Всё stateless, async и message-driven. Пользую и Java и Scala
По persistense — ебеня сразу не понравились (на то время версия фреймворка была 2.3 — может сейчас что и поменялось) так что пользую JPA (из коробки)
Пробовал Slick — идея крайне интересная, но только если не пользовать потом эти обьекты с маппингом напрямую. Т.е. если заморочится то можно получить очень красивую систему в результате. Касательно Anorm — а смысл? Пока не нашёл в чём его преимущество перед JPA, а из Scala Java код юзается на ура.
Как по мне Play имеет смысл юзать если с самого начала понимать что такое и зачем разные тред пуллы и почему блокировать НЕЛЬЗЯ!!!адын Если есть понимание/любовь к функциональному программированию (без него тоже можно, но смысл?) и нет страха перед callback-hell’ом при debug.

на то время версия фреймворка была 2.3 — может сейчас что и поменялось
а на даний момент яка версія? чи не було проблем з переходом на нову версію(backward compatibility)?

— Сейчас 2.5.*
— Мигрировать приходится ручками. Много вещей может сломаться. Для каждой следующей версии, есть туториал по миграции, но даже он не спасает. По личному опыту миграции с 2.3 -> 2.4 потратил около двух дней.

Цікаво було б почути відповіді з жителів форуму про те, як використовували або використовують Play Framework в продакшені.
Это немного не соотносится с темой:
Ніша Play Framework
Ниши у него уже нет, в джава мире, ибо основное его приимущество было в том что «все из коробки», сейчас это предоставляют и spring (spring boot), и JEE (wildfly swarm, dropwizard).
И брать play имеет смысл, только если у вас очень большая экспертиза в нем. Но даже это не убережет вас от необходимости самому писать компоненты которые уже есть под другие инфраструктуры.
Но даже это не убережет вас от необходимости самому писать компоненты которые уже есть под другие инфраструктуры.
а про які компоненти йде мова?

Ну например представь, что заказчик тебе говорит: «Я хочу чтобы seo angularjs сайта было реализовано с помощью сервиса prerender» Ты заходишь на сайт этого сервиса и видишь, что чтобы его подключить, тебе нужно добавить фильтр в web.xml com.github.greengerong.PreRenderSEOFilter.

Работал над серверной частью android приложения. 50000 скачиваний в play маркете. Использовался Play Framework + Java. На мой взгляд, если сервер бы был Spring + Hibernate работать бы было гораздо проще. Пока были типичные REST запросы, всё было нормально. Потом появилась необходимость сделать так, чтобы angularjs сайт индексировался поисковиками. На такую и на другую любую нетипичную задачу стало уходить очень много времени, просто потому, что для спринга уже есть готовые решения проблем, а для Play framework-a нету.

Когда это было? С какой версией Play?

Подписаться на комментарии