If you are hiring, use @kotlin_jobs. I am not sure about English though, but you can fill the form anyway.

What was that?

Рано отправил, пайплайн обработки запросов чертовски удобен, с Александром про 30 секунд не соглашусь, это про базовый кейс использования. Разбираться с каждой фичей по доке придется достаточно долго. Например хотите подключить кейклок как авторизационную машину - извольте потрахаться, ибо обычный jwt auth не всегда подойдет

Cant we ask android/kotlin questions?

Only it involves kotlin as a language.

Yes of course, I migrated android/kotlin a while ago from android/java

Хотите быстро - все еще спринг. Хотите большего удовольствия от работы и вовлеченности в процесс не по шаблону спринга - велком ту ктор. Только второй вариант обычно не устраивает работодателя

А что это за процесс, если в общих чертах? В коммерческих проектах на первом месте, конечно, результат в единицу времени, но во внутренних можно было бы попробовать.

Если внутренние не сильно ограничены временем - используйте, это будет лучше любых объяснений в чате)

Ктор идеален для небольших сервисов, где вы не используете всяких монстров типа Hibernate и монструозный DI

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

Кривовато объяснил, но может что-то понятно будет) ессно личное мнение на личном опыте

Грубо говоря, это всегда "знание языка" vs "знание фреймворка". Лично я всегда предпочитаю, чтобы играло первое, а не второе. Потому что знание языка и умение программировать более универсально. Но если надо посадить человека, чтобы он за две недели по шаблону что-то нафигачил, то фреймворк шаблонизировать проще.

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

Ну да. И знания спринга не переносятся на "не-спринг". Ну и использование комбинирования разных библиотек вместо одного кобайна, я думаю, что это плюс. Абстрагируешь интерфейсы и используешь то, что лучше подходит под задачу. Я сейчас участвую в продвижении этой идеологии в SCADA (там такие монструозные комбайны, по сравнению с которыми Спинг - ажурная конструкция). Идет туго. Они вообще не знают, как оно внутри работает

Ну я не был бы столь категоричен, я бы скорее сказал - напиши проект на кторе со всеми вытекающими, пойми как работает то что тебе нужно, а потом сэкономь время и возьми спринг

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

Опять же вопрос, что нужно. Если это не hibernate и нет массового использования DI, то спринг не нужен

Да причём тут hibernate - то )  А вот без DI не очень представляю сборку,  кажется что это будет на порядок менее удобно

Вот тут дело привычки. Мне лично очень сложно продираться через все эти DI stub-ы. Я предпочитаю явным образом передавать все параметрами

Для новичка вроде меня и учитывая что мне нужно решить задачу напили 5 простеньких рестов спринг самое то )