Вопросы к эволюции или почему REST стал везде доминировать

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Всем Привет, В двух темах по REST я неоднократно высказывал свое мнение, что REST как и любой RPC, не является хорошей зрелой технологией для получения\синхронизации данных. Там мы частично обсуждали темы про GraphQL и Service Bus, которые являются более зрелыми технологии для обеспечения внутресетевых коммуникаций между программным кодом. Там меня просили оформить свои мысли в отдельную тему. В какой-то момент, я хотел скопировать банальный длинный список приимуществ со своих преведущих сообщений в других темах, но потом подумал, что всеже мы упускаем суть.

Пинать RPC (и его современное подобие в лице REST) не будет только ленивый. Он зарождался в 50е годы на мейнфреймах, как только между компьютерами появилось сетевое взаимодействие. И первая мысль конечно была, "о ребята, а давайте теперь дергать методы у компонент так, как будто они у нас на одной машине"©. Ну на одной машине и на одной машине, про латенси, ретрай, консистенси, бродкастинг, маршалинг, горизонтальное масштабирование, изменчивость контрактов и версионность, профилирование и многие другие проблемы, которые совершенно внезапно возникают когда ваши компоненты больше не живут в одном адрессном пространстве процесса, тогда конечно никто не думал. Так и повелось.

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

И я скопирую свой пост из соседней темы:

Предоположим у нас есть 100 тыс клиентов базы данных, которые запускают тяжелые запросы по центральной базе данных, на основе какого-то SELECT ... FROM ... WHERE. Причем этот SELECT ... FROM ... WHERE у каждого клиента свой, индивидуальный.
Можно ли центральную базу данных написать так, чтобы клиенты вместо того, чтобы каждый раз дергать SELECT ... FROM ... WHERE на базе, просто подписывались (subscription) на изменения данных и сервер просто досылал новые данные которые подпадают под запрос клиента. Причем сервер не выполняет (!) запрос заново, он идет по более короткому пути, анализируя изменения на таблицах и может обрабатывать сотни тысяч подписчиков одновременно.
Соответственно клиенты сервера не только не выполняют SELECT ... FROM ... WHERE на каждый рефреш они еще и получают данные асинхронно, как только они изменились на сервере.

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

Сейчас я понимаю что такой механизм построить реально. Это полностью инвертирует понимание, _как_ может строится взаимодействие между клиентом и сервером.

Воощем как говорил когдато Булгаков устами Воланда.
"Люди как люди, такие же как и были, просто их испортил квартирный вопрос"©
Можно перефразировать на программирование. Программирование как программирование, такое же как и было, синхронизация данных испортило современное программирование.
Возможно удасться это починить.

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

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

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

Дискасс ?