Кстати, нет. Мы стремимся к тому, что бы сервисы были максимально независимы и могли использоваться по отдельности.
Безусловно, у модулей есть зависимости. Но эти зависимости разделены интерфейсами и могут быть заменены на любую другую реализацию на любом стеке.
То, что нам удобнее разрабатывать на едином стеке внутри одного репозитория, не делает систему монолитом.
Для «коробочного» решения довольно странной идеей является обновление компонентов по одному, но даже если это потребуется, нет никаких препятствий это сделать (пока совместимы интерфейсы).
А в чем, по Вашему мнению заключается «жесткость» наших зависимостей?
В данном случае, вопрос в том, насколько больно будет переводить ваши проекты на другой стек, если это потребуется.
Если это в меру больно - то очень рад за вас. Если внутренний протокол для передачи данных придется реализовывать с костылями - то сочувствую. Если при переходе на другие технологии придется переписывать половину или больше эндпоинтов - сочувствую еще больше.
Всё же я сравниваю с разделением фронта и бэка. На самом деле, с точки зрения разработки, это правда получается дольше. Как минимум, в плане фиксации договоренностей.
GraphQL - отличная альтернатива традиционному подходу с REST запросами. Но придется решать что делать с вебсокетами.
В плане запуска - тоже придется что-то придумывать. Монорепозиторий? Кстати, он решит проблему шаринга интерфейсов. Но потребует дополнительного контроля в плане смешивания кода.
Прошло уже 4 года, а $mol всё ещё не современен. Он из будущего.
Давайте посмотрим уже после того, как он преодолеет отметку "современности", и мы посмотрим на крупные поддерживаемые проекты на нем? Какими темпами они будут развиваться, какие сложности появятся?
И еще я не уверен, что он FullStack. Но тут Вы, наверно, расскажите.
Тут дело не в сложности освоения технологии, а в поиске сотрудников, которые хотят с нею работать.
Точнее в том, что подготовленных людей (которые хотя бы немного с ней работали) крайне мало на рынке. А изучать технологию (пускай даже довольно простую) не все потенциальные кандидаты хотят. Особенно, если по применимости они видят только правки легаси.
Простите, а как принцип присвоения версий влияет на то, о чем вы написали?
Про масштабирование - пожалуйста, перечитайте статью. Там этот момент освящен.
Кстати, нет. Мы стремимся к тому, что бы сервисы были максимально независимы и могли использоваться по отдельности.
Безусловно, у модулей есть зависимости. Но эти зависимости разделены интерфейсами и могут быть заменены на любую другую реализацию на любом стеке.
То, что нам удобнее разрабатывать на едином стеке внутри одного репозитория, не делает систему монолитом.
Для «коробочного» решения довольно странной идеей является обновление компонентов по одному, но даже если это потребуется, нет никаких препятствий это сделать (пока совместимы интерфейсы).
А в чем, по Вашему мнению заключается «жесткость» наших зависимостей?
Спасибо!
У нас все модули в одном репозитории, с NX в качестве «управлятора» ими.
Не хочется ввязываться в спор.
В данном случае, вопрос в том, насколько больно будет переводить ваши проекты на другой стек, если это потребуется.
Если это в меру больно - то очень рад за вас. Если внутренний протокол для передачи данных придется реализовывать с костылями - то сочувствую. Если при переходе на другие технологии придется переписывать половину или больше эндпоинтов - сочувствую еще больше.
В целом, Вы правы.
Как я и писал, fullstack принимает решения за вас. В том числе, архитектурные:
Принципы построения api
Принципы роутинга
Доступность тех или иных вещей на разных этапах
Это делается, в том числе, за счет большего количества зависимостей, которые и реализуют фунционал на более «узком» наборе технологий.
Проблема в том, что рано или поздно технологию придется менять. И в случае fullstack это будет намного больнее, чем для частей по отдельности.
Всё же я сравниваю с разделением фронта и бэка. На самом деле, с точки зрения разработки, это правда получается дольше. Как минимум, в плане фиксации договоренностей.
GraphQL - отличная альтернатива традиционному подходу с REST запросами. Но придется решать что делать с вебсокетами.
В плане запуска - тоже придется что-то придумывать. Монорепозиторий? Кстати, он решит проблему шаринга интерфейсов. Но потребует дополнительного контроля в плане смешивания кода.
Как Вы сами пишете в 2020 году:
Давайте посмотрим уже после того, как он преодолеет отметку "современности", и мы посмотрим на крупные поддерживаемые проекты на нем? Какими темпами они будут развиваться, какие сложности появятся?
И еще я не уверен, что он FullStack. Но тут Вы, наверно, расскажите.
Они все рано или поздно устареют. Есть какой-нибудь контр-пример?
Тут дело не в сложности освоения технологии, а в поиске сотрудников, которые хотят с нею работать.
Точнее в том, что подготовленных людей (которые хотя бы немного с ней работали) крайне мало на рынке. А изучать технологию (пускай даже довольно простую) не все потенциальные кандидаты хотят. Особенно, если по применимости они видят только правки легаси.