Не доводилось с этим чудом инженерной мысли работать, потому не скажу ничего конкретного. Пользуюсь Ktor -- вполне себе всё успешно руками раскладывается на модули в духе тех, которые генерирует даггер на основании задекларированных интерфейсов, без существенного увеличения количества кода, но с заметным повышением наглядности. В том же Android без DI-фреймворка кода рисуется больше, но исключительно за счёт идиотской архитектуры. Присоединяюсь к вопросу, зачем hot replace.

подмена бизнес логики (замена реализации определенного этапа) на основе контекста(тут что угодно, хоть роль пользователя, хоть наличие/отсуствие сессии да и много чего)

ты сможешь поддерживать граф из 50-70 объектов с передачей через параметры конструктора?

вы видимо не бывали в мире кровавого интерпрайза и огромных систем с толстой БЛ?

вы видимо не бывали в мире кровавого интерпрайза и огромных систем с толстой БЛ?

Если зависимостей от тысячи, давно пора рефакторить

Пора рубить на микросервисы (на ktor) ?

С вашим представлением об огромности систем и кровавости ынтерпрайза не знаком, у каждого свои ужасы за душой. хотя озвученное количество узлов графа выше не звучит чем-то заоблачным и страшным. Пока более чем хватало Стратегии, чтобы даже не задумываться о том, чтобы на лету в рантайме пытаться где-то что-то подменять.

стоит просто попробовать :)

ребят, кстати, а вы случаем не тупо CRUD приложения пилите? :)

Здесь большая часть - андроид разрабы, так что да.

блин, надеюсь я тут не один из стариков?

Дедуль, тебе сюда @kotlin_jvm ?

Дедуль, тебе сюда @kotlin_jvm ?

Я пока заметил только аппеляцию к своему невероятному опыту кровавого ынтерпрайза без хотя бы одного объективного примера, почему озвученные подходы считаются незыблемой нормой (разве что за исключением очевидного легаси, которое нельзя взять и переделать, но это явно не ваш аргумент). Конечно, тут у всех только круды, все ходят из бд к клиенту и обратно, только у вас, старичка, тонны нестандартной логики, которые оправдывают озвученное :)

опчему же, батюшка, незыблемой нормой. писать можно по разному. можно колбасить как попало, а можно гибко и расширяемо :)

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

я думаю тут стоит закончить, спор на пустом месте

У нас хаскелист в группе, как-то обсуждали

Я с каналов symfony и angular. Сижу тут потому что рассматриваю котел в качестве API бека для новой платформы. Но пока не очень уверен. Тут в основном ондроед разработчики. А вебы есть?

Я с каналов symfony и angular. Сижу тут потому что рассматриваю котел в качестве API бека для новой платформы. Но пока не очень уверен. Тут в основном ондроед разработчики. А вебы есть?

А какой Фреймворк у вас реализует взаимодействие с клиентом? Спринг? Просто чёто срут на него...

А какой Фреймворк у вас реализует взаимодействие с клиентом? Спринг? Просто чёто срут на него...

Тут проскакивало что ктор для совсем начальных вещей)

срут те кто не понимает/кому не нужна его мощь, им он просто кажется сложным. хрен там с два наваяете на ктор то же что на спринге

А базы у вас как у всех mongo/postgres/mysql?

срут те кто не понимает/кому не нужна его мощь, им он просто кажется сложным. хрен там с два наваяете на ктор то же что на спринге

С докерами тоже все хорошо?

С докерами тоже все хорошо?

Писать бин пост процесоры, не пасибо. Спринг хорошо ложится под определенные задачи которые были заложены в фреймворк

хм, что что? ты везде бин пост процессоры пишешь? тащем?)

хм, что что? ты везде бин пост процессоры пишешь? тащем?)

Любые кишки спринга боль

Меня в документации бомбануло от генерации html- tr { td {} }} - этим же никто не пользуется?

Меня в документации бомбануло от генерации html- tr { td {} }} - этим же никто не пользуется?

NO

Меня в документации бомбануло от генерации html- tr { td {} }} - этим же никто не пользуется?

Ну как. А шаблоны хотя бы? Темплейты...

Любые кишки спринга боль

Мощный аргмент, давай завязывать

Да эм... вроде думал отошли уже от того чтобы в классах HTML генерить. Может чего не понимаю... может фича действительно

Почему обязательно HTML? Это просто шаблоны, как отмечено. Например шаблоны для писем.

Да эм... вроде думал отошли уже от того чтобы в классах HTML генерить. Может чего не понимаю... может фича действительно

Ну меня бомбит от этого))) я привык к twig или blade - когда это вообще отдельный слой - никак не пересекающийся с фреймворком или языком.

Ну меня бомбит от этого))) я привык к twig или blade - когда это вообще отдельный слой - никак не пересекающийся с фреймворком или языком.

Ну это я так конечно. Щас то на сервере генерить хтмл не хорошо. )

не модно уже, да?

DSL быстрее html шаблонов. Если речь идет о каком-то жестко фиксированном html, который никогда не будет изменяться - это супер удобно. Если нужен дополнительный уровень или динамическая генерация, в кторе есть поддержка темплейтных движков: https://ktor.io/features/templates/freemarker.html

шаблонизатор должен быть клиентским, хватит все на сервере генерить

DSL быстрее html шаблонов. Если речь идет о каком-то жестко фиксированном html, который никогда не будет изменяться - это супер удобно. Если нужен дополнительный уровень или динамическая генерация, в кторе есть поддержка темплейтных движков: https://ktor.io/features/templates/freemarker.html

А как быть, когда требуется сформировать отчет, например, финансовый, но при этом требуется скрытие данных? Например, показывать суммарный бюджет, скрывая некоторые пункты?

а что, html dsl не позволяет динамики?

передавать на клиент только нужные данные

Он не позволяет подгружать шаблон в рантайме

Не-нене) Я вот о чем А Б В .. -список сумм, - требуется вывести их в таблице и подбить итог. При этом часть строчек цензурировано.

Не-нене) Я вот о чем А Б В .. -список сумм, - требуется вывести их в таблице и подбить итог. При этом часть строчек цензурировано.