Microservices における認証と認可の設計パターン
マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その
本当に倒すべきだったのは jQuery ではなくテンプレートエンジンだった - fsubal
そうはっきり言ったほうが良かった。いや言わなくても伝わる現場は良かったんだけど、伝わらないままごく一部だけをコンポーネントに移行、それ以外はただ生 DOM API に変えて終わり（あるいは他は jQuery のまま）みたいな「モダン化」で済ます余地を与えたのは発信の失敗だった……という10年代の振り返り。 テンプレートエンジンはなぜ倒された方が（…といって悪ければ、変わったほうが）良いのかは端的に指摘できて、それは初回レンダリングしか考慮してないからだということになる。 Web の UI には状態変化がつきもの（になったのは実は最近の話）だが、テンプレートエンジンは1回目のレンダリングだけを担当し、変化した後の2回目以降の見え方は JavaScript が担当するというパラダイムを構成する。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
