Comments 8
Всё делается куда проще:
Клиент создаёт заказ на чашку кофе и сохраняет его в свою локальную БД. Всё, заказ создан, read-your-writes, все дела. Пользователь видит, что заказ есть, но в статусе "идёт передача".
В фоне идёт синхронизация БД. Сеть может обрываться, сервера меняться, клиент перезапускаться, не важно. Когда сервер увидит заказ в статусе "идёт передача", он меняет его статус на "принят" и через ту же синхронизацию об этом узнаёт клиент и другие сервера.
Теперь, даже если клиент переподключится к тому серверу, на котором этого заказа ещё нет, то (благодаря синхронизации) тут же передаст ему этот заказ со статусом "принят" и со всеми обновлениями, которые успел сделать к этому моменту.
Во-первых, это достаточно сложный паттерн чтобы предлагать его имплементировать клиентам публичного API. Предоставить компонент для записи в локальные БД для каждой платформы не выглядит простой задачей, ну и вообще на разработчика API налагает много дополнительной ответственности.
Во-вторых, запись в локальную БД может быть неудачной или локальная БД может быть повреждена/стёрта.
Во-третьих, паттерн «клиент передаёт на сервер известный ему заказ» вообще чрезвычайно опасен. Сервер обязан дополнительно валидировать, что клиент не врёт и заказ действительно вот такой. Зачем тогда передавать сам заказ, достаточно его идентификатора.
Самое главное, я не вижу, каким образом это проще. Подмена синхронизации через API [у которого есть формальные интерфейсы и спецификация] синхронизацией через БД [у которой в лучшем случае есть документированная схема] почти всегда плохая идея даже если речь идёт о внутренних системах.
Подключил библиотеку и работаешь - куда проще, чем думать обо всех этих описанных в статье проблемах.
То есть и токен мы сохранить не сможем, и аутентификацию, да и приложение не факт, что вообще запустится.
Идентификатора достаточно только, если на конкретном сервере уже есть все актуальные данные. Ну а безопасность обеспечивается цифровой подписью.
Неидемпотентное API - это не почти, а всегда плохая идея. А вот синхронизация БД всегда идемпотентна.
Ну так и какая разница клиенту, хранит библиотека только токены или заказы целиком
Да, всё так. Именно этому вопросу и посвящена вторая половина статьи — как жить с ненадёжными клиентами и какие риски возникают
Эм, как обеспечить цифровой подписью, что клиент передал правильные данные, если сервер сам данных не знает?
Это не так. Обеспечить консистентную репликацию БД очень сложно. Вот, например, вводная статья от разрабочтиков InnoDB: https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html
Клиент может работать с данными синхронно, не парясь по поводу скорости и надёжности соединения с сервером.
Если токен цел, то БД можно восстановить с сервера или другого клиента.
Так ему и данные и подпись прилетят при синхронизации.
И где там сложности в row based replication?
Каким образом? Объём данных не изменился, его всё равно надо как-то синхронизировать (хотя бы на холодном старте). Ну и в обсуждаемом кейсе типа синхронизации заказов объём данных настолько незначителен, что всерьёз обсуждать какие-то выигрыши в плане трафика несерьёзно.
Можно. Тем не менее, хранить один токен, который меняется редко и целиком, гораздо проще, чем синхронизировать БД (в плане сложности кода)
Кому? Серверу? Откуда?
Там в разделе “Disadvantages of row-based replication” достаточно хорошо описано, в чём сложность.
Вы серьёзно пытаетесь убедить, что stateful клиент с синхронизацией через БД лучше, чем stateless с синхронизацией через API? Синхронизация через БД вообще антипаттерн, и оправдана в крайне редких кейсах.
1) А при чём тут объём трафика?
3) От клиента.
4) Мифические "много трафика" по сравнению с куда более проблемным подходом.
Зачем мне вас в чём-то убеждать? Мучайтесь со stateless api и дальше. Мне же выгодней. Моя БД прекрасно синхронизируется в реальном времени и даже не подозревает, что она "антипаттерн".
Меня чем-то привлекла эта безумная идея, позже планирую реализовать кейс с использованием данного подхода .
upd: Ожидаю развитие обсуждения туть: https://t.me/h_y_o_o/ (в топике распределенных систем)
[Паттерны API] Слабая консистентность