お前らまだ簡単なCRUD処理を実装してるのか？ 〜PostGraphileへの誘い〜
煽りタイトルみたいになってしまいましたが、最近の開発で使ってるPostGraphileがめちゃくちゃオススメなので、紹介記事です。 PostGraphileとは PostGraphileは、Node.jsベースのオープンソースのライブラリで、PostgreSQLデータベースをGraphQL APIに変換するツールです。PostGraphileは、GraphQLサーバーのセットアップやGraphQLスキーマの手動作成などを省略して、効率的にGraphQL APIを生成することができるため、開発をスピードアップできます。 主な特徴とメリット： 自動生成されたGraphQL API: データベースのスキーマを基にして、自動的にGraphQLスキーマとリゾルバーを生成します。これにより、データベースに対してGraphQLクエリを直接発行することができます。 安全性: PostGraphileはセキ
Full-Stack TypeScriptの最終到達点、T3-Turboで新規開発した話
はじめに この記事はTSKaigi Advent Calendar 2024の記事です。(TSKaigiの運営メンバーとして最初の記事になりそうです。) みなさん、TypeScript書いてますか？最近、フロントエンドもバックエンドも（加えてインフラも）TypeScriptで統一する、Full-Stack TypeScriptを採用する事例が増えてきました。 Full-Stack TypeScriptの由来やメリットはこちらの記事から フロントもバックもTypeScriptだし、どうせならMonorepoで管理しようということで、TypeScript専用のMonorepo管理ツールであるTurborepoを導入し、T3-Turboというアーキテクチャを導入することになりました。 T3-Turboというアーキテクチャは、以前導入を考えた際に記事にしているので、こちらをご参照ください。 またT
TypeScriptとGraphQLで実現する型安全なAPI実装
この記事はTSKaigi2024での以下の私の発表内容を書き下ろしたものです。 なぜAPIに型をつけたいのか 現代のWebのシステム開発において、クライアント・サーバーともに型のある言語で開発されることが増えてきました。静的な型検査はコードの堅牢性やよりよいメンテナンス性の向上をもたらします。 プログラミング内部だけで型検査をするだけでも十分メリットはありますが、外部I/Oに対する型付けが不十分だとそのメリットを最大限に発揮してるとは言えません。外部I/Oとは、例えばWebフロントエンドだとLocalStorageやDOMからの入力値、それからネットワーク通信（今回はこれをAPIと呼びます[1]）などですね。サーバー側でいうとAPIからの入力・レスポンスやデータベースへの読み書きが該当します。 個人的な経験から言うと、Webシステムの開発におけるエラーの多くはAPIやデータベースとのやり取
TypeScript x GraphQLで2年開発してみて
イベント「【タイミー/Voicy/令和トラベル】Backend LT〜技術選定における“見極める力”とは〜」での登壇資料 https://reiwatravel.connpass.com/event/306794/
【日本語訳】nitrogql 1.1リリース: hello type-safe resolvers!
この記事は、昨日公開された次の記事の日本語訳です。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 好きだから
GraphQL と Prisma から考える次のN年を見据えた技術選定 / Architecture decision for the next N years at StudySapuri
JSConf JP 2021 で登壇した資料です #jsconfjp #jsconfjp_b Links: [Active Recordから考える次の10年を見据えた技術選定](https://speakerdeck.com/yasaichi/architecture-decision-for-…
GraphQLの“つらみ”には「スキーマ駆動開発」を使え Nuxt.jsやTypeScriptが使えるモダンな開発環境で陥った、「なんじゃこりゃー！」 | ログミーBusiness
事業部初導入のGraphQLとTypeScriptを使ったSPA開発に参加樋口鉄朗氏：合同会社DMM.comオンラインイベント事業部の樋口鉄朗です。（※取材当時）今回は「Nuxt × TypeScript × GraphQLで開発した際のつらみ」についてのTipsを説明していきたいと思います。よろしくお願いします。 私は公立はこだて未来大学出身で、2019年に新卒でDMM.comに入社しました。趣味は自転車に乗ったり、旅行したり、ドライブに行ったりすることで、多趣味なエンジニアです。 以前は動画配信事業部に所属していて、売上グロース施策の関連開発などを担当していました。また、プラットフォーム事業部では、事業部内のシステムのリプレイスなどのプロジェクトを担当したり、運営事業部チーム向けのアプリケーションやbotを開発したりしていました。 現在所属しているオンラインイベント事業部では、オンライ
TypeScript * GraphQLのバックエンド設計プラクティス
2冊目も公開中なのでみてください！ https://zenn.dev/tatta/books/4e993c596e7dc9 TypeScriptを使いはじめて1年になるので、バックエンドのWebアプリを設計するときに気を付けていることをまとめました。（※社内勉強会用資料の公開版です。） TypeScriptについては、Next.jsを中心にフロントエンドに関する公開情報が豊富です。一方でバックエンドに関する公開情報が少ないと感じています。（かくいう私もNext.jsからTypeScriptデビューしたわけですが） TypeScript * GraphQL という構成は仕事・趣味で採用されている方も多いのではないでしょうか？ 私もその1人です。私のような方のためにも、バックエンドの設計プラクティスについてまとめようと思い筆を取りました。 本書がこれから始める読者にとっては教科書のようになり、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エラーレスポンス設計から考える、0→1開発におけるGraphQLへの向き合い方
TypeScript による GraphQL バックエンド開発
Apollo ServerとPrismaではじめるGraphQL API開発入門