Building Protocols with HTTP
Workgroup: HTTP Internet-Draft: draft-ietf-httpbis-bcp56bis Obsoletes: 3205 (if approved) Published: 22 March 2022 Intended Status: Best Current Practice Expires: 23 September 2022 Author: Building Protocols with HTTP Abstract Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new applicati
OpenAPI Generator と TypeScript で型安全にフロントエンド開発をしている話 - SmartHR Tech Blog
こんにちは、SmartHR でフロントエンド開発を担当している @Tokky0425 です。 この記事では、私のプロダクトでの OpenAPI Generator を使ったフロントエンド開発の取り組みを紹介していきます。 目次 OpenAPI とは 「ラクラク分析レポート」の DX 上の課題 OpenAPI Generator とは 実際に generate してみる 生成ファイルを使ってみる 型情報を出力してみる 組み込み・運用の工夫 chokidar で監視する lint-staged に組み込む メリット・デメリット メリット デメリット まとめ OpenAPI とは OpenAPI とは、「REST API のドキュメントの記述形式を定めた仕様」のことを指しています。 簡単な例ですが、下記のような YAML ファイルがあるとします。 schema.yml paths: "/some
Javaのエンジニアだった私がGo言語でREST APIを作る上で学んだことをまとめています。 プロジェクト構成、単体テスト、Dockerイメージの作成など実際にREST APIを開発する上で必要だと思われる要素を盛り込みつつサンプルプロジェクトを作成していきます。 はじめに Javaのエンジニアだった私がGo言語でREST APIを作る上で学んだことをまとめています。 プロジェクト構成、単体テスト、Dockerイメージの作成など実際にREST APIを開発する上で必要だと思われる要素を盛り込みつつサンプルプロジェクトを作成していきます。 今回はできるだけ外部ライブラリやフレームワークを使わずにGo言語の標準機能のみで開発しました。 これからバックエンドにGo言語を使用することを検討されている方の参考になれば幸いです。 ※この記事は既にGo言語の開発環境をセットアップ済みで基本的な文法を学
2021年6月2日に行われたSendai Frontend Meetup #6で使用したスライドです。 GitHub サンプルコード https://github.com/KanDai/openapi-sample ReDocで生成されたドキュメント https://kandai.github.io/openapi-sample/ About Swagger Specification https://swagger.io/docs/specification/about/ Swagger Editor https://editor.swagger.io/ Stoplight Studio https://stoplight.io/api-design/ Swagger UI https://petstore.swagger.io/ Redoc https://github.com/Red
レッドハットでインテグレーションのためのミドルウェアのテクニカルサポートを担当している山下です。 最近はマイクロサービスでシステムを開発しているという話もよく聞くようになってきました。ではそこでメッセージング、そしてKafkaを使ってますでしょうか？マイクロサービスでは何故かRESTばかりが世の中に注目されてしまうことも多いために、今回はメッセージング推しの内容にしています。 マイクロサービスではメッセージングを用いたコマンドやイベントこそ中心であって不可欠です。マイクロサービスの中でメッセージングはどのように利用され、そしてなぜ必要なのでしょうか。今回は「マイクロサービスとメッセージングのなぜ [概要編]」と題してそれを概観していきます。 Kafkaの簡単なおさらい どこでメッセージングは利用されるのか？ RESTはお手軽な解決策？ なぜマイクロサービスにメッセージング(Kafka)が必
![マイクロサービスとメッセージングのなぜ [概要編] - 赤帽エンジニアブログ](https://cdn-ak-scissors.b.st-hatena.com/image/square/707ca04fc1adae69cf6e76dabc92e34469792eec/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Ft%2Ftyamashi-oss%2F20190724%2F20190724112428.jpg)
はじめに 自分は実務でReact×TypeScriptを利用したフロント周りとNode.js(Nest)やRailsを用いたバックエンド(API)の開発をしています。 本記事では、OpenAPIを用いたAPI設計の書き方及び、Swaggerの説明と使い方についてまとめていきます。 この記事の対象者 プログラミング初心者から中級者 APIの基礎を理解している人 OpenAPIを用いてサクッとモックサーバーを試したい人 この記事の目標 モックサーバーの環境構築を学ぶ Swaggerの使い方を理解する OpenAPIを用いてAPI設計の具体的な書き方を学ぶ この記事でやらないこと 本記事ではOpenAPIの「書き方」をメインで解説するため、API設計についての細かい解説は省きます。 なおAPI設計については下記の記事でまとめているので、ぜひ参考にしてみてください。 用語解説 OpenAPI 公式
こんにちは、エンジニアリンググループの福林 (@fukubaya) です。 先月から、今年の秋くらいにリリース予定の新サービスの設計、開発を始めました。 せっかく新しく始めるサービスなので、まだ経験したことがない言語やフレームワーク、技術を使わないと楽しくありません。 そこで、バックエンドにGoにして、フロントのAPIまで含めてgRPCの .proto ファイルで定義を一元化し、APIコードは protoc で生成させる計画を立てていたのですが、 フロントでgRPCとなると、 gRPC-web か grpc-gateway になるが、リリースまでに使える期間では認証も含めると検証が間に合わなさそう Goだけでなく、terraform(インフラ設計もやります) も Vue.jsも今回が初めて、というメンバーもおり、さらにRESTではなくgRPCも、となると未経験技術が多すぎてキャッチアップが
はじめに こんにちは、retail HUBで Software Engineer をしているほんだです。 今回は私が現在着手している事業譲渡されたアプリを社内で持続的なプロダクト開発を行える状態にするリプレイスプロジェクトをどのように行っているか紹介しようと思います。 この記事ではリプレイスを行うにあたってどのようなことを課題に感じてその課題に対してどのような解決策をとったか主にサーバーの実装について説明しています。 ネットスーパーアプリとは 現在弊社ではネットスーパーアプリとして Web アプリとスマホアプリの二つのシステムを提供しています。 Web アプリは販促コンテンツの設定や売り上げの管理・集計を行うことが可能な管理システムと受け取り方法に応じた価格変更や送料変更にも対応し、消費者の柔軟な買い物を実現するお客様向けアプリを 17 の小売り様に、スマホアプリでは Web アプリのお客
続：Postman 使ってたけど VSCode の REST Client に乗り換えた - かずきのBlog@hatena
超適当に書いた記事に限ってブクマが伸びる件について。400超えって…。 REST Client って自分の用途的には、非常にシンプルな REST API を Visual Studio Code を使う機会が多い環境で別途ソフトウェアを立ち上げることなくテストできて、しかもテキストファイルに保存しておけるという点がポイント高い感じでした。 blog.okazuki.jp とまぁブクマがたまると何がいいって自分ならこうしてるという意見がたくさん拾える！！ということで気になったものをいくつか試してみたいと思います。 Chrome の Copy as cURL Chrome の開発者ツールの Network タブで Copy as cURL で curl コマンドがクリップボードに貼られるので、それを使うとクッキーとかも継続出来て便利！！ cURL 以外にも色々あるんですね…知らなかった。 とり
Intro 最近とあるデータベースに関する記事を読んだのですが、Upstashについて誰も言及しておらずヤバいなと思ったので紹介することにしました。 ちなみに私も今日はじめてアカウント登録するのでご安心ください。 ゴールデンウィークは色々始めたくなるものです。 Upstashはサーバーレスデータベースを提供するサービスです。 Redisを主に扱っていますが一応Kafkaも使うことができます。 詳しく調べた感じだともう一つぐらい使えるデータベースが増えそうな気がしたので様子見していたのですが、 3月中旬に約2.3億円の資金調達を行いしばらくは既存サービスの強化を行うようなのでとりあえず使ってみることにします。 Upstash 様々な特徴がありますが特筆すべき点として、AOFモードで永続性が常に有効になっている点が挙げられます。 つまりRedisでありがちなキャッシュやエフェメラル用途で使える
[Python]原文 What's new in Python 3.8? - DeepSource (English) 原文著者 Sanket Saurav 原文公開日 2019-07-26 翻訳依頼者 翻訳者 hiroya 翻訳レビュアー doublemarket msh5 meiq 原著者への翻訳報告 1415日前 原文へのコメントで報告済み 1415日前 原著者承諾済み 編集 はじめに もうすぐPythonの最新バージョンのベータ版が公開される予定です。最終の安定版が利用可能になるまでは、もう少し時間がありますが(リリーススケジュールはこちら)、どのような新機能が追加されているのかを調査することには十分価値があります。Python 3.8 では、言語としての構文の追加、既存の挙動に関しての軽微な変更、そして全体的な速度の改善が追加されています。これらの変更は、以前の3.7のリリースま
誰もがその戦いの背景にある歴史の深淵と人々の覚悟を見誤っていた。開戦初日に決着が付くと高を括って鼻歌混じりに筆を取った私は、気が付けば夏休みの８割を喪失し、すべての指が腱鞘炎で悲鳴を上げる中で参考文献の海に這いつくばっていた。 —— Josh Nobus —— ぜんぜんわからない 俺たちは雰囲気で REST をやっている 何度調べてもなんだかよく分からない概念ランキングの個人的 Top5 に入る言葉。 それが「REST」だ。 いろんな Web サービスの REST API はよく使わせてもらっているし、REST API が何かと聞かれれば「その Web サービスの機能を HTTP リクエストで呼び出せる API エンドポイントのことだよ」みたいにそれっぽくお茶を濁すことはできると思うが、じゃあ自分で RESTful なサービスを作ってみろと言われたら私は作れない。作れなかった。 だってどん
Protocol Buffers によるプロダクト開発のススメ - API 開発の今昔 - | Wantedly Engineer Blog
こんにちは、Wantedly People アプリの開発をしている竹野（Altech）です。今回は、Protocol Buffers についての記事になります。 Wantedly People では、2018年に Protocol Buffers （以下、Protobuf と呼ぶ）がとあるマイクロサービスに入って以降、何度か大規模に Protobuf を使った開発をしてきました。またその経験を通じて、Protobuf には単に「型がついて嬉しい」というだけではないパラダイム的な変化があることが分かってきました。 その知見を全社に展開するため、去年「Protobuf によるプロダクト開発速習会」という会を行いました。この記事の内容は、そこで話したことの前半「Protobuf を使うと開発がどう変わるのか？」になります。 なお、Protobuf にはバイナリフォーマットとしての役割とインターフ
Supabase https://supabase.io/ Supabaseの特徴 「Supabase」は、既存のPostgreSQLデータベースをRESTful APIに変えるオープンソースおよび、それを使ったクラウドのDBサービスです。 https://github.com/supabase/supabase PostgreSQLの挿入・更新・削除をリッスンするElixirサーバーで、Webソケットを介してJSONをブロードキャストするのが、Supabaseの中核的な役割になります。今回は、そのSupabaseが提供するクラウドDBサービス（アルファ版）を使って、RESTful APIを試してみました。 SupabaseのクラウドDBを使ってみる サインアップが完了したら、基本情報として組織と プロジェクトを登録します。 登録が完了すると、作成されたデータベースの接続情報が表示されます
こんにちは、ritou です。 最近のあれこれでIDaaSと呼ばれる機能に注目が集まっているような気がしますが、どうしてもフロントエンドでの導入部分が目に付きます。 「新規サービスで使っていこう」ならまだしも「既存のを何とかしたい」みたいな場合にフロントエンドまでごっそり変えるのなんて腰が重くなって仕方ない感じでしょう。 そこで今回は、REST APIを用いた新規導入、移行というアプローチもあるのかなという話を書いておきます。 SPAとなると当然フロントエンドの振る舞いに注目されるけど、Deviseからの...を考える人たちはこの辺りから攻めるのもアリかと思う。ちゃんと整理して考えよう。https://t.co/fwhoA6wtjx— 👹秋田の猫🐱 (@ritou) 2020年8月19日 IDaaS の REST API この辺りをみてみてはどうでしょう。 Firebase Authe
はじめに 最近のウェブアプリではバックエンドをREST-APIとして用意し、 フロントエンドはREST-APIから引っ張ってきたデータをReactやVueといったフレームワークで描画することが多いと思います。 このようなウェブアプリを開発する際に問題となるのはバックエンドとフロントエンドを並行して開発しにくいということです。バックエンドができなければフロントエンドはどんなデータが来るのかわからず描画できませんし、バックエンドもフロントエンドからどのようなリクエストが来るか決まらないと実装ができません。 そのため、最初にREST-APIの仕様を定めて、その仕様に沿ったモックサーバを作成し、 フロントエンドはバックエンドが完成するまでそれを用いて開発を進めるということが行われます。 さてそのREST-APIの仕様とはどのように記述されるのでしょうか？ 1. 自然言語で記述する 一番よくある場合
Golang GenericsでREST APIを作る - Nature Engineering Blog
Go 1.18が出てしばらく経ちました。みなさんGenerics使っていますか？ @maaashです。 これは Nature Engineering Blog祭 の2日目の記事です。 祭り 最初は歓喜し、mapやfilter的なfor文を少しずつgithub.com/samber/loに切り替えたり、 internalなsliceパッケージを作ってみたり。 ですが心のどこかで欲求不満が蓄積されていくのを感じていました。 使い尽くしていないのでその真価が理解できていなくて物足りないような、 こんなに面白いおもちゃが与えられたのに遊び尽くしていないような感覚です。 Genericsを使ったコードを書きたい！と思いながら日々の業務でREST APIを書いていると、、 あれ、これはかの When To Use Genericsの結論にある: If you find yourself writing
グラフモデルとSoEとGraphQL / TECH STAND #7 GraphQL 2022/03/03 に行われた stand.fmさん主催の TECH STAND #7 にて上記のタイトルで登壇しました。 今回の内容は GraphQLの採用を検討するにあたって、RESTとの違い、BFFとの違いをデータの観点から言語化したかった Hasuraが良いという意見と, Apolloやgraphql-ruby, gqlgenなどのハンドライティングなGraphQLが良いという意見の違いがどこから生まれているかの考察がしたかった データ指向アプリケーションデザイン(2017年リリース)にSoEやGraphQLへの言及がないため, 今だとこういう内容が書かれているんじゃないかという考察がしたかった をモチベーションに調査・検討しました。 発表のハイライトはこちらです。 以下発表内容です。一部発表時
NEWS: htmx finished 2nd in the 2023 JavaScript Rising Stars "Front-end Frameworks" category, just behind React (htmx is a library, btw) and #10 overall! Thank you to everyone who starred us! introduction htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hyper
GithHubは、今後はAPI仕様を記述する業界標準であるOpenAPIに対応した生成ツールで生成したAPIクライアントをSDKとして提供することを明らかにしました。 現在まで同社は「Octokit」と呼ばれるSDKを提供しています。これはGitHubの開発者が、外部のアプリケーション開発者のために、さまざまな言語でGitHub APIを呼び出しやすいように開発したライブラリと言えます。 それに対して今後は、GitHubのAPIがどのような仕様であるかを業界標準であるOpenAPIに従って記述したドキュメントを基に、そこからAPIクライアントを生成するツール「Microsoft Kiota」によって生成したAPIクライアントをSDKとして提供することになると説明されています。 GitHubはこれを同社にとって大きな転換点だと、ブログ「Our move to generated SDKs」（
Yasoob Khalidのブログより。 皆さん、こんにちは! 👋 この土曜日に行われたSpaceXの打ち上げをご覧になった方も多いのではないでしょうか。それは驚くべき、歴史的な出来事でした。何百万人もの人々がYouTubeや他の場所でその様子をライブで見ていました。日を追うごとに、私たちは商業宇宙飛行に近づいており、私は興奮していることに同意しなければなりません。 この打ち上げは、宇宙旅行に対する興奮を煽るだけでなく、これらのロケットに搭載されている技術にも興味が湧いてきました。コンピュータ・サイエンスの観点からいくつか調べてみましたので、その結果を共有したいと思いました。言うまでもなく、これらの情報のほとんどは、私がオンラインで見付けた様々な情報源から集めたものです。間違った情報が含まれないように努めましたが、この情報が100%正確である保証はありません。 チーム 7年前、Space
Kaigi on Rails 2023の登壇資料です。 https://kaigionrails.org/2023/talks/moro/ 実世界のRailsアプリケーションをシンプルに保つための方法を、Railsが提供する機能群をもとに考察します。 実世界の、特に仕事で開発するRailsアプリへの要求は様々のものがあり、Railsの豊富な機能群をもっても日々苦労して開発しているかと思います。 そんな中でも、Railsが得意とするような設計に落とし込むことで、複雑な要求をシンプルな実装で実現できると感じています。 本講演では、Railsが提供する機能のうち、「RDB」「REST」「Ruby」という要素を軸に、実世界の要求をシンプルに実装するための考え方を紹介します。
Solutions for API Design and Management | Stoplight
API excellence made easy.All of the benefits of innovation without the headaches. Create a Successful API ProgramTake a proactive approach with your API programs to efficiently create consistent productivity and avoid the underbelly of delays and overages. Reduce Risk and Improve ROIConnected Software is mandatory for today’s consumers. Avoid disorganized development efforts that cause significant
郵便番号APIのようなシンプルなREST APIをlambdaで作る時にマスターデータを何で持つべきか計測してみた
こういうAPIを作らなければいけないときって割とよくあると思います（有料データベースと契約してて、csvでもらったデータをAPIで使えるようにするとか） そんな時に一番シンプルな解決方法として思いつくのがaws lambda + API Gatewayになると思います そんな時にふとした疑問が生まれました 元のcsvって何の形式で持つのが一番効率良いのだろう こういうのって何となく適当に選んじゃうことが多いのですが実際に計測して選ぶことも大切なので色々計測してみました 別解 多分goあたりでプログラム本体に含めてコンパイルしちゃうのが早いと思いますが、今回はrubyでやりたかったのでそれ以外の解決策を考えてみます 準備 郵便局の出している住所 <-> 郵便番号データをサンプルとして使います 元データがcsvなのですがその時点で以下のようになっています 行数：12万4500行 ファイルサイズ
import { asApi, Zodios } from '@zodios/core' import { z } from 'zod' const vR1x0k5qaLk = z.object({ id: z.number(), name: z.string() }).partial() const v8JbFEq2fUl = z.object({ id: z.number().optional(), name: z.string(), category: vR1x0k5qaLk.optional(), photoUrls: z.array(z.string()), tags: z.array(vR1x0k5qaLk).optional(), status: z.enum(['available', 'pending', 'sold']).optional(), }) const vlh
関連キーワード API | データ統合 前編「Netflixがクエリ言語『GraphQL』を採用 何にどう使っているのか」は、Netflixのコンテンツエンジニアリングチームに所属するギャレット・ハインレン氏が、同チームで使うデータ連携用のクエリ（データ操作）言語として「GraphQL」を採用した背景を説明した。一方でハインレン氏のチームは、依然としてスキーマ管理、エラー処理、分散書き込みなどの問題に直面している。「GraphQLはクエリとAPI（アプリケーションプログラミングインタフェース）構築のプロセスを簡略化するが、特効薬ではない」と同氏は言う。 ハインレン氏はGraphQLを受け入れるまでに数カ月を要した。受け入れた理由は、テクノロジー面でのメリットがあるからというよりも「チームと組織の行動やコミュニケーションを改善するためだった」と同氏は明かす。同氏によればGraphQLは、スキ
この記事はGraphQL Advent Calendar 2021の22日目の記事です。 またこれは書籍、出来る100%TypeScript 作って学ぶNext.js + GraphQL + Prismaに掲載していたコラムに加筆修正を行ったものです。 GraphQLは一言でまとめてしまえばDSL(GraphQL query language)による宣言的な記述を介してGraphQLサーバーから柔軟にデータを取得/提供する事が出来る仕組みです。文法は全く異なりますが動作モデルとしてはSQLとRDBの関係に近いかもしれません。なおHTTP上で利用される事がほとんどですが特に決まりがあるわけではありません。 元々はFacebook社(現Meta社)で開発され2012年からfacebook.comで利用されている技術で、その後2015年にはオープンソース化されFacebook以外でも徐々に利用さ
googleからタイトルについて書かれた記事が出たので読んでいた cloud.google.com これらについて自分でもなんとなく考えていたことがあったけれど良い機会なのでまとめておく 記事での注目ポイント 冒頭より引用。 私としては、HTTP を使用する API のビルドには、重要かつ特徴のあるアプローチが 3 つあると考えています。次のようなアプローチです。 1. REST 2. gRPC（および Apache Thrift など） 3. OpenAPI（およびその競合製品） なるほど、と思うかもしれないが、読み進めていくとRESTについてはこう書かれていた。 このスタイルの API の特徴的な性質は、クライアントが他の情報から URL を構築せず、サーバーから渡された URL をそのまま使用することです 何の話かと思ったけれど、REST APIにはLv3までありこの記事ではLv3の
一行要約 はじめに Readable OpenAPIとは? 既存ルールの不満点 不満点1: 標準仕様外の分割を行っている 不満点2: ディレクトリ階層が深い 不満点3: 1つのAPI定義を参照する際にたくさんのファイルを参照する必要がある 不満点4: コンポーネントスキーマの同一性が不明瞭 新ルールで工夫した点 工夫1: operationIdと対応したパス定義のファイル名を採用し、フラットなディレクトリ構造を実現した 工夫2: パス定義ファイルに含まれる情報量を増やした 工夫3: 再利用性を重視したcomponent定義 できなかったこと、やらなかったこと、やりたいこと 定義ファイルのhttpメソッドごとの分割ができなかった ルートの定義ファイルにcomponentディレクティブを置かなかった exampleの定義は余力があればやりたい おわりに We are hiring! 脚注 一行
REST API Design Best Practices Handbook – How to Build a REST API with JavaScript, Node.js, and Express.js
I've created and consumed many API's over the past few years. During that time, I've come across good and bad practices and have experienced nasty situations when consuming and building API's. But there also have been great moments. There are helpful articles online which present many best practices, but many of them lack some practicality in my opinion. Knowing the theory with few examples is goo
はじめにOpenAPI仕様に則ってREST APIの設計をする際に、値が存在しないという状態をどのように表現するかというお話です。 undefinedとはまずはじめに、ここでundefinedと言っているのは、OpenAPIの仕様において、リクエスト/レスポンスのデータ型を定義するSchema Objectのプロパティの1つであるrequiredが指定されていない状態を指します。 OpenAPIにおけるrequiredの定義を確認してみましょう。 OpenAPIの仕様を参照すると、Schema ObjectはJSON Schemaの仕様に従うと記載されています。 The Schema Object allows the definition of input and output data types. These types can be objects, but also primit
（株）ライトコードの笹川（ささがわ）です 今回も、Go言語（Golang）を習得していきたいと思います。 引き続き、Firestoreを利用して色々とやってみようかと思います。 Firestoreをデータストレージ、GolangをAPIとした場合は、どこかにデプロイしてから使うことが想定されます。 そのため、今回はデプロイする前にREST APIとして使えるようにしたいと思います。 ちなみに、RESTにした理由は特にありません（笑） 入門編のゴールとしては、Androidアプリとの結合を目論んでいるので、「RESTでいいなぁ」と難しいこと考えずに思った次第です！
初めてのGraphQL
今日では多くのWebサービスがRESTアーキテクチャスタイルで実装されています。RESTは2000年にフィールディングの論文で提唱された後に爆発的に普及し洗練されてきました。一方で、本書で紹介するGraphQLは2015年にFacebookによって公開されたRESTとは異なるアプローチのアーキテクチャです。GraphQLの最大の特徴はクエリ言語を用いてデータを操作する点です。クエリ言語の表現力の高さによりクライアントは本当に必要なリクエストを送ることができます。本書ではGraphQLの概要とGraphQLを用いたWebサービスの開発方法を実装例に沿って紹介します。認証やファイルアップロードといった実践的なトピックまで踏み込んだGraphQLの実用的な入門書です。 関連ファイル サンプルコード 正誤表 ここで紹介する正誤表には、書籍発行後に気づいた誤植や更新された情報を掲載しています。以下の
Help us understand the problem. What is going on with this article? これはなに？ 先日投稿した君はまだ平成のアーキテクチャを使ってるのか？僕はFirebaseと令和の時代に行くぞ。の続きです。 思っていたよりもたくさんのフィードバックを頂いて驚いています。ありがとうございます。 伝えたいことが伝わっていてよかったなと思う一方、記事の内容の設計が微妙だったなという感じのご指摘もいただきました。この記事では、前回の記事を読んでいただいたみなさんが抱いたであろう疑問・懸念にお答えすることができればと思っています。 この記事だけ読んでもおそらく何の話かわからんとおもうので、先に前回の記事を読んで頂くと良いと思います。 Firebaseって銀の弾丸なの？ 違います。 先の記事から引用しておきます。 大切なことは、解決したい問題を明ら
経緯 ここ6,7年くらいはバックエンドに関してはRails + EC2/ECSあたりのAWS環境を中心に過ごしてきたが、昨今はフロントエンドでReact/Vue + TypeScriptを書く機会も増えている。なのでこの際NestJS等でバックエンドを書けるようになれば言語のコンテキストスイッチの切り替えが容易になりそうと思った(ちなみにモバイルアプリはFlutterで書くのでDartだが、ではDartでバックエンドを書くかと言われると一人でそんな勇気はないわ...となるのでひとまず置いておく) 最近はinputとoutputを型注釈によって守れたりすることの主に開発体験方面への恩恵が個人的に大きくて、Rails以外で安住の地を見つけたいとは予々思っていた。なので先に挙げたNestJSに全ベットするわけではないにしろ何かしらフレームワークは試していきたい。 AppEngineは大昔に少し触
こんにちは、ティアフォーで認証認可基盤を開発している澤田です。 最近取り入れたProtobufで、素晴らしいREST APIの開発体験をしたのでご紹介します。 なお、ティアフォーではマイクロサービスを支える認証認可基盤を一緒に開発いただけるメンバーを募集しています。ご興味のある方は下記ページからご応募ください。 herp.careers 実現したかったこと マイクロサービス間連携のAPI開発において、以下の条件を満たすやり方を探していました。 スキーマを最初に定義してリクエストとレスポンスの型が自動で生成される ドキュメント（openapi.yaml）が生成される バリデーションが定義できて、その実装が自動で生成される 実現方法 Go言語で開発する場合はgo-swaggerでも実現できますが、本記事では、Protobufで実現できるgRPC Gatewayとprotoc-gen-valid
銀の弾丸ではないので良し悪しあるのは当然として、それを差し引いても以下の2つの要素があるのではと思った。 なんとなく使ってもメリットが十分得られない RESTでできてたことができなくなる（※ちゃんと調べればできる） なんとなく使ってもメリットが十分得られないWeb界隈は良くも悪くも新しい技術をとりあえず使ってみるところがあると思っていて、そこがGraphQLは十分に事前知識を持って導入しないとメリットが薄いところとミスマッチを起こしてネガティブな意見が出るのかなと思う。 GraphQLはもともとFacebookがReact, Relayとの組み合わせで使い始めたもので、クライアントライブラリとしてのRelayと、IDやページネーションについての追加仕様を公開している。ライブラリとしてのRelayは使わなくても仕様に乗っかることはできるのでそれをRelayスタイルと言ったりする。出典を忘れた
Move Fast and Break Nothing. End-to-end typesafe APIs made easy.Experience the full power of TypeScript inference to boost productivity for your full-stack application.
HTML+JavaScriptでこれから始める、REST APIを利用したアプリ開発 第3回目／Webサービスとブラウザをつなぐ機能「Fetch API」 - MdN Design Interactive
HTML+JavaScriptでこれから始める、REST APIを利用したアプリ開発 第3回目／Webサービスとブラウザをつなぐ機能「Fetch API」 新規会員登録 ログイン管理 Twitter facebook はてなブックマーク RSS 2023.6.2 FRI
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Go言語で基本的なCRUD操作を行うREST APIを作成 | DevelopersIO
OpenAPIを使ってAPIドキュメントとモックサーバーを良い感じにした話
マイクロサービスとメッセージングのなぜ [概要編] - 赤帽エンジニアブログ
OpenAPI (Swagger) まとめ - Qiita
APIのコードを自動生成させたいだけならgRPCでなくてもよくない? - エムスリーテックブログ
ネットスーパーアプリ GraphQL から REST へ移行始めました - every Tech Blog
無料で使えるデータベースUpstashをご存知、ないのですか！？
Python3.8の新機能 | Yakst
すべての Web サービス設計者に捧ぐ「RESTful って結局なんなんだ」
オープンソースのFirebase代替プロダクト「Supabase」 - ITnews
認証機能を独自実装する代わりにIDaaSのREST APIを使うアプローチ - r-weblife
REST APIを簡単にMockできるツールSmopeckの紹介 - Qiita
データ指向アプリケーションデザインから見るGraphQL
</> htmx - high power tools for html
GitHub、SDKを刷新。今後はOpenAPI仕様の生成ツールで生成したSDKを提供へ
ブログ: SpaceX内部のソフトウェア・エンジニアリング
Simplicity on Rails -- RDB, REST and Ruby
OpenAPI + Zod で型安全な API クライアント出力
Netflixが「REST」をやめて「GraphQL」に乗り換えた理由
なぜGraphQLを採用するべきなのか、あるいはなぜ採用するべきではないのか 2021冬
API設計：REST、gRPC、OpenAPI - 気まぐれ開発日記
ReadableなOpenAPI定義ファイルを書く - ドワンゴ教育サービス開発者ブログ
OpenAPIにおけるundefinedとnullの設計 | フューチャー技術ブログ
【第4回】Go言語（Golang）入門～REST API環境構築編～ – 株式会社ライトコード
Firebaseを採用する上で思っていることをちゃんと書く - Qiita
NestJS + Prisma + Cloud Run + Cloud SQLを試す
ProtobufでREST APIを快適に開発する方法のご紹介 - TIER IV Tech Blog
https://twitter.com/iwashi86/status/1547051699503857667
GraphQLのよくないところ｜adwd
tRPC - Move Fast and Break Nothing. End-to-end typesafe APIs made easy. | tRPC