А чому це технічно неможливо? Що конкретно в HTTP протоколі вам це не дозволяє? Ну і практично www.elastic.co/...urrent/search-search.html.
Ніхто не заважає (окрім деяких проксі серверів) додати body в GET. Заміна GET на POST робить запит не ідемпотентним, а тому, ідеологічно, його не можна ретраїти.
Виходить що не редіс основа цієї архітектури, а кафка. А сам редіс можна замінити чим завгодно, наприклад in-process кешом, кешом на фронтенді...
(365 * 24 * 60) * 0.0001 = 52.56
А що буде, якщо у цей момент впаде редіс ( нехай у вас буде кластер) скільки голосів ви втратите?
Вся біда у цьому світи лежить на стороні баз даних.
Думаю, що все залежить від характеру запитів. Цікаво чим при такого типі навантаження допоможе рідс, голоси там зберігати )
Деякі проблеми вирішуються стандартизацією, але не всі. Срібної кулі не існує, за гнучкість треба платити. Ну і в BFF краще розміщати тільки специфічні для консюмера речі, основна логіка в сервісах/мікросервісах, тоді дублювання буде мінімальним.
З мого досвіду, у таких випадках, краще робити BFF ніж один спільний API. Продукти (та і платформи також), у більшості випадків, рухаються незалежно і дуже зручно коли бекенд рухаеться разом з ними. Також, коли у вас один спільний API, дуже тяжко його оновлювати і деприкейтити, бо у кліентських додатків своєї роботи вистачає.
GraphQL це інструмент, який покликаний вирішити конкретні проблеми компанії, яка його створила. На мою думку, ці проблеми повʼязані з великою кількістю зовнішніх консюмерів з різними потребами. Якщо це ваш кейс, GraphQL гарне рішення. Водночас, якщо у вас
Просте API на Go: 1 файл 0 залежностей, просте API на PHP: фрейворк + тона конфігурації + менеджер процесів + реверс проксі ( fpm + nginx) ...
Варто додати, що gRPC фреймворк має github.com/.../doc/server-reflection.md, що значно спрощує дебаг і має купу інтеграцій ( наприклад з тим же postman). Також він дозволяє гнучко конфігурувати клієнтів зі сторони сервера через наприклад DNS, ретраї, дедлайни і хеджинг.
Якщо за JS на бекенді майбутнє, чому спільнота активно переписує тулзи для білда JS проектів на Rust?
Kubernetes це не про кількість запитів, а про уніфікацію управління додтками.
Це стандартні проблеми всіх кластерів, не буває ідеальних рішень. Кожен обирає для себе сам, чим він буде жертвувати. На рахунок проблем з OLTP, тести покажуть.
Ну зараз набирає обертів NewSQL, який обяцяє і консистентність і доступність і масштабування з коробки. Наприклад ми вирішили потестувати TiDB, він ± гарно прикидується MySQL і поки особливих проблем з ним не було.
Можливо ви додасте контексту, яка саме база даних використовуеться у такій конфігурації? Думаю стаття написана у контексті MySQL/Postgres.
Поки вони будуть це робити, сервіс буде деградувати, а вірогідність такої ситуації у вас x3. Я вже мовчу про бюджетність даного рішення.
Я вас не ображав, але бачу що ви розбираетесь в темі. А що буде коли ваша синхронна репліка (primary standby) почне деградувати, або повністю вийде з ладу?
Згоден, що не всі, але постман не входить в цей перелік. Виберіть GET, перемкніть radio button з позиції ’none’ наприклад в ’raw’.