Building Better People: How to give real-time feedback that sticks.
TypeScriptなGraphQLサーバをGoにリプレースした 3-shake Advent Calendar 2022の11日目です。 現在携わっているプロダクトではGraphQLを利用してフロント/バックエンドの通信を行っています。 7月に入社した当初はTypeScriptで開発が進んでおり、ある程度の機能が出揃っていましたが、チーム編成が変わったことによりGoが得意なメンバーがバックエンドを担当することになりました。 そこで既存のGraphQLサーバをGoにリプレースしたのでまとめます。 これまで 既存のGraphQLサーバはTypeScriptをベースに構成されており、以下のようなパッケージを採用していました。 NestJS Prisma NestJSの拡張機能でGraphQLを取り扱い、Prismaで定義したスキーマを利用して永続化を行っていました。 これから 技術選定 Goへ
GraphQLクライアントライブラリ乗り換え遍歴 私達のプロジェクトではReactのフロントエンドとバックエンドの通信にGraphQLを使っています。 GraphQLは、たいていの場合はHTTP POSTリクエストで リクエストボディ:GraphQLクエリ(文字列)と引数(オブジェクト)からなるJSON レスポンスボディ:データJSON をやりとりするだけというだけのシンプルなプロトコルなので、全てfetch関数で頑張るストロングスタイルで行けないこともないですが、やっぱり専用のクライアントライブラリを利用したほうが楽です。 そのライブラリとして一番有名なApollo Clientから始まってRelay、Urqlと、3ヶ月くらいの間に2回も乗り換えてしまったので、反省の意味も込めて記事にしたいと思います。 GraphQLクライアントライブラリがいろいろあってどう違うんだろうと迷った方の助け
一休のSaaSサービス「RESZAIKO」開発チームは、フロントエンド開発における時系列に基づく状態遷移、宣言的プログラミングをバックエンド開発に採用。開発時のアーキテクチャやコンテキストのギャップを軽減するチャレンジに挑んだ。その取り組みやアーキテクチャについて、CTO伊藤直也氏が語った。 きっかけは、フロントエンドとバックエンドの技術的関心事のギャップ 株式会社 一休 執行役員 CTO 伊藤 直也氏 今回のイベントで、「RESZAIKO」のバックエンドチームでチャレンジした開発手法について語ってくれたのは、株式会社一休のCTOを務める伊藤直也氏だ。伊藤氏はまず、今回のTypeScriptでのGraphQLバックエンドを開発するに至った背景を、「フロントエンドとバックエンドの技術的関心事と開発スタイルのギャップ」だと切り出す。 例えば、フロントエンドがReactで開発した場合、React
GraphQL スターターパック | Prisma + NestJS + Next.JS製 個人ブログサイトをCloud Runで運用しよう 「GraphQLの仕様はなんとなく知っているけど、それを使ってどうアプリを作るのかいまいちイメージがわかない」 この本はそんなスキマを埋めるべく書きました。 近年ではReactをはじめフロントエンドの選択肢が豊富になっており、フロントエンドとバックエンド間のやりとりにはより汎用的かつ効率的な方法が求められます。 GraphQLはその選択肢のひとつです。本書では NestJS で GraphQLバックエンドを実装し、それをNext.jsから利用して、個人ブログサイトを構築してみます。 GraphQL開発の流れを体験し、ご自身のアプリ開発に役立ててください。 v1.10 refactor github deploy
この記事はGraphQLで使われる文法の入門編です。 よく使われるクエリの文法に焦点を当てて整理しています。 今回はPlaygroundとして一般公開されている以下のサイトを例にして、GraphQLの文法をクエリの実行を試しながら整理していきます。 http://snowtooth.moonhighway.com/ ※以下のページより、PlaygroundのIDEをインストールして利用することも可能です。今回は既に公開されているスキーマベースで文法を確認していきます。 https://github.com/prisma/graphql-playground SQL/RESTとの比較 GraphQLはクエリ言語です。基本的にはQueryとMutation、Subscriptionを使い分けます。 SQLはデータベース専用のクエリ言語です。 GraphQLはインターネットのためのクエリ言語です
2冊目も公開中なのでみてください! https://zenn.dev/tatta/books/4e993c596e7dc9 TypeScriptを使いはじめて1年になるので、バックエンドのWebアプリを設計するときに気を付けていることをまとめました。(※社内勉強会用資料の公開版です。) TypeScriptについては、Next.jsを中心にフロントエンドに関する公開情報が豊富です。一方でバックエンドに関する公開情報が少ないと感じています。(かくいう私もNext.jsからTypeScriptデビューしたわけですが) TypeScript * GraphQL という構成は仕事・趣味で採用されている方も多いのではないでしょうか? 私もその1人です。私のような方のためにも、バックエンドの設計プラクティスについてまとめようと思い筆を取りました。 本書がこれから始める読者にとっては教科書のようになり、
GraphQL Tokyo #10 Links: p11 https://speakerdeck.com/qsona/graphql-for-service-to-service-communication-protocol p12 https://note.com/qsona/n/nfc73a8…
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、映像サービスプロダクト本部の浜田(@narirow)です。 GYAO!では最近トップページの大規模な変更が行われました。本記事では映像サービスのバックオフィスを含む大規模な構成変更と、その成果として得られたスケーラビリティ・ページの表示速度の向上についてをお話しします。 GYAO!のトップページの特徴 映像サービスであるGYAO!のトップページは、豊富なラインアップの中から作品を厳選して掲載しています。有名作品をただ並べるだけではなく、レコメンデーションやターゲティングの技術を使って、閲覧者の趣向にあった作品を一覧しています。大量の画像が表示されていることに加え、縦に長いページ構成となっています。 課題と解決のアプロー
M3 ではグローバル CTO の Brian が、サービスの海外展開や技術基盤の共通化などを積極的に進めています。その中のプロジェクトの1つとして、アメリカで提供している医療ニュースのリニューアルにチャレンジしています。2018 年 5 月には日本オフィス所属のイギリス人エンジニア @christophrowley と日本人のエンジニア (筆者)が 1 ヶ月ほどニューヨークに出張してリニューアルの検討をしてきました。 ( ↑ Chrisが撮影してくれた NY の写真 ) 今回の記事は、リニューアルで採用を検討している GraphQL を Apollo + JavaScript で作るチュートリアルです。 TL;DR Apollo を使って、クライアントサイド、バックエンドを作るチュートリアルを紹介 英語・海外での開発に挑戦したいエンジニアを絶賛募集中です。もし興味があればランチ行きましょう
エムスリーでマルチデバイスチームのチームリーダーをしている松原@ma2geです。 マルチデバイスチームはこちらのテックブログでは初出なので簡単に紹介すると、iOS や Android 等のデバイス対応を主導する開発するチームで、主に iOS, Android のネイティブアプリ開発から、アプリから叩く API サーバ(いわゆる Backends For Frontends(BFF))、プッシュ通知基盤システムのバックエンドサービスも開発しております。 私自身は3月までは別チームで Rails/Java/Elixir などを触っていましたが、4月から現チームに移動しこちらでもまた新たな挑戦をさせてもらっています。 💪 前提 今回はネイティブアプリ向けの RESTful な API サーバがレガシーとなっており、このサーバのリニューアルを検討している話を書きます。 対象のサーバはフレームワー
By Alan Johnson May 8, 2018 I have seen the future, and it looks a lot like GraphQL. Mark my words: in 5 years, newly minted full-stack app developers won’t be debating RESTfulness anymore, because REST API design will be obsolete. By the end of this post, I hope you’ll see what I see in the promise of GraphQL as a new approach to client-server interaction. GraphQL is taking the full-stack world b
こんにちわ。 OPENLOGI AdventCalendar 4日目です。 普段は倉庫の管理システム(WMS)の開発をしています。 今回はロジスティクスと全く関係ありませんが、とある社内システムをGraphQLを用いて実装したのでGraphQLについて書きます。 2015年にFacebookがGraphQLを公開してはや2年。公開当時は衝撃を受けた記憶がありますが、まだまだ潮流にはなっていないというところでしょうか。 GitHubを始め少しづつAPIとしてGraphQLを利用しているサービスが増えてきた中、GraphQL自体は何となく何をするか浸透している気がします。でも一方で、実際の実装のイメージを持っている人は割と少ないイメージがあり、ハードルが高いような気がしてます。ということで、このハードル、「どうやって実装すんの?」というところが何となく分かってもらえれれば幸いです。 Graph
DroidKaigi 2018のスライドです
k0kubun.hatenablog.com 非常に丁寧に書かれていると思うのですが、少し反論したい部分があるので、記載したいと思います。 GraphQLのキャッシュ効率について クエリをパースしないとキャッシュの可否を判定できないため、HTTPキャッシュが難しい こちらに関して、2つの観点から反論してみたいと思います。 まずに、GraphQL は GET リクエストでも送ることができます。Serving over HTTP | GraphQL によると、http://myapi/graphql?query={me{name}} のような URL の GET リクエストができます。(※そもそも、これ自体は GraphQL の絶対的な制約ではなく、 GraphQL を一般的に HTTP で提供するときのプラクティス、という位置づけです) そして、GraphQL は 1 回のリクエストで送らな
今年GitHubがGraphQL APIを正式公開したあたりから、GraphQLが去年とかに比べちょっと流行り始めたように感じる。idobataがGraphQL APIを公開したり、Kibelaも公開APIをGraphQLで作ることを宣言している。 利用者側からすると使えるインターフェースの中から必要なものを調べて使うだけなのであまり考えることはないのだが、自分がAPIを提供する立場になると話は変わってくる。REST APIとGraphQL APIはどちらかがもう一方のスーパーセットという風にはなっておらず、どちらかを選択すると何かを捨てることになるので、要件に応じてどちらを選ぶのが総合的に幸せなのか考える必要がある。 以前趣味でGitHub連携のあるサービスを作っており、それを最近GraphQL API v4を使うように移行し、そこでついでにそのサービスのGraphQL APIを書いてみ
注:単純なデータモデルでさえ、今後の維持や説明が必要になる6つものエンドポイントが含まれています。 あなたがクライアント側の開発者で、movies APIを使い、HTMLとjQueryで単純なWebページを作るとします。そのためには、映画と出演俳優・女優の情報が必要です。APIに必要な機能は揃っているので、データを取得します。 新しくターミナルを開いて以下を実行します。 curl localhost:3000/movies 以下の応答が返ってきます。 [ { "href": "http://localhost:3000/movie/1" }, { "href": "http://localhost:3000/movie/2" }, { "href": "http://localhost:3000/movie/3" }, { "href": "http://localhost:3000/mo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く