Чем больше проект и команда, тем больше выхлоп.
В какой-то момент он становится критичным.



Легко и кухонным ножом порезаться :)



Речь не только про изменения. Но и про обычное программирование. Контракт -- это с одной стороны гарантии, с другой по сути документация, интеллисенс и возможность проведения глубокого статического анализа. Сильно легче -- становится.



Переезд на микросервисы решает совсем другие задачи. Какое-то современное тотальное заблуждение, рассматривать микросервисы как средство решения всех проблем в разработке, в языках программирования и т.д. Давайте не будем всерьёз эти заблуждения обсуждать, ладн? ))

Если работаешь с микросервисами, то и программировать не надо. Я понял

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

Я вообще не понимаю, каким боком тут микросервисы в обсуждаемой теме.



С чего бы это? Средства любого языка явно богаче, чем тот же REST.
Да если и так, на основе OpenAPI в ЯП генерируются всё те же интерфейсы, с которыми нужно работать на прикладном уровне.

Это либо попытка самообмана, либо отсутствие опыта и недопонимание.

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

Но почему-то вы притягиваете за уши эти микросервисы сюда. ))

Чем же конкретно нода под это дело подходит лучше, чем Go, C# или что-то ещё? :)



За счёт чего его получается сильно меньше? Откуда такие идеи? ))



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

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




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

Ни в каких проектах микросервисы не решают проблемы ЯП. Никто так не считает из коллег по цеху, в том числе на конференциях и митапах, которые проводят мы и другие компании.

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

crutchmaster,

Должен согласиться, что для небольших веб-сервисов с одной единственной задачей, нода подходит неплохо.

Dart, CoffeeScript,..?

Просто микросервисы решают совершенно другие проблемы.
Но есть ещё такой религиозный подход.

Окрестили, что монолит это всегда при любых раскладах -- плохо, а микросервисы -- хорошо, так как решают вообще все проблемы в разработке и проблемы, существующие в любых концепциях, подходах и даже в ЯП :)



Если говорить именно про GraphQL.

Я вот не знаю как там в других командах и проектах, надеюсь всё с этим GQL хорошо, и он им реально помогает.

Но вот личное наблюдение показывает совершенно обратную картину. В моих проектах не применялось, а на смежных люди страдали. Точнее было так. Руководитель пришёл и говорит, хорошо бы нам внедрить GraphQL, ведь столько хорошего о нём говорят. Разработчики такие, даааа, ураа, класс, давайте. И пошло дело. Проходят неделя за неделей, на каждом митапе вопрос, ну чё там как там, двигается?

Интересно было наблюдать, как искренний интерес и эйфория постепенно сменялась недоумением, затем лёгким раздражением, а в конце уже не выдерживали и говорили. Да-да, вот эту задачу мы пока на РЕСТ сделали, потому что это быстро. Мы потом перепишем на GQL, честно! Обещаем.

Ещё немного, и похоронили в отдельной веточке. Пускали на продакшен, матюкались, откатывали. А проект серьёзный, это не туду какой-то там, паблик апп с огромной посещаемостью по стране.

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

К сожалению любой "единый стандарт", это почти всегда +1 стандарт и ещё больше энтропии :)
По мне так, OpenAPI (swagger), на сегодняшний день -- золотая середина.

И конечно же, с ним тоже не всё гладко, говнеца и там хватает.

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

Всё (почти) вроде решается, но иногда каким-то пипецом.



На верхнем уровне, очень интересная. Не могу не согласиться.



Вот, хороший пример. Вот эта экономия абсолютный фарс. Никто не делает REST интерфейс с заведомо избыточной инфой.

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

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

А для работы с табличными данными, с возможностью ограничения выборки, есть стабильный и быстрый OData.

Ну так это и не нужно. Бек предоставит столько полей, сколько ему нужно, не больше и не меньше. Это хорошо работает, хорошо сопровождается, у тебя конкретный контракт. А не супер-граф, который на самом деле только в теории выглядит красиво, а в реальности собрать его на беке, где может быть куча интеграции, разных условий, сложная политика безопасности и т.д. и т.п. -- овер сложность, которая не нужна. Зачем тратить время и усилия на все 500 полей, из которых нужны десяток, их можно прямо сейчас отдать, а не пилить мега-монстра, который нафиг никому в итоге не нужен.



Вот-вот.

Рекомендую посмотреть на OData. Просто погляди. Это сетевой REST интерфейс, некий аналог SQL. Отлично подходит для табличных данных. Но может и больше. И при этом он хорошо маппится на SQL, и вообще на источники данных, без сложнючих и оверусложнённых прокладок.

Т.е. гибкость именно там, где она нужна.




Проблема в том, что GraphQL к графам как-то мало отношения имеет