Size: a a a

Scala User Group

2020 May 21

Oℕ

Oleg ℕizhnik in Scala User Group
любой
источник

Oℕ

Oleg ℕizhnik in Scala User Group
play на бесплатный амазоновский влезает легко
источник

OS

Oleg Svechkarenko in Scala User Group
Oleg ℕizhnik
play на бесплатный амазоновский влезает легко
Спасибо, посмотрю
источник

Oℕ

Oleg ℕizhnik in Scala User Group
посмотрите
источник

P

Pavel in Scala User Group
Oleg Svechkarenko
Посоветуйте, пожалуйста, бесплатный веб-хостинг, чтобы с play поиграться.
не знаю как сейчас, но раньше на heroku можно было
источник

OS

Oleg Svechkarenko in Scala User Group
Спасибо, Павел
источник

P

Pavel in Scala User Group
пожалуйста
источник

IP

Ilya Petrov in Scala User Group
А подскажите, если делать zio апку с этими ZLayerами, есть две альтернативы: 1-я - засасывать в реализацию сервиса все зависимости и тогда все методы будут иметь тип возвращаемого значения IO[...], 2-я это оставлять зависимости каждого из методов сервиса торчать через R в каждом из типов возвращаемых значений (RIO[Blocking with Clock with Storage with MailClient with...]). Как в итоге лучше идти, 1 подход нравится тем, что апи становится более легковесным - везде IO, но с другой стороны в реализации сервиса появляются те самые поля с зашитыми туда зависимостями, что выгдядит как некий стейт. Второй подход более заумно и функционально так скажем выглядит, но подсознательно хочется видеть как один слой/сервис использует другие и в его апи эти другие слои/сервисы больше не появляются, а получается, что они торчат через R компоненту, как у Волка из "Ну погоди" пальцы из коньков.
источник

Oℕ

Oleg ℕizhnik in Scala User Group
ну очевидно ,что 1-я
источник

Oℕ

Oleg ℕizhnik in Scala User Group
2-я - это протекание абстракций
источник

Oℕ

Oleg ℕizhnik in Scala User Group
если у вас все зависимости торчат в сигнатурах методов, тогда это бессмысленно делать сервисом, это можно просто функциями оставить
источник

Oℕ

Oleg ℕizhnik in Scala User Group
2-й точно не заумный и не функциональный
источник

IP

Ilya Petrov in Scala User Group
Oleg ℕizhnik
2-й точно не заумный и не функциональный
Ок, просто когда своё воял - опирался на это
trait Service {
   def getData: Budget[Seq[CategoryData]]
....
 }
а Budget как раз RIO где R бутерброд из всех зависимостей через with перечисленных. Или это просто так в данном случае получилось?
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Ilya Petrov
Ок, просто когда своё воял - опирался на это
trait Service {
   def getData: Budget[Seq[CategoryData]]
....
 }
а Budget как раз RIO где R бутерброд из всех зависимостей через with перечисленных. Или это просто так в данном случае получилось?
Код для финтех школы намеренно упрощённый.
Там не используется ZIO module pattern никакой версии
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Он был сделан для того, чтобы можно было потом перейти к полноценному модуль паттерну или к тэглесс файналу по желанию
источник

IP

Ilya Petrov in Scala User Group
Oleg ℕizhnik
Код для финтех школы намеренно упрощённый.
Там не используется ZIO module pattern никакой версии
Ок, понял, по жизни использую первый подход и добиваюсь чтобы в сигнатурах не было ничего с R составляющей.
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Ilya Petrov
Ок, понял, по жизни использую первый подход и добиваюсь чтобы в сигнатурах не было ничего с R составляющей.
Это правильно. Код финтех школы принципиально не модуляризированный, вы можете либо выкинуть R из результатов, либо заменить Budget на F. В обоих случаях  вы теряете информацию о реализации.

Но такой подход это просто компромис между подходами с наиболее простой, как мне показалось структурой.

Тэглесс файнал альтернатива есть в той же репе, зио модульную тоже можно написать, но не уверен, что я хочу
источник

KM

Kovalyshev Michail in Scala User Group
А можно спросить пример модуляризированного кода с ZIO?
Я делал для себя простейшие примеры в виде ООП сервисов, но на большее не хватило.
Буду признателен! =)
источник

IP

Ilya Petrov in Scala User Group
Kovalyshev Michail
А можно спросить пример модуляризированного кода с ZIO?
Я делал для себя простейшие примеры в виде ООП сервисов, но на большее не хватило.
Буду признателен! =)
источник

R

Roman in Scala User Group
Ilya Petrov
А подскажите, если делать zio апку с этими ZLayerами, есть две альтернативы: 1-я - засасывать в реализацию сервиса все зависимости и тогда все методы будут иметь тип возвращаемого значения IO[...], 2-я это оставлять зависимости каждого из методов сервиса торчать через R в каждом из типов возвращаемых значений (RIO[Blocking with Clock with Storage with MailClient with...]). Как в итоге лучше идти, 1 подход нравится тем, что апи становится более легковесным - везде IO, но с другой стороны в реализации сервиса появляются те самые поля с зашитыми туда зависимостями, что выгдядит как некий стейт. Второй подход более заумно и функционально так скажем выглядит, но подсознательно хочется видеть как один слой/сервис использует другие и в его апи эти другие слои/сервисы больше не появляются, а получается, что они торчат через R компоненту, как у Волка из "Ну погоди" пальцы из коньков.
И то и то нужно по-моему — если что-то можно в R ZLayer-a, то там ему и место, а какой-нибудь условный RequestContext отлично идет в R методов
источник