タグ

*programとwebappに関するsh19910711のブックマーク (1,011)

  • OpenAPIスキーマ互換なAsyncAPIとは? - Qiita

    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は検索しづらい名前ではある

    OpenAPIスキーマ互換なAsyncAPIとは? - Qiita
    sh19910711
    sh19910711 2024/06/17
    "AsyncAPI: Event駆動アーキテクチャで非同期APIを定義するためのOpenAPIのスキーマに対応した仕様 / 同じように仕様のドキュメント化、コード生成、コードからの仕様化までも提供" 2021
  • deepmap/oapi-codegen のカスタムテンプレートで required array が null で返ってしまうのを防ぐ - Qiita

    はじめに 私が今関わっているプロジェクトでは、サーバーサイドにGo言語を採用し、Webフレームワークとして labstack/echo (以下、Echo) を採用しています。また、APIの定義を OpenAPI で行い、OpenAPI の定義から Echo のハンドラを一括登録するための関数やリクエスト/レスポンスの型を生成するために deepmap/oapi-codegen(以下、oapi-codegen)を利用しています。 OpenAPI を利用する目的の一つとして、クライアントとサーバー双方が一意な解釈が可能な API 定義を参照することによって認識の齟齬なく開発を進められるようすることが挙げられます。しかし、 oapi-codegen が生成するコードを使用した際に、 required な array と定義されているプロパティについて null として返却してしまう問題があります

    deepmap/oapi-codegen のカスタムテンプレートで required array が null で返ってしまうのを防ぐ - Qiita
    sh19910711
    sh19910711 2024/06/17
    "deepmap/oapi-codegen: OpenAPI の定義から Echo のハンドラを一括登録するための関数やリクエスト/レスポンスの型を生成 / 定義を満たしていない API を実装してしまうことがあり、クライアントが API レスポンスを処理できず" 2021
  • APIドキュメントから生成したFastApiスタブをPysenに怒られないようにするまで - Qiita

    以前はFlaskを使ってゆるい型もないゆるゆるフワフワしたAPIを作って居たものです。 しかしながら、最近は型の概念がいかに素晴らしいかというのをTypeScriptやらGolangやらで体感したので、たとえPythonであっても、しっかりした型でいい感じのコードを書きたくなりました。 開発環境 Poetry+Pysen これが今どきの最新っぽい雰囲気でおすすめされてたので使います openapi-generator-cli 別に何で生成してもいいと思いますが、以前から何度か使っていて慣れているので使う Stoplight 初めからStoplight使って居るので、無いとやってられない、もはや手書きでは書けない 1 ドキュメントを作る Stoplightでガリガリ書きます 2 Python-templeteを使い PysenとPoetry入ったプロジェクトを生成 で作ったあと、git cl

    APIドキュメントから生成したFastApiスタブをPysenに怒られないようにするまで - Qiita
    sh19910711
    sh19910711 2024/06/17
    "最近は型の概念がいかに素晴らしいかというのをTypeScriptやらGolangやらで体感したので、たとえPythonであっても、しっかりした型でいい感じのコードを書きたく / Poetry+Pysen: 今どきの最新っぽい雰囲気でおすすめされ" 2022
  • Docker を使って Dredd で openapi (Swagger) のテストを簡単にできるようにしたよ - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    Docker を使って Dredd で openapi (Swagger) のテストを簡単にできるようにしたよ - Qiita
    sh19910711
    sh19910711 2024/06/17
    "FEのエンジニアから「プロパティ名が一文字間違っていてハマりましたよー笑」なんて言われてしまうと、平謝りすることしかできない / Dredd: デフォルトでは、OASに書かれたすべてのレスポンスを検証" 2022
  • OpenAPI 定義と Aspida で型付きの Symbol API レスポンスを取り扱う - Qiita

    (全部隅々まで見たわけではないので若干間違っているかもしれませんが) SDK 2.xの大部分はAPIアクセスクラスを占めていたと言っても過言ではなく、その部分がごっそりなくなりました。 また、全体的な実装ボリュームも削減されたので、機能としても大幅に削減されています。 RxJSはWeb APIクラスが依存していましたが、それが無くなったので依存から無くなりました。 理由はコアデブなどに確認したわけではないので、憶測ですが、 規模が大きくなりすぎていて、メンテが行き届かなくなり、必要な機能だけに絞り込んだ小さなSDKを目指している 他の言語と同様のインターフェイスと使い心地を維持するため、リアクティブを止めた という狙いがあるように思えます。 参考までに公開されているパッケージのリンクを張っておきますが、この記事においては、SDKの利用については触れません。 SDK 2.x SDK 3.x

    OpenAPI 定義と Aspida で型付きの Symbol API レスポンスを取り扱う - Qiita
    sh19910711
    sh19910711 2024/06/17
    "Symbol SDK: 3.x系からガラッと実装が変わっています。というか作り直され / 規模が大きくなりすぎていて、メンテが行き届かなくなり、必要な機能だけに絞り込んだ小さなSDKを目指している" 2022
  • NextjsでVSCodeのタブのカスタムラベルを設定してみた - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    NextjsでVSCodeのタブのカスタムラベルを設定してみた - Qiita
    sh19910711
    sh19910711 2024/06/17
    "VSCode: 1.88がリリースされ、タブの見た目をカスタムできるcustomLabelsが設定できるようになりました / 「どこ」の「なに」がわかりやすくなり + カスタムラベルを使うと、タブで何の「役割」かを明示できてよさそう"
  • Python 3 + Falcon を使った RESTful API の開発/テスト/デバッグ - Qiita

    はじめに 単純な Web API を用意する必要があり、Falcon という若干マイナーな WSGI フレームワークを使ってみました。Falcon の公式サイトのサンプルやドキュメントの情報は十分なので、インストールしてすぐに使い始めるのはとても簡単です。しかし、細かいところで追加情報が必要だと感じることが多かったので、この記事で補いたいと思います。 Falcon - The minimalist Python WSGI framework https://falconframework.org/ 公式情報を日語訳するだけのことは避けたいので、インストール方法や使い方を日語で読みたいという方は、Qiita にある他の記事が参考になると思います。既に Falcon タグが作られています。この記事が記念すべき 10 件目。 Falconに関する9件の投稿 - Qiita http://qi

    Python 3 + Falcon を使った RESTful API の開発/テスト/デバッグ - Qiita
    sh19910711
    sh19910711 2024/06/17
    "単純な Web API を用意する必要があり、Falcon という若干マイナーな WSGI フレームワークを使ってみました / 公式ドキュメントもシンプル: 記述が簡潔過ぎて知りたい情報が書かれていなかったり" 2017
  • 【pytest】をFlask+docker開発で初めて使ってみた - Qiita

    Flask + docker-composeでのWebアプリ開発に初めてpytestを使用しました。 その際のテストファイルと、設定内容をザックリまとめました。 親の記事はコチラとなります。 ■Flask+Docker+Vue.js+AWS...でゲームWebAppを作ってみた。 ■Githubにソースコード公開しています テスト書くとこんなに良い事ある 今まで、テストプログラムを避けていた人生でした 偶然ですが、テストを必要としないプロジェクトばかりで使う機会が無かったといえば言い訳ですが、心のなかで「あー、当はテストとか書いといた方が良いんだろうなー」と思いつつも、重い腰が持ち上がらず。。。 そんな方は、私だけでなく多いと思います! 心機一転でテストを書こうと決心したのは、こんなメリットがあります。 テストコードを書くメリット コード変更した際に、挙動確認が簡単&確実になる。 テスト

    【pytest】をFlask+docker開発で初めて使ってみた - Qiita
    sh19910711
    sh19910711 2024/06/17
    "テストを通すことで、チーム内のエンジニア同士で、問題なく動くことのエビデンスとなる / エラーがいつからどこで、おかしくなったのか、把握することが容易 / チーム内のエンジニア同士の仕様の齟齬を無くす" 2020
  • Django + jsonrpcserver + Docker Compose で作った JSON-RPC API を pytest-django の parametrize でテストする - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    Django + jsonrpcserver + Docker Compose で作った JSON-RPC API を pytest-django の parametrize でテストする - Qiita
    sh19910711
    sh19910711 2024/06/17
    "parametrize で複数パターンの一括テスト / Django では unittest が標準のユニットテストフレームワークですが、ここではサードパーティの pytest と pytest-django をインストールして使用" 2021
  • [Python]Page Object Modelパターンを用いたSelenium テストの記述方法メモ - Qiita

    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
    sh19910711
    sh19910711 2024/06/17
    "ページをクラスオブジェクトとして扱うブラウザ自動化テストのデザインパターン / ページオブジェクト: テスト用コードとWebページアクセス用コードを分離 / 可読性の高いテストケースを書くことができる" 2021
  • PythonのFastAPIをLambdaで動かそうと思ったらSQLModelも使ってみたくなったので調べてみた(テストまあまあ盛り) - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    PythonのFastAPIをLambdaで動かそうと思ったらSQLModelも使ってみたくなったので調べてみた(テストまあまあ盛り) - Qiita
    sh19910711
    sh19910711 2024/06/17
    "SQLModel: Pythonの型アノテーションに基づき、PydanticとSQLAlchemyを利用 + 直感的で使いやすく、互換性が高く、堅牢になるように設計 / async sessionにも対応しており、FastAPIと一緒に利用すると作業が捗りそう" 2022
  • Playwright for PythonでPytestコードが生成できるようになった - Qiita

    サマリ 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

    Playwright for PythonでPytestコードが生成できるようになった - Qiita
    sh19910711
    sh19910711 2024/06/17
    "Playwright for PythonのVer.1.22からPytestコードが生成(codegen)できるように / Recordボタンが赤になった状態でブラウザ操作をすると自動でPytestのコードが記載 / PWDEBUG: Playwright Inspectorをデバッガとして起動" 2022
  • GraphQL Meshを使ってMySQLのDBをGraphQLで操作してみる - Qiita

    はじめに GraphQL Meshとは複数のバックエンドサービスを束ねるGraphQLゲートウェイを構築するためのフレームワークです。GraphQL Mesh自体についての詳細は、数多くの記事が世の中にあるため省きます。 今回はGraphQL Meshを利用して、MySQLをラップしてGraphQLで扱う方法について試していきます。GraphQL Meshを経由して扱うことで、スキーマを自前で用意せずに既に存在するDB情報から自動で生成して取り扱うことができるようになります。 ローカルで動かすまでの手順 今回はローカルのdevサーバーとしてGraphQL Meshを立てて、任意のMySQLDBを操作するところまで試します。 準備しておくもの ローカルからアクセス可能なMySQLサーバー 検証用に適当なデータベースとテーブルを作っておく 今回はMySQL8.0を使っています 必要なパッケー

    GraphQL Meshを使ってMySQLのDBをGraphQLで操作してみる - Qiita
    sh19910711
    sh19910711 2024/06/17
    "GraphQL Mesh: 複数のバックエンドサービスを束ねるGraphQLゲートウェイを構築するためのフレームワーク / スキーマを自前で用意せずに既に存在するDB情報から自動で生成して取り扱うことができる" 2023
  • GraphQL クライアントではクエリインジェクションに注意しよう - Qiita

    発端 GraphQL API の利用者から API クライアントのコードレビューに付き合ってほしいと言われたので出席したんですが、とんでもない実装になっていて腰を抜かしてしまったので、注意喚起しようかなと。 はじめに結論 クエリの一部にユーザ入力を文字列連結するのはやめましょう! 動的パラメータは variables で指定しましょう。 variables の指定例は以下を参照。 https://graphql.org/learn/serving-over-http/#post-request ポピュラーな GraphQL クライアントであれば、 variables に当たる変数を渡すことができるインタフェースが用意されていると思います。 インジェクションが起きる仕組み 実装言語は何でも良いです。 以下のような API クライアント実装があるとします。

    GraphQL クライアントではクエリインジェクションに注意しよう - Qiita
    sh19910711
    sh19910711 2024/06/17
    "クエリの一部にユーザ入力を文字列連結するのはやめ / 動的パラメータは variables で指定しましょう / ポピュラーな GraphQL クライアントであれば、 variables に当たる変数を渡すことができるインタフェースが用意されて" 2023
  • PostgreSQLとPostGraphileでサクッとGraphQLエンドポイントを作成する - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    PostgreSQLとPostGraphileでサクッとGraphQLエンドポイントを作成する - Qiita
    sh19910711
    sh19910711 2024/06/16
    "PostGraphile: テーブル、列、インデックス、リレーションシップ、View、型、関数、コメントなどを自動的に検出 + 自動的にGraphQLエンドポイントを作成 / DB定義を更新すると、GraphQLスキーマが自動生成される" 2019
  • Goで始めるGraphQL Federation - Qiita

    この抜粋の内容は次のとおりです。 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 について見て

    Goで始めるGraphQL Federation - Qiita
    sh19910711
    sh19910711 2024/06/16
    "Go による GraphQL Federation + Gateway として、Bramble / 複数のドメイン業務を扱う場合、各チームは独立して自分たちの GraphQL サービスを開発するため、Supergraph(GraghQL Federation)にしていく必要がある" 2023
  • ヘキサゴナルアーキテクチャでハイブリッドな GraphQL + REST API ゲートウェイを実現する - Qiita

    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 + REST API ゲートウェイを実現する - Qiita
    sh19910711
    sh19910711 2024/06/16
    "GraphQL サーバーと REST API サーバーのコードを共通化したい / マイクロサービスを実践することは開発組織の習熟度や所属エンジニアのスキルなど中々ハードルも高く + モノリシックなアプリケーションから始めたい" 2023
  • 比較的簡単にできるGraphQLのパフォーマンス改善 - Qiita

    はじめに 最近フロントエンドの通信をGraphQLに統一すべく頑張っているのですが、元々フロントエンドメインで開発していたのもありパフォーマンス度外視のBFF実装をしてしまいました。今回はGraphQLのパフォーマンス改善のために取り組んだこと2つをまとめていきたいと思います。2つしか書かない分できるだけ丁寧に書いたつもりです。普段BFFをGo言語で実装してるためサンプルコードはGo言語で書きますが、Goがわからない人にもわかりやすく説明するので最後までお付き合いいただけると幸いです。 触れること 取得するフィールドの制限してオーバーフェッチングを防ぐ Dataloaderを利用したN+1問題の解決 触れないこと GraphQLの基礎的なこと スキーマ設計とか 外部ツールを導入して計測をしたりだとか 現状そこまでしてパフォーマンス改善を行なった経験がないため 導入コストが高そうなので今回は

    比較的簡単にできるGraphQLのパフォーマンス改善 - Qiita
    sh19910711
    sh19910711 2024/06/16
    "DataLoader: 短い時間内に同じリソースへのアクセスを「バッチ化」することで、複数のリクエストを一度のリクエストにまとめて処理し、データベースへのアクセス回数を大幅に削減" 2023
  • 初めての Relay Connection によるページネーション実装 - Qiita

    前期に初めて Relay Connection を使ったページネーション実装を行いました。 実装要件の制約もあり、その良さを最大限に生かした実装にはならなかったものの、カーソルベースのページネーションの考え方や Connection の仕様など、個人的に新しく学ぶことができました。 実際の実装イメージともに、それらの学びをまとめとして共有したいと思います。 前提 ページネーションの実装方式 そもそもページネーションの実装にはいくつか方法があり、代表してオフセットベースとカーソルベースがよく取り上げられます。 それぞれ得意とすることが異なるため、適材適所で使い分ける必要があります。 オフセットベースページネーション (offset-based pagination) SQL の OFFSET/LIMIT 句を使ったページネーション方式です。 データの先頭から数えて offset で指定した数

    初めての Relay Connection によるページネーション実装 - Qiita
    sh19910711
    sh19910711 2024/06/16
    "ページネーション: 一般的にはページ番号を指定して任意のページに遷移させる必要がある場合はオフセットベースのページネーションが使われることが多い / 指定のページに到達するまでの全行を数える必要がある" 2023
  • Goで学ぶGraphQLサーバーサイド(8)ーN+1問題の回避 - dataloaderの導入 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    Goで学ぶGraphQLサーバーサイド(8)ーN+1問題の回避 - dataloaderの導入 - Qiita
    sh19910711
    sh19910711 2024/06/16
    "SQLBoilerによって発行されているSQLクエリをログに出力して残すオプションがある / DataLoaderを使って、先ほどのような「Issueの作者(ユーザー)の情報をN回取得するときに、DBにselectクエリがN回飛ぶ」状況を回避" 2023