Про роботу · 3 грудня 2016, 22:28 2469

sanchez

Ніша Play Framework

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

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

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

Теми: Java, Play Framework, Scala

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

LinkedIn

Ctrl + Enter

Ctrl + Enter

Зиновьев Дмитрий Java/Scala Backend 17.12.2016 16:49

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

Відповісти

Підтримати

Віталій Шкуренко Software Engineer 05.12.2016 23:49

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

Відповісти

Підтримати

Alexandr Sova Developer 06.12.2016 01:33

если писать на Java , то я бы все таки выбрал Spring

кстати, очень интересно — почему?
~~Так, надо завершать писать в этом трэде, а то получается какой-то Play головного мозга~~

Відповісти

Підтримати

Віталій Шкуренко

Bogdan Shyiak SE or Dev 06.12.2016 10:27

если писать на Java , то я бы все таки выбрал Spring

кстати, очень интересно — почему?

Не правильно поставлен вопрос.
Правильно спрошивать: Почему (С чего бы это) вы решили использовать маргинальную технологию (плей) вместо мейнстрима (спринг)?

Відповісти

Підтримати

Віталій Шкуренко Software Engineer 06.12.2016 11:50

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

функциональное программирование, stateless, async и message driven :

+ работа с акторами, то Play без Scala, все таки вам это не даст, точней даст но не в полном обьемы и прийдется писать намного больше кода.
Что касается Java, то с выбом Spring вы получаете не только фреймоврк, но и огромную инфрастуру для постоения приложений (посмотрите количество spring проектов), да и не мало важно что спринг, считай, стандарт де-факто, и количество разработчиков которые могут на нем писать превышает тех кто знает Play.

Відповісти

Підтримати

Alexandr Sova Developer 06.12.2016 22:40

даст но не в полном обьемы

Может когда-то так и было, но сейчас Java и Scala API уже эквивалентны

прийдется писать намного больше кода

Тоже не совсем согласен. Может кейс приведёте когда на Scala меньше кода чем на Java 8. Тем более сейчас когда появился Javaslang.

Відповісти

Підтримати

Віталій Шкуренко

Віталій Шкуренко Software Engineer 07.12.2016 16:54

Тоже не совсем согласен. Может кейс приведёте когда на 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.

Відповісти

Підтримати

Alexandr Sova Developer 08.12.2016 03:02

Так

kukuruku.co/...es-and-mutual-innovations

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

Відповісти

Підтримати

Віталій Шкуренко

Alexandr Sova Developer 06.12.2016 22:33

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 06.12.2016 23:09

Для бизнеса было критично решать их задачу параллельно и с минимальной платой за эту параллельность

Не правда. Бизнесу на...неинтересно как (технически) вы будете решать задачи. Акка или тредпул, или очереди, или банально поставить солярку и спокойно держать 100500 тредов — это бизнес не интересует.

Я же напарился с сервлет-контейнером и больше не хотелось иметь с ним дело — Play на Netty отлично обходит использование контейнера при той же функциональности.

То есть ответ такой:
Потому что __вы__ захотели попробовать что-то другое.
И при этом вы или осознавали что это проект из серии «написали и забыли», или не осознавали что __бизнесу__ потом прийдется искать людей для поддержки этого проекта (см тред ниже)

Відповісти

Підтримати

Alexandr Sova Developer 07.12.2016 00:11

Не правда.

Почти. Бизнесу действительно в идеале бы заказывать ЧТО а не КАК. Но идеал есть не всегда.
Например от на то время CTO приходит задача:
— Нам нужно на каждый реквест запускать процесс A и получать результат его работы в ответе. Но у процесса A есть особенность: на самом деле это множество процессов A/n. Думаю запускать их последовательно будет долго так что найди параллельное решение. Да такое чтоб по меньше по граблям ходить.
Я: — Yes, sir!
Голый тред пулл — очень много граблей генерит при незнании. Такой враппер над ним как Akka — существенно уменьшает их количество.
С очередями другая проблема — зачастую нужно самим писать подсистему которая узнаёт, а закончилась ли обработка и собирает ответ. В Akka это уже из коробки (это же и есть очереди если взглянуть на мейлбоксы)

банально поставить солярку и спокойно держать 100500 тредов

дорого. И снова таки проблема синхронизации потом этих трэдов. Akka отлично работает на мелких серверах с SE.

