このデックでは、エラーレスポンス設計から考える、プロダクトの0→1開発におけるGraphQLへの向き合い方について紹介します。 記事: 【技術選定】 0→1 の SaaS に…

この記事はTSKaigi2024での以下の私の発表内容を書き下ろしたものです。 なぜAPIに型をつけたいのか 現代のWebのシステム開発において、クライアント・サーバーともに型のある言語で開発されることが増えてきました。静的な型検査はコードの堅牢性やよりよいメンテナンス性の向上をもたらします。 プログラミング内部だけで型検査をするだけでも十分メリットはありますが、外部I/Oに対する型付けが不十分だとそのメリットを最大限に発揮してるとは言えません。外部I/Oとは、例えばWebフロントエンドだとLocalStorageやDOMからの入力値、それからネットワーク通信(今回はこれをAPIと呼びます[1])などですね。サーバー側でいうとAPIからの入力・レスポンスやデータベースへの読み書きが該当します。 個人的な経験から言うと、Webシステムの開発におけるエラーの多くはAPIやデータベースとのやり取
皆さんこんにちは。これは、筆者が最近公開したnitrogqlを宣伝する記事です。nitrogqlの概要や、開発にあたっての裏話などを紹介します。 nitrogqlとは nitrogqlは、TypeScriptコードからGraphQLを使用するためのツールです。有体にいえば、graphql-code-generatorを置き換えることを目指して開発しています。具体的には、.graphqlファイルからTypeScriptの型定義を生成する機能を備えています。 例えば、次のようなクエリがあったとします。 query ($unfinishedOnly: Boolean) { todos(filter: { unfinishedOnly: $unfinishedOnly }) { id body createdAt finishedAt tags { id label color } } } imp
graphql-codegen で型定義を生成する (React, Apollo, TypeScript)TypeScriptReactGraphQLapollo 本記事はこのリポジトリでやったことのまとめです。 GraphQL + TypeScript への課題感 TypeScript(に限らず他の静的型付の言語) と GraphQL を使うと、型の二重定義が発生がちです。折角 GraphQL に通信規約としての型を書いているのに、それを多重定義することで、運用の面倒臭さやバグの温床になりかねない、という懸念がありました。 今回は、graphql のスキーマとクエリを書くと、サーバー向けに resolver の型定義、クライアント向けにクエリの型定義を生成し、それによってできるかぎり型安全なコードを扱うのをゴールとします。 やり方 graphql-code-generator を使います
追記: 2021年6月現在はアーキテクチャが変わってきています。 次の記事に詳細を書いていますので、一読をお願いします。 Kaizen Adのフロントエンドアーキテクチャの遷移について - Kaizen Platform 開発者ブログ Kaizen Platform でフロントエンドエンジニアをしている山本です。この記事では、我々が運営するサービス「Kaizen Ad」のフロントエンド部分をご紹介します。 Kaizen Ad とは Kaizen Ad は、動画広告をサポートするマーケットプレイスです。 カスタマーがクリエイティブを依頼すると、広告クリエイティブを作成するグロースハッカーから動画広告クリエイティブが納品される仕組みです。 カスタマーにとってはクリエイティブ改善の運用を省力化できると同時に、グロースハッカーにとっても新しい働き方が創造できるソリューションとして提供しています。
Kaizen Platformでフロントエンド開発をやっているlacoです。 新規アプリケーション開発において、API仕様中心の開発スタイルを検討し、実験的に取り入れました。 本記事ではその概要と効果を紹介します。 API仕様中心開発 API仕様中心開発を取り入れようと思ったきっかけは、2017年のNode学園祭でpika_shiさんが発表した「JSON Schema Centralized Design」です。 JSON Schema Centralized Design - Speaker Deck Kaizen Platformではリモートワークで開発しているメンバーが多く、非同期にコミュニケーションをすることが多いので、生産性を高めるためには互いの作業を待たずに独立して分業できるワークフローが必要でした。 バックエンドAPIの実装を待たないとフロントエンドが実装できないような依存関
2017/07/18 Service Dev Meetup #1 の資料です。 会場は Speee さんに提供していただきました。ありがとうございました。 自己紹介 FUJI Goro / @__gfx__ ビットジャーニーのエンジニア 最近のスコープ: Ruby on Rails / TypeScript / React / GraphQL 情報共有サービス Kibela を開発してます 最近の発表: RailsエンジニアがReactを始めてSSRとReduxとTypeScriptを導入するまで 今日の話 Kibelaにおける技術選定とは やらないこと やったこと これからやること Kibelaにおける技術選定とは 自分(@gfx)にとっては技術的挑戦は精神衛生上必要なこと 興味のある分野に限るが… スタートアップにとってはサービスの成長が最も重要 技術的挑戦によって機能を磨いて差別化に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く