Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? みらい翻訳 Advent Calendar 2021の記事です。 はじめに みなさんご存知だと思いますが、OpenAPIはREST APIを記述するデファクトな仕様記述言語と言っていいと考えています。では、AsyncAPIとは何でしょうか？ 結論から言うと、Event駆動アーキテクチャのAPIのインターフェイスを定義するためのものです。Eventは通常その処理結果を待つことなく任意のタイミングで発生しうるので、当然Event駆動アーキテクチャでは、Async(非同期)であることが要求されます。(AsyncAPIは検索しづらい名前ではある
はじめに 私が今関わっているプロジェクトでは、サーバーサイドにGo言語を採用し、Webフレームワークとして labstack/echo (以下、Echo) を採用しています。また、APIの定義を OpenAPI で行い、OpenAPI の定義から Echo のハンドラを一括登録するための関数やリクエスト/レスポンスの型を生成するために deepmap/oapi-codegen（以下、oapi-codegen）を利用しています。 OpenAPI を利用する目的の一つとして、クライアントとサーバー双方が一意な解釈が可能な API 定義を参照することによって認識の齟齬なく開発を進められるようすることが挙げられます。しかし、 oapi-codegen が生成するコードを使用した際に、 required な array と定義されているプロパティについて null として返却してしまう問題があります
以前はFlaskを使ってゆるい型もないゆるゆるフワフワしたAPIを作って居たものです。 しかしながら、最近は型の概念がいかに素晴らしいかというのをTypeScriptやらGolangやらで体感したので、たとえPythonであっても、しっかりした型でいい感じのコードを書きたくなりました。 開発環境 Poetry+Pysen これが今どきの最新っぽい雰囲気でおすすめされてたので使います openapi-generator-cli 別に何で生成してもいいと思いますが、以前から何度か使っていて慣れているので使う Stoplight 初めからStoplight使って居るので、無いとやってられない、もはや手書きでは書けない 1 ドキュメントを作る Stoplightでガリガリ書きます 2 Python-templeteを使い PysenとPoetry入ったプロジェクトを生成 で作ったあと、git cl
（全部隅々まで見たわけではないので若干間違っているかもしれませんが） SDK 2.xの大部分はAPIアクセスクラスを占めていたと言っても過言ではなく、その部分がごっそりなくなりました。 また、全体的な実装ボリュームも削減されたので、機能としても大幅に削減されています。 RxJSはWeb APIクラスが依存していましたが、それが無くなったので依存から無くなりました。 理由はコアデブなどに確認したわけではないので、憶測ですが、 規模が大きくなりすぎていて、メンテが行き届かなくなり、必要な機能だけに絞り込んだ小さなSDKを目指している 他の言語と同様のインターフェイスと使い心地を維持するため、リアクティブを止めた という狙いがあるように思えます。 参考までに公開されているパッケージのリンクを張っておきますが、この記事においては、SDKの利用については触れません。 SDK 2.x SDK 3.x
はじめに 単純な Web API を用意する必要があり、Falcon という若干マイナーな WSGI フレームワークを使ってみました。Falcon の公式サイトのサンプルやドキュメントの情報は十分なので、インストールしてすぐに使い始めるのはとても簡単です。しかし、細かいところで追加情報が必要だと感じることが多かったので、この記事で補いたいと思います。 Falcon - The minimalist Python WSGI framework https://falconframework.org/ 公式情報を日本語訳するだけのことは避けたいので、インストール方法や使い方を日本語で読みたいという方は、Qiita にある他の記事が参考になると思います。既に Falcon タグが作られています。この記事が記念すべき 10 件目。 Falconに関する9件の投稿 - Qiita http://qi
Flask + docker-composeでのWebアプリ開発に初めてpytestを使用しました。 その際のテストファイルと、設定内容をザックリまとめました。 親の記事はコチラとなります。 ■Flask+Docker+Vue.js+AWS...でゲームWebAppを作ってみた。 ■Githubにソースコード公開しています テスト書くとこんなに良い事ある 今まで、テストプログラムを避けていた人生でした 偶然ですが、テストを必要としないプロジェクトばかりで使う機会が無かったといえば言い訳ですが、心のなかで「あー、本当はテストとか書いといた方が良いんだろうなー」と思いつつも、重い腰が持ち上がらず。。。 そんな方は、私だけでなく多いと思います！ 心機一転でテストを書こうと決心したのは、こんなメリットがあります。 テストコードを書くメリット コード変更した際に、挙動確認が簡単&確実になる。 テスト
Page Object Modelパターンを利用したSeleniumテストの記述方法についてメモする。 POM(Page Object Model)とは ページをクラスオブジェクトとして扱うブラウザ自動化テストのデザインパターンの一つ。 主な概念 テストクラス * 対象ページのテストケース。 ページオブジェクト * 各Webページオブジェクトを作成することを目的としたクラス。 * テスト用コードとWebページアクセス用コードを分離。 ロケータ * ページ要素を取得させる。 利点 可読性の高いテストケースを書くことができる。 複数のテストケース間で共有できる再利用可能なコードを作ることができる※コード重複を防ぐことができる。 構成 root - TestBase.py |_ test_GoogleSearch.py |_ chromedriver.exe |_ Pages -- google
![[Python]Page Object Modelパターンを用いたSelenium テストの記述方法メモ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/d022cf7b75a39f4bd1034d251f68413207a521d0/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnBicy50d2ltZy5jb20lMkZwcm9maWxlX2ltYWdlcyUyRjEyMjg1NTU3MDgxMTI2MjE1NjglMkZsVy1KMm5wbl9iaWdnZXIuanBnP2l4bGliPXJiLTQuMC4wJmFyPTElM0ExJmZpdD1jcm9wJm1hc2s9ZWxsaXBzZSZiZz1GRkZGRkYmZm09cG5nMzImcz1jN2ViZjY0ODNlMWQ0ZGUyMmVlYjg4ZjVjY2EyZDkzYQ%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253Dd1cd3d0424fbee5aeeb8592ca173518f%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTIwJTVCUHl0aG9uJTVEUGFnZSUyME9iamVjdCUyME1vZGVsJUUzJTgzJTkxJUUzJTgyJUJGJUUzJTgzJUJDJUUzJTgzJUIzJUUzJTgyJTkyJUU3JTk0JUE4JUUzJTgxJTg0JUUzJTgxJTlGU2VsZW5pdW0lMjAlRTMlODMlODYlRTMlODIlQjklRTMlODMlODglRTMlODElQUUlRTglQTglOTglRTglQkYlQjAlRTYlOTYlQjklRTYlQjMlOTUlRTMlODMlQTElRTMlODMlQTImdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtcGFkPTAmcz04ODhkNGU4MzgxZGNiY2I1ZjYwYWMwNGI0M2JhY2MzZg%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBLV1NfMDkwMSZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1wYWQ9MCZzPWJjMDQ4OWRkZDZiMjU0MDM0NjhmYTlmNDdiYmFiZWVl%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3D5f8ffdc14e06a921074fa8e403b3f789)
サマリ Playwright for PythonのVer.1.22からPytestコードが生成(codegen)できるようになっています。 本記事ではPlaywrightのインストールからPytestコードの生成までを試します。 Codegen now supports generating Pytest Tests インストール > playwright codegen --help Usage: playwright codegen [options] [url] open page and generate code for user actions Options: -o, --output <file name> saves the generated script to a file --target <language> language to generate, one
はじめに GraphQL Meshとは複数のバックエンドサービスを束ねるGraphQLゲートウェイを構築するためのフレームワークです。GraphQL Mesh自体についての詳細は、数多くの記事が世の中にあるため省きます。 今回はGraphQL Meshを利用して、MySQLをラップしてGraphQLで扱う方法について試していきます。GraphQL Meshを経由して扱うことで、スキーマを自前で用意せずに既に存在するDB情報から自動で生成して取り扱うことができるようになります。 ローカルで動かすまでの手順 今回はローカルのdevサーバーとしてGraphQL Meshを立てて、任意のMySQLのDBを操作するところまで試します。 準備しておくもの ローカルからアクセス可能なMySQLサーバー 検証用に適当なデータベースとテーブルを作っておく 今回はMySQL8.0を使っています 必要なパッケー
発端 GraphQL API の利用者から API クライアントのコードレビューに付き合ってほしいと言われたので出席したんですが、とんでもない実装になっていて腰を抜かしてしまったので、注意喚起しようかなと。 はじめに結論 クエリの一部にユーザ入力を文字列連結するのはやめましょう！ 動的パラメータは variables で指定しましょう。 variables の指定例は以下を参照。 https://graphql.org/learn/serving-over-http/#post-request ポピュラーな GraphQL クライアントであれば、 variables に当たる変数を渡すことができるインタフェースが用意されていると思います。 インジェクションが起きる仕組み 実装言語は何でも良いです。 以下のような API クライアント実装があるとします。
この抜粋の内容は次のとおりです。 Subgraph Server の実装 Gateway Server の実装 Subgraph を通す Gateway を通す さらに詳しく知りたい方は読み続けてください。 2023年7月4回目です。 GraphQL Fedetaion についてです。 弊社のモバイルアプリの1つは、ユーザーのネットワーク帯域幅による影響を避けるため、GraphQL を BFF として使っています。 単一ドメイン業務においては、1つの GraghQL で問題ないと思います。 しかし、複数のドメイン業務を扱う場合、各チームは独立して自分たちの GraphQL サービスを開発するため、Supergraph（GraghQL Federation）1 にしていく必要があると思います。 現在弊社の第1言語は、Go です。Go による GraphQL Federation について見て
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 書きたいことを詰め込んだらタイトルが長くなってしまいました。 インフラ、フロントエンドと記事を書いてきたのでようやくバックエンドに触れます。 今回もサンプルを用意していますので最後までお付き合いください。 対象読者 マイクロサービス化を見据えたモノリシックアプリケーションを検討されている方 GraphQL サーバーと REST API サーバーのコードを共通化したい方 中規模以上のプロジェクト / プロダクトの技術選定を任された方 Scala や ZIO、関数型プログラミングに興味がある方 注意事項 サンプルはドメイン駆動設計(DDD)
はじめに 最近フロントエンドの通信をGraphQLに統一すべく頑張っているのですが、元々フロントエンドメインで開発していたのもありパフォーマンス度外視のBFF実装をしてしまいました。今回はGraphQLのパフォーマンス改善のために取り組んだこと2つをまとめていきたいと思います。2つしか書かない分できるだけ丁寧に書いたつもりです。普段BFFをGo言語で実装してるためサンプルコードはGo言語で書きますが、Goがわからない人にもわかりやすく説明するので最後までお付き合いいただけると幸いです。 触れること 取得するフィールドの制限してオーバーフェッチングを防ぐ Dataloaderを利用したN+1問題の解決 触れないこと GraphQLの基礎的なこと スキーマ設計とか 外部ツールを導入して計測をしたりだとか 現状そこまでしてパフォーマンス改善を行なった経験がないため 導入コストが高そうなので今回は
前期に初めて Relay Connection を使ったページネーション実装を行いました。 実装要件の制約もあり、その良さを最大限に生かした実装にはならなかったものの、カーソルベースのページネーションの考え方や Connection の仕様など、個人的に新しく学ぶことができました。 実際の実装イメージともに、それらの学びをまとめとして共有したいと思います。 前提 ページネーションの実装方式 そもそもページネーションの実装にはいくつか方法があり、代表してオフセットベースとカーソルベースがよく取り上げられます。 それぞれ得意とすることが異なるため、適材適所で使い分ける必要があります。 オフセットベースページネーション (offset-based pagination） SQL の OFFSET/LIMIT 句を使ったページネーション方式です。 データの先頭から数えて offset で指定した数
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