То есть ответ такой: Потому что __вы__ захотели попробовать что-то другое.
И при этом вы или осознавали что это проект из серии «написали и забыли», или не осознавали что __бизнесу__ потом прийдется искать людей для поддержки этого проекта (см тред ниже)

Скорее потому что нашёл такой инструмент. Касательно стаффинга — нет, таки не бизнесу а мне. Не искали, решили растить. Но здесь мне повезло — попался парень который умеет и любит учится. За полтора месяца уже стал спокойно выполнять задачи на этом стэке.

Відповісти

Підтримати

Віталій Шкуренко Software Engineer 07.12.2016 17:15

С очередями другая проблема — зачастую нужно самим писать подсистему которая узнаёт, а закончилась ли обработка и собирает ответ. В Akka это уже из коробки (это же и есть очереди если взглянуть на мейлбоксы)

Какие не убедительные причины использовать Akka.
Java’воский ExecutorService в комплекте с CompletableFuture отлично ложится на описание задачи.

Відповісти

Підтримати

Alexandr Sova Developer 08.12.2016 03:09

Не совсем. С

ExecutorService

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

Відповісти

Підтримати

Віталій Шкуренко

Dmitriy Chaban 08.12.2016 09:14

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

Відповісти

Підтримати

Alexandr Sova Developer 08.12.2016 23:16

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

Відповісти

Підтримати

Artem Astafyev Solution Architect в DataArt 05.12.2016 23:21

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

Відповісти

Підтримати

Alexandr Sova Developer 06.12.2016 01:32

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

для простых проектов типа REST+CRUD

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

Відповісти

Підтримати

Artem Astafyev Solution Architect в DataArt 06.12.2016 10:32

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

Відповісти

Підтримати

Alexandr Sova Developer 06.12.2016 22:25

Согласен.

стафинг

и нехватка

людей, которые понимают и любят функциональное программирование, stateless, async и message driven

на сейчас, пожалуй, основные причины которые осанавливают мир web-разработки перед скачком из CRUD и data-driven в Stream и action-driven. А без этого скачка действительно

весь этот стек теряет смысл

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

Відповісти

Підтримати

anonymous 17.12.2016 17:01

но вот PM и заказчик потом бегают с круглыми глазами в поисках знатоков Scala+Play+Akka+Slick+CQRS+ES.

Потому что не хотят вкладываться в обучение. И не умееют удерживать людей. Всему этому любой синьор жава девелопер сможет обучиться менее чем за месяц, особенно если у вас есть знающие люди. Никакого рокет сайенса там нет, если только искусственно не создавать себе сложности с scalaz.

Відповісти

Підтримати

undefined pointer 18.12.2016 08:26

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

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

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

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

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

Відповісти

Підтримати

Olexandr Vovchok 18.12.2016 13:49

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

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

Відповісти

Підтримати

undefined pointer

Artem Astafyev Solution Architect в DataArt 18.12.2016 19:28

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

Відповісти

Підтримати

Alexandr Sova Developer 22.12.2016 02:23

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

Відповісти

Підтримати

Artem Astafyev Solution Architect в DataArt 22.12.2016 10:09

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

Відповісти

Підтримати

Alexandr Sova Developer 05.12.2016 18:04

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

Відповісти

Підтримати

sanchez 05.12.2016 18:23

на то время версия фреймворка была 2.3 — может сейчас что и поменялось

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

Відповісти

Підтримати

Віталій Шкуренко Software Engineer 05.12.2016 23:53

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 04.12.2016 00:02

Цікаво було б почути відповіді з жителів форуму про те, як використовували або використовують Play Framework в продакшені.

Это немного не соотносится с темой:

Ніша Play Framework

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

Відповісти

Підтримати

sanchez 04.12.2016 00:18

Но даже это не убережет вас от необходимости самому писать компоненты которые уже есть под другие инфраструктуры.

а про які компоненти йде мова?

Відповісти

Підтримати

Александр Гринько 04.12.2016 01:13

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

Відповісти

Підтримати

Александр Гринько 03.12.2016 23:25

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

Відповісти

Підтримати

Alexandr Sova Developer 05.12.2016 17:50

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

Відповісти

Підтримати

Александр Гринько

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

Ваша пошта

Не підписуватись