APIセキュリティ入門（2）：APIの認証と認可をスケールする手法 - ZDNet Japan
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 前回は、APIをエッジで処理する有効性について説明した。第2回の本稿では、APIの認証と認可をエッジでどのようにスケールさせるかを説明したい。 APIのタイプには、パブリックとプライベートがある。パブリックなものは、誰でもAPIを呼び出すことができ、大概は一定期間キャッシュできるため、コンテンツ配信ネットワーク（CDN）のような仕組みは非常に有効だ。例えば、検索結果を返すAPIは、バックエンドのデータベース情報が変わらなければ常に同じ結果を返すので、エッジでキャッシュできればエンドユーザーの操作性はかなり良くなる。また、毎回オリジンサーバにリクエストが届かなくなるので、クラウド基盤のコンピュータリソースもコスト削減できる。 問題なのは、
APIセキュリティ入門（1）：APIをエッジで制御する意味とは何か
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます モノからコトへと人々の価値観が変化、多様化していく中で、自社の発想だけでのユーザー囲い込みは、よほどの強力な製品やプラットフォームがなければ生き残り続けるのは厳しい。コストもかかる。多くの企業はビジネスのアジリティを高めるために、従来のモノリシックなシステム構造から脱却し、クライアントからのデータアクセスをAPIで提供している。そして、APIはマネタイズ（収益化）するための重要な企業戦略になる可能性を秘めている。APIは「Application Programming Interface」の略だが、「A Profit Increase」だという解釈もあるようにAPIは利益を生み出すのだ。 日々、約3兆のリクエストをインターネットで処理し
GraphQLクライアントにurqlをおすすめしたい
GraphQLのクライアントといえばApollo Clientが使われることが多いと思いますが、urqlというクライアントをおすすめする記事です。 TL;DR urqlのドキュメントキャッシュはApolloみたいなキャッシュ管理が要らなくて楽だからおすすめ ドキュメントキャッシュは、Mutationの __typename を見て汚れたキャッシュを捨てる仕組み Mutationのあと refetchQueries やってるならそれはurqlが自動でやってることと同じ なぜurqlをおすすめするのか この記事ではurqlのドキュメントキャッシュというキャッシュを仕組みだけを紹介します。雑に言うと、Apolloの正規化されたキャッシュより多少効率は落ちるものの煩雑な正規化されたキャッシュの管理から解き放たれるというものです。Apolloのキャッシュの管理に疲れた人にめちゃくちゃおすすめですし、
AmazonのAPI設計方針 (The Bezos Mandate) - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに The Bezos Mandateという文書があります。日本語に訳すと「ベゾスのお達し」とか「ベゾスの勅令」でしょうか。 言わずと知れたAmazon.comのCEO、ジェフ・ベゾスが開発チームに通達した内容です。 これが（元Amazon.com従業員によって）公開されたのは2011年ですが、ベゾスがこのお達しを出したのは2002年前後です。17年経過した現在でも真理をついているどころかようやく時代がベゾスに追いついたかという感想です。 この記事ではThe Bezos Mandateの紹介と、僭越ながら補足説明も行います。 お達
TypeScript * GraphQLのバックエンド設計プラクティス
2冊目も公開中なのでみてください！ https://zenn.dev/tatta/books/4e993c596e7dc9 TypeScriptを使いはじめて1年になるので、バックエンドのWebアプリを設計するときに気を付けていることをまとめました。（※社内勉強会用資料の公開版です。） TypeScriptについては、Next.jsを中心にフロントエンドに関する公開情報が豊富です。一方でバックエンドに関する公開情報が少ないと感じています。（かくいう私もNext.jsからTypeScriptデビューしたわけですが） TypeScript * GraphQL という構成は仕事・趣味で採用されている方も多いのではないでしょうか？ 私もその1人です。私のような方のためにも、バックエンドの設計プラクティスについてまとめようと思い筆を取りました。 本書がこれから始める読者にとっては教科書のようになり、
ZOZOTOWNリニューアルで実施したCache Stampede対策 - ZOZO TECH BLOG
はじめに こんにちは。マイグレーションチームの藤本です。 この記事では、先日のリニューアルに伴って導入したBackends For Frontends（以下、BFF）で、Redisを使ったキャッシュの事例をご紹介します。キャッシュを導入する際に起きる問題とその回避策について、サーバーサイドのアプリケーションで行った対策をもとに紹介していきます。 ZOZOTOWNリニューアルとBFF ZOZOTOWNで導入したBFFは、複数のAPIのレスポンスをフロントエンドが必要とする形式に集約して返却することを主な目的としています。これまでの実績から、大規模セール時のアクセス数は通常時の何倍にもなることがわかっており、BFFもそれに耐えられるパフォーマンスが必要です。 しかし、BFFに来たすべてのアクセスをそのままAPIに流すと、パフォーマンスに影響する恐れが出てきました。そのため、APIからのレスポン
GraphQL IDE の “GraphiQL” をカスタマイズして、開発ツールとして活用する - Hatena Developer Blog
こんにちは．マンガチームの id:mangano-ito です．最近は GraphQL API の開発を担当しており，GraphQL に関することを勉強したり実践したりしています．今回は開発ツールについてのお話です． GraphiQL とは GitHub API での使用例 GraphiQL を導入してみよう ツールバーをカスタマイズしてみよう ヘッダーやクエリをカスタマイズしてみよう 実際に開発ではどう使っているか GraphiQL とは graphql/graphiql: GraphiQL & the GraphQL LSP Reference Ecosystem for building browser & IDE tools. GraphQL API の使いやすい GUI クライアントです．GUI クライアントなので GraphQL ではなく Graph i QL となっているのが
TypeScript の型生成における OpenAPI Generator のハマりどころ - READYFOR Tech Blog
こんにちは。READYFOR でフロントエンドエンジニアとして働いている菅原（@kotarella1110）です！ 嬉しいことに、READYFOR のプロダクト開発組織は急拡大中で、正社員の人数は 2019年7月時点では8名でしたが2021年4月現在は29名になりました 🎉 その反面、組織が大きくなってくると「我々はどこに向かってるんだっけ？」「あの人、最近はどんなことに取り組んでいるんだろう？」といった「見えないこと」が増えてきます🤔 この「見えないこと」を減らすために、READYFOR では毎月「プロダクト開発本部会」を開催しています。 プロダクト開発本部会では、必要な全体周知（組織やプロダクトの方針等）や月替わりプレゼンテーションを行っています。 本記事はこのプロダクト開発本部会の月替わりプレゼンテーションで発表した内容になります。 はじめに 以前 READYFOR で初主催とな
GraphQLでバックエンドのコードをすっきりさせた話 - LayerX エンジニアブログ
こんにちは！LayerXの mosa_siru (榎本) です。 LayerX インボイスでは、もともと github.com/go-swagger/go-swagger を利用してREST APIを開発していましたが、最近開発したワークフロー機能 のコンポーネントではGraphQLを取り入れました。 GraphQLには様々なメリットがあり、RESTとの比較記事は多くありますが、なぜ僕らは移行したのか、その結果どうなったのかを紹介していきます。 GraphQLのメリット GraphQLのメリットは、様々な箇所で語られています。例えばこの記事によれば、 強力に型付けされたスキーマであること アンダーフェッチとオーバーフェッチがないこと（後述） Apollo, Relayなどの、クライアントライブラリにより、フロントエンド開発が迅速になること 複数のGraphQL APIからの統合が可能 強力
GraphQLが解決する問題とその先のユースケース
サーバーサイドからみたGraphQL Serverlss Meetup#19 2021/03/31 に行われた Serverlss Meetup#19 で上記のタイトルで登壇してきました。サーバーサイドの話をしようと思ったけどGraphQLの解決している話をしようと思ったらクライアントの事もかなりはいってしまったので記事のタイトルは変えました。 以下内容です。記事の最後に資料を書くにあたって参考になった資料のリンクを置いてます。 GraphQL and me この1年書いたQiita記事 GraphQLの特徴を分解する ~API インターフェース・Universal BFF・API Gateway~ GraphQLはサーバーサイド実装のベストプラクティスとなるか GraphQLの全体像とWebApp開発のこれから 今回話す事 そもそもGraphQLはなんで作られたのか、何を解決しようとして
swagger-merger を用いた大規模API開発における Swagger 運用
はじめにこんにちは、Finatext で保険事業のプロダクト開発をしている @toshipon です。今回は以前の Fin-JAWS のイベントで少し紹介させていただいた、我々の現場で取り組んでいる、大規模API開発における Swagger を用いたAPI仕様のドキュメント運用方法について紹介いたします。 概要我々の現場では、API ベースのWeb Application を開発する際に、Swagger を用いて API 設計をしたり、BFFサーバー開発者やフロントエンド開発者とのコミュニケーション手段として活用しています。 ただし、Web Application の規模が大きくなってくると、Swagger の 定義ファイルは肥大化してしまい、メンテナンスが困難になってきます。 今回は、Web Application の規模が大きくなっても耐えうる Swagger 定義ファイルの運用方法を
【ZOZOTOWNマイクロサービス化】API Gatewayの可用性を高めるノウハウを惜しみなく大公開 - ZOZO TECH BLOG
はじめに こんにちは。ECプラットフォーム部のAPI基盤チームに所属している籏野 @gold_kou と申します。普段は、GoでAPI GatewayやID基盤（認証マイクロサービス）の開発をしています。 先日、【ZOZOTOWNマイクロサービス化】API Gatewayを自社開発したノウハウ大公開！ を公開したところ、多くの方からご好評いただきました。ありがとうございます。まだ読まれていない方はぜひご覧ください。 techblog.zozo.com 今回はその記事の続きです。API Gatewayは単にリバースプロキシの役割を担うだけでなく、ZOZOTOWN全体の可用性を高める仕組みを用意しています。本記事では、それらの中でカナリアリリース機能・リトライ機能・タイムアウト機能に関して実装レベルの紹介をします。 マイクロサービスに興味ある方や、API Gatewayを自社開発する方の参考に
1画面1APIと比べるとGraphQLのAPIはどこから作ったらいいか分かりにくい - hitode909の日記
Backends for Frontends的に、1画面につき1つずつAPIを作っていると、画面のリストを作って、それぞれ1画面につき1個ずつAPIを作っていくことになるので、進捗の把握がやりやすかった。10画面あって3APIできてたら進捗30%ということになる。 グラフをたどって開発することになる GraphQLでAPIを作っていると、「実はこの画面を組み立てるためのクエリは、あちらの画面の条件を変えたものである」みたいなことが起きるようになる。たとえば、トップページではサマリを表示していて、もっと見るを押すと全件表示するような場合とか。 このように、着手しようとするともう作るものがなかったりとか、逆に、作るときに、他の画面から使う想定でパラメータの設計をするなど、考えることが増えたりもする。 スキーマに沿ってグラフをたどるだけで画面を組み立てられるのは良いことだけど、開発内容の依存関係
バックエンド Web API に管理画面/管理機能を追加するアーキテクチャパターン - valid,invalid
プレゼンテーションレイヤ、いわゆるフロントエンドがクライアントサイドで実装・実行されるアーキテクチャ (注 1) において、管理画面/管理機能をあとから追加する際にどのような実装パターンがあるのかを整理してみます。 注 1: Presentation Domain Separation の実践の中でも、物理的にプレゼンテーションロジックとドメインロジックを分離しているアーキテクチャです。 用語の整理 プレゼンテーションレイヤ 三層アーキテクチャにおける、システムの利用者へユーザインターフェイスを提供する層です。本記事では"フロントエンド"とほぼ同義で使います。 OSI 参照モデルの第六層ではないです。 バックエンド Web API とは プレゼンテーションを持たない Web API (HTTP プロトコルを用いてネットワーク越しに呼び出すアプリケーション) とします。 プレゼンテーションレ
Swagger / OpenAPI 定義から C# クライアントを自動生成するツールの比較 - しばやん雑記
Swagger / OpenAPI の定義からクライアントを作成するツールがいくつかあって、それぞれ特徴がありそうだったので実際に生成して試してみました。試したのは以下の 3 つです。 Swagger Codegen OpenAPI Generator AutoRest 使った Swagger 定義は公式の Petstore サンプル*1です。生成したコードは GitHub に上げました。 C# に関してのみ試しているので、他の言語の場合はまた変わってくると思います。何となく C# のクライアントは Java のコードを移植した感がありました。 Swagger Codegen Swagger が開発しているジェネレータです。対応する言語は多く、サーバー側のコードも生成してくれます。 実行環境を用意するのが面倒だったので、Swagger Editor を使ってクライアントを生成しました。 c
OpenAPI SchemaからTypeScript Code Generatorを作ったので紹介します
他言語からTypeScriptに変換する記事を観測したので、JSONSchemaを経由してTypeScriptのコードに吐き出すライブラリを作りました。本記事のコアロジックの部分を抽出した形です。 OpenAPI TypeScript Code Generatorとの違いとして、ルートの名前空間を廃止しているので、割と自由に書ける様になってます。 https://www.npmjs.com/package/@himenon/jsonschema2ts
Good Bye Web APIs
DEV Community Follow A space to discuss and keep up software development and manage your software career Open Forem Follow A general discussion space for the Forem community. If it doesn't have a home elsewhere, it belongs here Future Follow News and discussion of science and technology such as AI, VR, cryptocurrency, quantum computing, and more.
オープンソースのAPIゲートウェイ「Kong Gateway 2.2」がリリース
「Kong Gateway 2.2」では、従来サポートしてきたRESTおよびgRPC APIによるHTTP／HTTPSトラフィックや、TCPストリームに加えて、UDPベースのプロトコルもサポートしている。UDPサポートには、プロキシ、負荷分散、プラグインの実行が含まれ、TCPと同様の機能を提供する。 さらに、Goプラグインが強化され、Go言語によって実行可能な機能の範囲が拡張したほか、ルートごとにリクエストとレスポンスのバッファリングの有効／無効を設定できるようになり、エンドポイントごとにバッファリング動作をより適切に調整することで、大きなペイロードを処理するエンドポイントで最適なレイテンシの確保を可能にしている。 そのほか、OS証明書の自動ロード、パスによるレート制限、データベースからのターゲット履歴の削除など、さまざまな機能の改善や修正が行われた。 なお、「Kong Gateway 2
なぜその API は使われないのか？ API の活用を拒む3つの壁とその対策 - CData Software Blog
こんにちは！ CData Software Japan リードエンジニアの杉本です。 大変ありがたいことに、最近あるSaaSを提供する会社さんから「リリース前のAPIを触ってみてフィードバックをくれませんか？」と依頼を受けました。 私は以前こんな記事 を公開するほど、APIどっぷりな人間なのですが、数多くの SaaS APIを触ってきてよく考えることがあります。 それは SaaS APIというサービス・プロダクトそのものを成長させる上で、もっとも重要なことは「顧客・デベロッパーが、そのAPIをどれだけスムーズにキャッチアップできるか？」という点に尽きるのではないか？ というものです。 以下のグラフはAPI管理ツールを提供するSmartBearのAPI調査において、APIドキュメントで最も重要な要素とは何か？ というアンケート結果のランキングですが、ExamplesやAuthenticati
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GraphQL を利用したアーキテクチャの勘所 / Architecture practices with GraphQL
