このデックでは、エラーレスポンス設計から考える、プロダクトの0→1開発におけるGraphQLへの向き合い方について紹介します。 旧タイトル: 「TypeScriptとGraphQLを活用した変化に強いプロダクト作り」。2024年9月9日(月) に更新しました。
![エラーレスポンス設計から考える、0→1開発におけるGraphQLへの向き合い方](https://cdn-ak-scissors.b.st-hatena.com/image/square/05ee33051d449b03a87c02b2ea62dcfd8c3c7aef/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F7e2ab79707764b5b9b6ac2f650aed02c%2Fslide_0.jpg%3F31648150)
このデックでは、エラーレスポンス設計から考える、プロダクトの0→1開発におけるGraphQLへの向き合い方について紹介します。 旧タイトル: 「TypeScriptとGraphQLを活用した変化に強いプロダクト作り」。2024年9月9日(月) に更新しました。
この記事はTSKaigi2024での以下の私の発表内容を書き下ろしたものです。 なぜAPIに型をつけたいのか 現代のWebのシステム開発において、クライアント・サーバーともに型のある言語で開発されることが増えてきました。静的な型検査はコードの堅牢性やよりよいメンテナンス性の向上をもたらします。 プログラミング内部だけで型検査をするだけでも十分メリットはありますが、外部I/Oに対する型付けが不十分だとそのメリットを最大限に発揮してるとは言えません。外部I/Oとは、例えばWebフロントエンドだとLocalStorageやDOMからの入力値、それからネットワーク通信(今回はこれをAPIと呼びます[1])などですね。サーバー側でいうとAPIからの入力・レスポンスやデータベースへの読み書きが該当します。 個人的な経験から言うと、Webシステムの開発におけるエラーの多くはAPIやデータベースとのやり取
イベント「【タイミー/Voicy/令和トラベル】Backend LT〜技術選定における“見極める力”とは〜」での登壇資料 https://reiwatravel.connpass.com/event/306794/
この記事は、昨日公開された次の記事の日本語訳です。nitrogql 1.1がリリースされresolver向けの型生成機能が使えるようになり、nitrogqlだけでサーバー側とクライアント側両方を型安全に書けるようになりました。元記事はこちらです。 本日、nitrogql 1.1をリリースしました! nitrogqlはTypeScriptプロジェクトでGraphQLを使うためのツールチェインです。1.1では、resolver向けの型定義の生成機能を追加しました。これにより、nitrogqlを使うことでクライアント側とサーバー側の両方で型安全にGraphQLを使うことができるようになりました。 nitrogql 1.1の新機能 nitrogql 1.1では、1.0の機能に加えて新たに2つのTypeScriptファイルを生成できるようになりました。 Resolverの型定義ファイルは、実装すべき
はじめに 私の仕事は、新規サービスをまるっといい感じに開発するのを委託されることがほとんどです。最近はネイティブアプリを作ることよりもブラウザで動くWebサービスを開発することが多いのですが、案件の規模感や要求によって技術選定を少し変えるようにしています。「こういうときはこう」みたいに一概には言えないのですが、普段使う構成を紹介します。誰かの参考になれば幸いです。 2022/02/10 現在での内容です。 前提 開発を委託される場合の運用費をどうするの問題があります。クライアントにクレカ登録をしてもらうか、こちらで支払って毎月請求するかになります。僕は毎月やるのがめんどくさいのでできるだけ前者に倒している関係上、あまりいろいろなSaaSを組み合わせて作ることをなるべく避けています。 規模感によらず使っているもの 私の場合、以下が使えるとめちゃくちゃ効率よく開発できます。 GCP 好きだから
JSConf JP 2021 で登壇した資料です #jsconfjp #jsconfjp_b Links: [Active Recordから考える次の10年を見据えた技術選定](https://speakerdeck.com/yasaichi/architecture-decision-for-the-next-10-years-at-pixta) [GraphQL を活用したスキーマ駆動開発の実践](https://speakerdeck.com/qsona/schema-driven-development-with-graphql) [GraphQL を利用したアーキテクチャの勘所 / Architecture practices with GraphQL - Speaker Deck](https://speakerdeck.com/qsona/architecture-pract
「Think ! FrontEnd by DMM」は、DMM Group のフロントエンド及び JavaScript における開発現場の「今」を話しながらみんなで考えるコミュニティです。樋口氏から、Nuxt、TypeScript、GraphQLを使ったSPA開発での気づきを発表しました。 事業部初導入のGraphQLとTypeScriptを使ったSPA開発に参加 樋口鉄朗氏:合同会社DMM.comオンラインイベント事業部の樋口鉄朗です。(※取材当時)今回は「Nuxt × TypeScript × GraphQLで開発した際のつらみ」についてのTipsを説明していきたいと思います。よろしくお願いします。 私は公立はこだて未来大学出身で、2019年に新卒でDMM.comに入社しました。趣味は自転車に乗ったり、旅行したり、ドライブに行ったりすることで、多趣味なエンジニアです。 以前は動画配信事業
2冊目も公開中なのでみてください! https://zenn.dev/tatta/books/4e993c596e7dc9 TypeScriptを使いはじめて1年になるので、バックエンドのWebアプリを設計するときに気を付けていることをまとめました。(※社内勉強会用資料の公開版です。) TypeScriptについては、Next.jsを中心にフロントエンドに関する公開情報が豊富です。一方でバックエンドに関する公開情報が少ないと感じています。(かくいう私もNext.jsからTypeScriptデビューしたわけですが) TypeScript * GraphQL という構成は仕事・趣味で採用されている方も多いのではないでしょうか? 私もその1人です。私のような方のためにも、バックエンドの設計プラクティスについてまとめようと思い筆を取りました。 本書がこれから始める読者にとっては教科書のようになり、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く