С rest-api все хорошо, пока это пара методов и один клиент. Но когда приложение становится большим, с кучей данных и интерфейсов, все становится гораздо хуже. Разработка api замедляется, появляется множество специализированных методов (и нюансов к ним), тоны документации.
Мне нравится концепция, когда к бэку относятся как к медленной асинхронной базе данных и дают доступ выполнять произвольные запросы (GraphQL, по сути sql к обычной БД), где я сам могу выбирать какие данные, в каком объем объеме получать и как их агрировать.
Использовать Google Closure Library и завязаться на их «строгий» код стайл, было очень разумно, для такого крупного проекта. Наверняка это сэкономило кучу денег и времени на реализацию и поддержку веб версии клиента.
Проблема не в модулях в две строчки, а в принципе "зачем писать свой велосипед" доведенным до абсурда, когда внешняя зависимость в проекте по-умолчанию лучше.
#Delsian: Напомнило популярный несколько лет назад ответ на вопрос «Зачем расширять каналы, если имеющихся хватает»:
Исходящую трубу унитаза все видели? Так вот она такая толстая не потому, что траффик большой, а чтобы имеющиеся пики траффика пропускать с максимальной скоростью.
А сейчас они виндовые? Если да, то как в контейнерах запускаете винду?
Мне нравится концепция, когда к бэку относятся как к медленной асинхронной базе данных и дают доступ выполнять произвольные запросы (GraphQL, по сути sql к обычной БД), где я сам могу выбирать какие данные, в каком объем объеме получать и как их агрировать.
Для процессора тоже актуально.
По-моему уже поздновато… тут и без них народа хватает
вот если бы apple разрабатывал интерфейс, было бы занятно посмотреть на него