Я даже больше скажу — в корпорациях типа гугла, яндекса и тд, таблица с юзерами будет находится в отдельном датацентре во владении отдельной команды и у нас, как разработчиков сервиса заказов вообще не будет к ней доступа, только приватная рестапишка и может кафка с ивентами апдейтов пользователей
И в таком случае чисто технически FK невозможно будет использовать
FK не даст гарантии, что юзер не забанен, не отключен или что-то еще, поэтому нужно делать в транзакции:
begin;
select * from user where id = ? for update;
insert into order ...;
commit;
(Либо уместить в 1 SQL запрос)
Конечно, если у вас система простая, без soft-delete, можно обойтись одними FK. Но в больших и нагруженных системах крайне часто FK не дает достаточных гарантий и все равно нужно делать проверки на беке
Кореютилс помимо перехода на раст ещё пытаются в оптимизацию, видел недавно баг репорт, что sort некорректно работает, но зато раз в 5 быстрее оригинала:)
Плюс в том, что беку не нужно думать о конкретных эндпоинтах, просто выдать доступ ко всему
Но есть минус - фронтендер может не предупредить о том, что меняет какой-то запрос. И может получится, что он поменяет запрос на что-то, что будет тригеррит Н+1 проблему
По мне graphql слишком специфичная штука, чаще рест удобнее
Asyncio корректнее сравнивать с тредами, а не синхронностью
В питоне requests спокойно может работать в 10 потоков (паралельно) через concurrency.threads.ThreadPoolExecutor, без необходимости использования asyncio
Фишка asyncio в том, что он использует корутины, а они дешевле тредов, поэтому лучше использовать их
Сама БДшка будет буквально такой же, что и при FK, просто без FK.
Разница будет только на стороне бекенда и только на операции удаления. Если вы не хотите использовать soft-delete, то на удаление статьи нужно будет сделать `delete from post_change where post_id = ?` (post_change - таблица дат). А после `delete from post where id = ?`. В остальном архитектура будет такой же, как и с FK
Акцент у статьи я пытался чуть другим сделать — FK не уменьшает ошибки, FK не дает каких-либо гарантий, которые уже не были бы даны нормальным бэкендом.
То есть реально ПД нужны исключительно тогда и в тех решениях, когда их не требуется удалять даже при наличии запроса от физического лица.
Раскройте, пожалуйста, мысль не понял...
Если мы говорим про воображаемый интернет-магазин, то ПД нужны для авторизации (телефон) и отправки чека (почта).
После удаления аккаунта юзера, очевидно, эти ПД нам больше и не нужны, потому что юзер не будет авторизовываться и ему не будут отправляться чеки об покупках.
В БД останется только его айдишник, по нему не получится связать его с реальным человеком
Да, безусловно, и их тоже нужно валидировать если вы не доверяете источнику!
Например, у заказа может быть shop_id и delivery_id. Если юзер отправляет запрос вида `POST /order {"shopId": ..., "deliveryId": ..., "cartItems": []}` вам же все равно нужно сходить в БД и проверить, что такой shop существует, что он может принимать заказы, что в нем есть указанные товары.
Вставить в БДшку поля без проверки можно только в случае, если мы доверяем отправителю, например, в приватной апишке между сервисами.
Так вам в любом случае нужно сходить в БД, чтобы проверить, что юзер авторизован и имеет право сделать заказ
Если вы никак не верифицируете айдишники в системе, то злоумышленик может просто насоздавать заказов на чужих юзеров? Вам же так и так нужно верифицировать, что инпут в систему корректен
FK не необходимы, их можно использовать, но если вы правильно проектирует бэкенд, то FK не дадут вам каких-либо преимуществ.
В правильно спроектированном бэкенде не будет ситуации, когда FK может триггернуться и выдать ошибку. Таким образом FK не дают нам каких-либо преимуществ.
С интернет-магазином все просто — в архитектуру заложена гарантия валидности связанных таблиц
В статье говорится, что ситуация, когда FK сработает — невозможна, либо около невозможна, а валидация в первую очередь должна быть на стороне бэкенда, а не БД.
FK от шального скрипта никак не защищают, вы все также можете проставить неправильный айдишник, просто он должен существовать. Либо вообще удалить данные
Защищаться от неправильных скриптов нужно через ограничение прав, а не FK
Сами лямбды деплояться относительно просто, сложность заключается в связывание ресурсов. Такая же проблема будет в любых микросервисах: в кубере, в EC2 и тд.
У лямбд есть преимущество в логике скалирования: они скалируются по длительности выполнения: если ивенты к лямбдам начинают собираться в очередь, то запускаются еще лямбды. У ec2 и k8s, если мне не изменяет память, такой логики нет.
Скорость скалирования и дескалирования у лямбд намного выше почти любого ec2 и k8s
Я даже больше скажу — в корпорациях типа гугла, яндекса и тд, таблица с юзерами будет находится в отдельном датацентре во владении отдельной команды и у нас, как разработчиков сервиса заказов вообще не будет к ней доступа, только приватная рестапишка и может кафка с ивентами апдейтов пользователей
И в таком случае чисто технически FK невозможно будет использовать
Я про это как раз и писал в статье...
FK не даст гарантии, что юзер не забанен, не отключен или что-то еще, поэтому нужно делать в транзакции:
(Либо уместить в 1 SQL запрос)
Конечно, если у вас система простая, без soft-delete, можно обойтись одними FK. Но в больших и нагруженных системах крайне часто FK не дает достаточных гарантий и все равно нужно делать проверки на беке
Кореютилс помимо перехода на раст ещё пытаются в оптимизацию, видел недавно баг репорт, что sort некорректно работает, но зато раз в 5 быстрее оригинала:)
Гибкость graphql это сразу и плюс и минус
Плюс в том, что беку не нужно думать о конкретных эндпоинтах, просто выдать доступ ко всему
Но есть минус - фронтендер может не предупредить о том, что меняет какой-то запрос. И может получится, что он поменяет запрос на что-то, что будет тригеррит Н+1 проблему
По мне graphql слишком специфичная штука, чаще рест удобнее
Asyncio корректнее сравнивать с тредами, а не синхронностью
В питоне requests спокойно может работать в 10 потоков (паралельно) через concurrency.threads.ThreadPoolExecutor, без необходимости использования asyncio
Фишка asyncio в том, что он использует корутины, а они дешевле тредов, поэтому лучше использовать их
Крутая статья!
У меня получилось что-то наоборот:)
В комментариях автору, как мне кажется, корректно ответили, что не всегда мягкое удаление не нужно и его аргументы можно обойти.
Да, согласен.
Как доп. защиту FK можно использовать.
Сама БДшка будет буквально такой же, что и при FK, просто без FK.
Разница будет только на стороне бекенда и только на операции удаления. Если вы не хотите использовать soft-delete, то на удаление статьи нужно будет сделать `delete from post_change where post_id = ?` (post_change - таблица дат). А после `delete from post where id = ?`.
В остальном архитектура будет такой же, как и с FK
Акцент у статьи я пытался чуть другим сделать — FK не уменьшает ошибки, FK не дает каких-либо гарантий, которые уже не были бы даны нормальным бэкендом.
Раскройте, пожалуйста, мысль не понял...
Если мы говорим про воображаемый интернет-магазин, то ПД нужны для авторизации (телефон) и отправки чека (почта).
После удаления аккаунта юзера, очевидно, эти ПД нам больше и не нужны, потому что юзер не будет авторизовываться и ему не будут отправляться чеки об покупках.
В БД останется только его айдишник, по нему не получится связать его с реальным человеком
Да, безусловно, и их тоже нужно валидировать если вы не доверяете источнику!
Например, у заказа может быть shop_id и delivery_id. Если юзер отправляет запрос вида `POST /order {"shopId": ..., "deliveryId": ..., "cartItems": []}` вам же все равно нужно сходить в БД и проверить, что такой shop существует, что он может принимать заказы, что в нем есть указанные товары.
Вставить в БДшку поля без проверки можно только в случае, если мы доверяем отправителю, например, в приватной апишке между сервисами.
Так вам в любом случае нужно сходить в БД, чтобы проверить, что юзер авторизован и имеет право сделать заказ
Если вы никак не верифицируете айдишники в системе, то злоумышленик может просто насоздавать заказов на чужих юзеров?
Вам же так и так нужно верифицировать, что инпут в систему корректен
FK не необходимы, их можно использовать, но если вы правильно проектирует бэкенд, то FK не дадут вам каких-либо преимуществ.
С интернет-магазином все просто — в архитектуру заложена гарантия валидности связанных таблиц
В статье говорится, что ситуация, когда FK сработает — невозможна, либо около невозможна, а валидация в первую очередь должна быть на стороне бэкенда, а не БД.
FK от шального скрипта никак не защищают, вы все также можете проставить неправильный айдишник, просто он должен существовать. Либо вообще удалить данные
Защищаться от неправильных скриптов нужно через ограничение прав, а не FK
P.S. индексы, очевидно, нужны
Потому что первое - вызов функции, а второе - управление потоком
В каналах, кстати, используются мьютексы
Ой да гошка довольно простой и прямолинейный язык, быстро можно будет выучить, это же не раст или плюсы
В идеале, конечно, микросервис должен быть достаточно автономен доменно так, чтобы другим сервисам он был нужен как можно меньше
Если у вас есть 3 микросервиса, что ходят в другдружку, дублируют DTO и сильно связаны - это плохо, это должно быть монолитом
Если же у вас 3 микросервиса, которые вообще не ходят в друг дружку - это хорошо
(Очень грубо говоря, конечно)
Внешние ключи зло, их не надо использовать!!! (Они просто никогда не нужны, можно спокойно писать код без них)
Сами лямбды деплояться относительно просто, сложность заключается в связывание ресурсов. Такая же проблема будет в любых микросервисах: в кубере, в EC2 и тд.
У лямбд есть преимущество в логике скалирования: они скалируются по длительности выполнения: если ивенты к лямбдам начинают собираться в очередь, то запускаются еще лямбды. У ec2 и k8s, если мне не изменяет память, такой логики нет.
Скорость скалирования и дескалирования у лямбд намного выше почти любого ec2 и k8s
Совсем забыл добавить про глобальные переменные, которые сохраняются между вызовами, спасибо за дополнение!