Mevzu o değil, authN/authZ işini bir API gateway'e de bırakabilir. Kaç yıldır greenfield ve brownfield projelerde çalışıyorum, ne zaman iş authN/Z'ye el atmaya gelse JWT varsa bu tasarım kararını kim verdiyse arkasından güzel bir sövüyorum. Abi şunu anlamak zor değil, JWT denen nane partiler arası veri paslamıyorsanız (SSO vs sosyal medya login'i durumlarında vs.) Web authentication için kullanılmıyor. Auth0, Okta bile yapmıyor bu saçmalığı, ama ne hikmetse bir JWT manyası var geliştiricilerde. Adamlar 25-30 yıl önce bu sorunu çözmüşler zaten cookie ile.
https://www.google.com/search?q=don%...combinator.com
Middleware, rate limiting kullan. Ama bu ikisi de iṣe yaramıyor. Diyelim ki, api adresine saldırganlar dakikada milyonlarca istek atıyor. (çoğu hatalı istek) ama bu hatalı istekler; sunucunu ṣiṣirir.
En profesyonel çözüm; cloudflare ve docker kubernetes ile güvenlik duvarı kurmaktır. Baṣkasından gelen saldırgan request isteklerini engellersin.
Ciddi projelerde genelde BFF'den faydalanılır bu durumda. Birden fazla frontend varsa ona göre ayrı backend katmanı çekilir. Mesela sende hem Web, hem mobil var. Hepsinin ihtiyaçları farklı olur. Mesela Web'de server rendered içerik sunabilirsin, mobilde böyle bir şey olmadığı için ya API ya da GQL vs. kullanırsın. Best practice şöyle:
Ayrı bir api projesi oluşturdum gerekli sorguları api ve repositoryleri burada yazıyorum front end olarak mobil başladım ama ileride web içinde aynı apiyi kullanabilirim