イベントレポート1日目と3日目、それぞれ午後から参加してきた!ということで3日目の感想を。予約してなかったけど認証と認可の回聞けた。Miyamotowww.slideshare.netアムロ声です、とのアイスブレイクから始まった。気になって集中できない(笑)コンポーネント間の認証とかも重要ですよね、その辺を話しますとのこと。マイクロフロントエンドの話も、少しあとの講演があるので大筋はそちらに譲るが多少話す、と。認証と認可の違い、など基礎的な話から。ある程度わかっているつもりの部分だったけれど、改めて説明しろと言われると難しいな、と思ったけど、大変わかりやすい説明だった。APIのリクエスト署名の話も少し。署名バージョン1については、脆弱性があるので使ってはいけない、とのこと。情報あるかなと思ったけれど、軽くググった程度では、すでにサポートされていない、という以外の情報は得られなかった。ユーザーの認証とシステムの認証の違い、気をつける点について。データが誰のものか、というと(本発表のケースでは)消費者のものであり、事業者が再委託的に預かっているにすぎない、そのため、ユーザーの許諾が必要か否か、という点が重要になるとのこと。その話を聞いて思い出したのは、2018年11月現在ではあまり話題に上がらなくなったが、半年前はやたらと騒がれていたGDPRのこと。あれも、データ管理者とデータ処理者で考慮すべき点が違っていて、似たような話かな、と思った。SSO(シングルサインオン)に関する話題が出たので、認可をどのように実装していくか、についても話が出るかな、と思ったけれど講演中には詳しいお話は伺えなかった。Speakerでその点について質問させていただくことができた。Securityなどのフレームワークを利用して、ユーザーの認証情報を管理する認証MSAを立てて実現することができる、とのこと。踏み込んだ話をしたかったけれど、あまり時間がなかったので残念。最後の方、SLO(シングルログアウト)は闇、と。意識したことなかったけど、確かに難しそう......。古川陽介氏Node.jsのコラボレータでもある古川さんのお話。BFFのユースケース5つの紹介から。よろず本』でちらっと読んだ程度で、複雑な連続するAPIコールをネットワーク等のリソースが貧弱なMobileクライアントの代わりに実行しHTMLレンダリングないしJSON生成を代替するもの、というイメージしか持っていなかった。(『よろず本』が悪いという話ではなく、私が理解していないというだけです、念のため。WebSocket/LongPolling/ServerSentEventが挙げられていた。思った以上にいろんな用途があるんだな、と認識を改めることができた。Netflixのケーススタディが面白かった。PCからカーナビとデバイスが多岐にわたるためデバイスごとのAPIを実装していたがスケールしないため、ClientAdaptorCodeという呼称で自然発生的にBFFが実現されていった、と。必要に応じて適切なパターンを実装していくのが良くて、最初からそこ(だけ)を目指す、というのは悪手な気がするなあ......(自戒)。自社でも実践されているとのことで、アンチパターンの紹介があったのがよかった。チーム間のコミュニケーション問題、インフラ・レスポンシビリティ問題、ビッグバン・ジョイント問題など。それぞれ、自作のツールなどを含めて解決していっているという話が聞けた。チーム間コミュニケーション問題は、これからまさにハマるような気がしているので、気をつけたいところ......。理論=課題は何か、どういう技術で解決するか、実践=得られた知見や課題など、の話。フロントエンドは結合レイヤなので、必然的に密結合になってしまっており、マイクロサービスの恩恵を受けづらいという問題がある、と。それを解決するためにiframeが使われていたり、WebComponentsが使われていたりする、と。WebComponentsは前述の『よろず本』でも(たしか)そこまで細かく取り扱われていなかったので、window.customElements.define()とかの実装方法が勉強になった。bustingとかグローバル状態共有とか、ブラウザ間差異とか、なんとなくフロントエンドの問題と言われてイメージのつくものだった。DOMの組み合わせで上手くいかないことがあると聞いて、やっぱりフロントエンド辛いな、という気持ちになった。触れられていなかったような気がするけれど、結局結合レイヤは残っているようだったし、そのあたりの最後のモノリスとの戦いが今後どのように進展していくのか楽しみでもある。篠原英治氏AWSのソリューション・アーキテクトの方のお話。資料は今のところなし。Amazon.comでマイクロサービスがどのように考えられ、作られてきたか。AWS上でユーザーによってどのように実践されてきたか。開発者がどうしていくと良いか。いった内容が語られた。」ではなく(きちんと複数形で)「Microservices」と発信されていたのが印象的だった。いうのも、「マイクロサービス」といった時に、「小さく分割された業務機能を実現する1つのサービス、あるいはバイナリ・モジュール」のような謎の誤解をしている(と見受けられる)ケースを見かけたことがあった。いった誤解を生まないように、「小さく分割された業務機能を実現するための複数のサービス」であることを意識づけようと、きちんと複数形で呼ばれていたのがよかった。Amazon.comの話は、倉庫を軸に、入庫のinboundチームと、出庫のoutboundチームがいるところからスタート。共有DBで......みたいな辛そうな話から始まり、片方のチームのDBスキーマ変更がもう片方をバグらせたりとか、リリースタイミングがビジネスのスピードに追いつかないとか、あるあるな話が盛りだくさん。Amazon.comですらそうなんだな、と思うと逆に安心できる気もしてしまってよくない(笑)Amazom.comもALBの発表以降、MSAチックになりつつあった、と。この話に関連して、データ・ドリブンにマイクロサービス化していくと、結局注文や品物といったデータの部分が巨大なモノリスになるのでよくない、という話が。覚えておこう(いつかハマる気がするが......)。AWSを利用した事例、ということで、Mapbox社、インティメート・マージャー社、Nike社の事例が挙げられていた。資料を見つけたので、後で読むべくメモしておく。Pressの記事に言及する場面もちらり。確かにGraphQLはある意味BFFといえばそうなのかもしれない、と思ったり。最後の方で、Envoyの開発者の言として紹介されていたのが、アーリーステージのスタートアップの場合は無理にマイクロサービスにせず、顕著な問題が出るまではモノリシックで良い、という話が。確かにマイクロサービスは複雑だから、それによってリリースのタイミングを逃すなんてことになったら、それはそれで収入に繋がらないので、ビジネス上の判断で捨てるべき時もあるんだな、と学んだ(活かせるとは言ってない)。読者になる広告を非表示にする関連記事2024-07-142024年25/52週目の振り返り25週:2024/6/17(月)〜2024/6/23(日)のことを書きます。[つく...2023-12-282023年49/52週目の振り返り49週:2023/12/4(月)〜2023/12/10(日)のことを書きます。[つく...2019-10-142019年41/52週目の振り返りつらつらと振り返ります。6で購入した本を技術書典7の前日に読み終えた今日、2019年9月22日(日)は待ちに待った技術書典7の当日。今さ...2019-05-132019年19/52週目の振り返りつらつらと振り返ります。that.Amazonアソシエイト・プログラム参加者です。(1)はてなブログをはじめよう!kidani_aさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。