はじめに いつも聞いているポッドキャスト番組で、エンジニア転職について生々しくリアルな話が聞けたので、紹介します。今の自分がやっている仕事が市場価値を上げられているのか？ と日々の業務を振り返るきっかけになりました。詳しく知りたい方は是非、聞いてみて下さい。 転職の前提 かいちさん（転職した人）の紹介 情報系の大学院卒 中堅のバックエンド・エンジニア(30代) 社会人7年目 主に使っている言語: python, PHP アジャイル開発ができることを転職の軸に据えた 転職して感じたこと ① 30代は中堅の仕事を求められる → リーダー的立場が求められる ② 若い時の業務経験が転職の際に活きてくる → 20代はとにかく挑戦する回数を増やそう ③ 転職はどのタイミングでやってくるかわからない → 常に職務経歴書を更新し続けよう 結論 重要なポイント ・チームで開発した経験があるか？ ・AWSなど
Intro 10 年ほど前に同じことを調べたことがある。 なぜ html の form は PUT / DELETE をサポートしないのか? - Block Rockin' Codes https://jxck.hatenablog.com/entry/why-form-dosent-support-put-delete 当時は全くの素人で、素人なりに調査はしたが、ほとんどが推測の域を出ない結論だった。 この問題についてあらためて記す。 仕様策定の経緯 表題の通り、 <form> の method には GET と POST しかサポートされていない。 HTTP には他にも PUT や DELETE といったメソッドもあるのに、なぜサポートされていないのかという疑問から始まった。 仕様が決定した経緯は、以下に残っている。 Status: Rejected Change Descriptio
複数の言語で同じWebサービスを実装して技術特性の違いを見てみた - Hatena Developer Blog
開発合宿運営チームの id:yutailang0119 と id:maku693 です。はてなでは四半期に一度、技術グループ主導で開発合宿を開催しています（過去の合宿の様子は「開発合宿」カテゴリーにまとまっています）。 2023年4月に実施した開発合宿では、参加者が複数のチームに分かれ、それぞれ異なるプログラミング言語で同じお題のWebサービスを開発しました。言語ごとの特性を比較し、今後の技術選定に生かす取り組みです。 この記事ではその開催レポートをお届けします。 開発言語の特性を理解したい さまざまな技術要素を2日で実装できるお題に 参加チームやコミュニケーションでの工夫 順調に開発が進んだ合宿当日 技術勉強会で「成果物を見る会」を実施 開発合宿を終えて プログラミング言語ごとの使用ライブラリ TypeScript Go Ruby Scala 開発言語の特性を理解したい はてなではたくさ
@saboyutaka 合同会社春秋 Tech Base Okinawa 2023
【徹底解説】REST VS GraphQL
注意：今回の記事で載せているコードは読者に具体的なコードのイメージを持たせる目的で書いている。それ故に、実際にブラウザ上で実行しても動作しない点には注意してほしい。より専門的ににGraphQLとRESTの違いを学びたいならLogRocketの記事とApolloの記事を参考に。 はじめに 今回の記事では、Web APIの開発に重宝されるRESTとGraphQLの違いを解説する。 対象とする読者 これからREST、またはGraphQLを実務で積極的に活用したいひと 両者の違いがわからないひと 個人開発等でWeb APIをつくるひと タイトルを見てなんとなく気になったひと APIとは RESTとGraphQLの議論に入る前に、まずはAPIについて説明する必要がある。 Wikipediaによると、API(Application Programming Interface)は以下のように定義されてい
GraphQLはいつ使うか、RESTとの比較
さぼです、沖縄でWebと設計について考えてます。2023/09/23 に沖縄で行われたTechBaseOkinawa2023 にて上記のタイトルで登壇しました。 今回の内容は GraphQLを設計の観点から考えてみる GraphQLの目的や用途を整理する GraphQLを使う時、または使わない時のヒントを持ち帰ってもらう 最近、GraphQLじゃなくてRESTで良くないと思うケースがなんとなくわかってきたのでそれを共有する という感じで話しました。話した内容を文字に起こし少し改修してZennでも共有することとします。 まえおき 最近はクライアントAppとサーバーAppを分けて実装する事が増えてきた クライアントの環境はますます複雑になっている クライアントとサーバーはWebAPIで通信を行う クライアントが複雑になるのと同時にWebAPIの要求が更に増して来ている APIの要求・応答を効率
9ヶ月かけて全ての API を REST から GraphQL にリプレースした話 - がぶちゃんの日記
サマリー システム構成の変遷 創業フェーズ はじめての API と技術選定 GraphQL 移行直前 GraphQL への移行を決めたきっかけ GraphQL 移行方針 移行期間 ふりかえり 1つ目の方針は正解だった 2つ目の方針は微妙だったかもしれないけど、正解だったかもしれない 3つ目の方針はやはり苦戦した さいごに サマリー サービス開始から3年経った Next.js + Rails なシステム 全ての API を REST から GraphQL にリプレース 約9ヶ月かかりました 早速フロントエンドの都合でバックエンドにも手を入れるということが減って快適です という話です。 システム構成の変遷 創業フェーズ 1人目エンジニアとして入社して、何から手を付けようかなーと考えた結果、事業の肝の部分からシステム化していくことにしました。弊サービス https://moneiro.jp/ は
業務システム SPA のフロントエンド技術選定（2023年版） - KAKEHASHI Tech Blog
本エントリはカケハシ Part 2 Advent Calendar 2023の13日目の記事です。 （Part 1もおもしろい記事がいっぱいあるので、ぜひご覧ください。） はじめに こんにちは。カケハシでソフトウェアエンジニアをしている平松です。 今年、新規プロダクト立ち上げの機会があり、その際に行ったフロントエンドの技術選定について紹介したいと思います。 フロントエンドの領域は選択肢が豊富で、変化のスピードも速いため、プロダクトの要件に適した技術を選ぶことはひとつの挑戦です。 実際、フロントエンド技術選定のヒント 【令和五年度版】のアドベントカレンダー記事を読んで、その難しさを改めて感じました。 今回の新規プロダクトは、ユーザがログインして利用するtoBの業務システムです。 私はカケハシでは2度目の新規プロダクト立ち上げですが、前回の経験を活かしつつ、新しいアプローチにも挑戦しています。
GraphQL「良さ」・「難しさ」再探訪 〜スタディサプリにおける実例〜 / StudySapuri with GraphQL
2024/02/08 に「LayerX、スタディサプリ、SHEと考える GraphQLが向いている現場とは？運用実践LT」で、内山高広( @highwide )が発表した資料です。 #Offers_GraphQL実践LT
Backend エンジニア視点からの GraphQL / GraphQL from a perspective of backend engineer
"LayerX、スタディサプリ、SHEと考える GraphQLが向いている現場とは？運用実践LT" で登壇した資料です。 引用した資料 [Rails アプリに RESTful API のレールを敷いて生産性が大きく上がった話 | Wantedly Engineer Blog](https://www.wantedly.com/companies/wantedly/post_articles/85098) [React Server Components と GraphQL のアナロジー | by Yosuke Kurami | Dec, 2023 | Medium](https://quramy.medium.com/89b3f5f41a01) [実質無料で GraphQL Gateway を手に入れる / low-cost GraphQL Gateway - Speaker Deck](
この記事は一休.com Advent Calendar 2023 25日目の記事です。 一休レストランでは、よりスムーズな予約体験の提供を目的とするシステムのリニューアルを進めています。その一環として、2023年10月から、レストラン個別ページの表示から予約までのスマートフォンビューにおいて、バックエンドのサーバをRustで書かれたものに置き換えました。 一休レストランの Rust バックエンドが正式リリースされました。https://t.co/7N4VGv5ej9 このページのスマートフォンビューはバックエンドが Rust で書かれた GraphQL になってます— naoya (@naoya_ito) October 4, 2023 本番運用が始まって3か月近く経ちましたが、これまで安定して継続的な開発と運用ができています。これはRustだからと構えることなく、「ふつう」のバックエンド
Next.js の App Router が安定版となり、React Server Components (以下 RSC) を実際に試す環境が整ってきた。 実際、今年はやれどこそこのプロダクトが Next.js を採用しただのやっぱり捨てだのといった話題が尽きなかったように思う。 かくいう自分自身も、今年は App Router の案件に取り組んで RSC と格闘する日々を送っていた。 その過程で、こんなようなことを考えるようになったので、今回はこの辺りの話を書き残しておこうと思う（何回か X に同じ旨の POST は上げていたけど、一回もちゃんとまとめてなかったので）。 RSC がない頃の、別の言い方をすると getServerSideProps を使っていた頃の、Next.js におけるアプリケーションの設計は、トラディショナルな MVC にかなり近しい。 ここでいう MVC は、Sp
面白法人カヤック技術部の谷脇です。私は元気です。 この記事は面白法人グループ Advent Calendar 2023の5日目のエントリーです。 というわけでこの記事では、現環境(私が取り組んでいる業務のこと)ベストの管理画面の技術選択について考えたことを書き連ねていきます。 前提知識 管理画面の定義 ここで読者と私の目線を合わせるため、この記事上での管理画面の定義をしておきます。 管理画面はサービスの運営上必要な操作やデータの閲覧をまとめたWebアプリケーションです。また、このWebアプリケーションは一般ユーザーには開放されておらず、サービス運営者側のみ閲覧と操作が可能となっている、とします。 管理画面を作る動機 ここではTonamelの管理画面について、考えて導入したことを書きます。 tonamel.com Tonamelはゲーム大会やイベントを開催するためのプラットフォームです。We
6/16(金) は、久々のオフライン開催の吉祥寺.pm #33でした。懇親会含め楽しませてもらいました！主催のid:magnoliak ありがとうございました！ ここでは、話したことを書いてみたいと思います。 まず最初に、久々のオフライン開催おめでとうございます！いや〜〜〜、主催のmagnoliaさんよかったですね！おめでとうございます！ 改めて、こんにちは。こばけんと言います。 エンジニア組織開発責任者をしたり、開発生産性の可視化サービスを作っていました。 今は、はてなさんやDiverseさんで業務委託をしながら、起業の準備をしています。 技術コミュニティでは、Japan Perl Associationの理事として、YAPCという技術カンファレンスの運営やPerlのドキュメントを整備するワーキング・グループを運営しています。 2019年にYAPC::Tokyoのリーダーをしていたのです
Disclosure of a vulnerability that allows the theft of visitors' email addresses using Medium's custom domain feature / Mediumの独自ドメインプランを使って訪問者のメールアドレスが窃取できる脆弱性の開示
0_medium_vuln_en.md Disclosure of a vulnerability that allows the theft of visitors' email addresses using Medium's custom domain feature Author: mala Introduction This article describes a vulnerability in a web service called Medium that allows you to steal visitors' e-mail addresses by using custom domain plan of Medium. This is done as my personal activity and is not related to my organization.
はじめに こんにちは、retail HUBで Software Engineer をしているほんだです。 今回は私が現在着手している事業譲渡されたアプリを社内で持続的なプロダクト開発を行える状態にするリプレイスプロジェクトをどのように行っているか紹介しようと思います。 この記事ではリプレイスを行うにあたってどのようなことを課題に感じてその課題に対してどのような解決策をとったか主にサーバーの実装について説明しています。 ネットスーパーアプリとは 現在弊社ではネットスーパーアプリとして Web アプリとスマホアプリの二つのシステムを提供しています。 Web アプリは販促コンテンツの設定や売り上げの管理・集計を行うことが可能な管理システムと受け取り方法に応じた価格変更や送料変更にも対応し、消費者の柔軟な買い物を実現するお客様向けアプリを 17 の小売り様に、スマホアプリでは Web アプリのお客
Next.js × AWS App Runner × AWS AppSyncで進めるクライアントファーストのWEB開発
2023/09/23に開催されたServerlessDays Tokyo 2023で登壇した資料です
JSONとBigInt
ちょっと前にblueskyで見かけた話題。もとは「GraphQLのスキーマではintが32ビットしかなくて、64ビット整数とかないのがイケてない」といった話だったかなと思う。直感的にはこれは「Javascriptではすべてが倍精度浮動小数点数だから64bit intがないから」ということになるが、よくよく調べてみるといろいろややこしい歴史的事情があるようだ。 たしかにJSにはもともとひとつのNumber型しかなく、いわゆるdouble型(倍精度浮動小数点)だけで数値を表現してきた。IEEE754の倍精度浮動小数点数は仮数部が52ビットあるので、実際には32ビット整数ていどであれば全て誤差なく表現できる。なので32ビット整数または倍精度浮動小数点数がどちらも使えるというふうに理解されてきた。 そうはいっても不便なので、現代のJSにはBigIntがある。ES2020で導入されたらしい。ただし普
イベント「【タイミー/Voicy/令和トラベル】Backend LT〜技術選定における“見極める力”とは〜」での登壇資料 https://reiwatravel.connpass.com/event/306794/
はじめに マイクロサービスの開発では、サービスが増え続けるバックエンドに対して、フロントエンドは接続先が増えるため、開発効率を下げてしまいます。その対策として、さまざまな設計パターンが存在します。 弊社の開発ではGraphQL Gatewayを用いていますが、そこに至るまでや周辺の技術/アーキテクチャを解説します。 マイクロサービスとフロントエンド マイクロサービスを採用する場合、フロントエンド（ウェブアプリケーション、モバイルアプリケーションなど）は複数のサービスとの連携が必要になることが多いです。各マイクロサービスは通常、API（REST、gRPCなど）を提供し、フロントエンドはこれらのAPIを通じてデータの取得や操作を行います。 API Gateway API Gatewayは、フロントエンドとマイクロサービス間の中間に位置するコンポーネントとして機能し、マイクロサービスアーキテクチ
こんにちは、ユビーでプロダクト開発エンジニアをしている Sosuke Suzuki です。 最近、チームのエンジニア間の連携がいい感じだなーと思ったので、その要因の一つであるモブプログラミングについて、実践したことを紹介します。 はじめに 最近、私の所属するチームでは、データベース、バックエンド、そしてフロントエンドにも大きな変更を加える必要がある、規模の大きなプロジェクトに取り組んでいました（そして、今も同じチームで別の大きなプロジェクトに取り組んでいます！）。 そのプロジェクトの具体的な内容を書くことはできませんが、大雑把に事情を説明します。 数年前に設計されたいくつかのテーブルがあり、それは当時からずっとユビーのビジネスにとって重要でした。しかしそれらのテーブルは、この数年の間に複雑になったビジネス要件には耐えられなくなっていました。 このままではビジネスの機会を毀損することになりま
モバイルとの相性最強と言われるgRPCをFlutter x NestJSで実装し、Stream通信や認証、複数言語実装に使えるか試す
まとめ 相性バツグンといわれる、モバイル x gRPCは思ったよりずっと簡単に実装可能 複数言語間でもProtocol Buffersの恩恵により型変換を意識することなくスムーズに開発が進められる。 メソッド、引数の型、引数の返り値の型が自動生成されるのでとても良い RESTful APIにおけるheaderを、表現力の高いMetaDataとして利用し、認証認可等にも使えそう Streamをうまく使いこなせば、ユーザー体験をめっちゃ高くできそう。チャットやゲームなどの双方向通信が比較的楽に実装できるかも どんな人向きでない記事？ NestJSの詳しい実装を知りたい方 Bidirectional streaming, Client streamの詳細実装を知りたい方 モバイル向け通信技術の本格的な選択肢、gRPCを実際に試してみたい 現在、私の働いているMinediaで開発しているサービス群
ROUTE06 でソフトウェアエンジニアをしている @MH4GF です。 ROUTE06 ではエンタープライズ向けビジネスプラットフォーム「Plain」を開発しています。この記事では 2023 年 8 月に Plain クラウド EDI の Web フロントエンドで採用している技術について、その選定理由をまとめました。 現代の Web フロントエンド技術は領域ごとに選択肢が多く、プロダクトに最適な技術選定をする上で検討事項が多いと感じます。この記事がフロントエンド技術選定において参考になれば幸いです。 前提 プロダクトの特徴 技術選定に影響するプロダクトの特徴を箇条書きでまとめます。 エンタープライズ向け SaaS 現在開発中のプロダクトは商取引におけるクラウド EDI のドメインにフォーカス Plain が解決する課題は、元々フルスクラッチで開発すると 1 年かかるプロダクトの開発期間を
【Go編】Next.js × Go × AWSでJWT認証付きGraphQLアプリとCI/CDを構築してみよう - Qiita
■ご案内■ 本連載の背景/作成できるアプリケーション/進め方をご理解頂く上でも【環境構築編】 をご一読頂けると幸いです。 【環境構築編】 【Next.js編】 【Go編】 👈いまここです 【AWS編】 これからも頑張ってハンズオン系の記事を書いていきたいと思っているので、いいねっと思って頂けたらLGTM押していただけると励みになります！ 環境構築 本サンプルアプリの環境構築方法は【環境構築編】に記載しているので、そちらをご参照ください。 クリーンアーキテクチャ風なディレクトリ設計 以下の記事を参考にしつつクリーンアーキテクチャ風なディレクトリ設計をしてみました。 各階層間をインターフェースを利用して、システムの各部分を疎結合化しております。 # 簡単のため一部ファイルは割愛しています go-graphql-jwt-api/ ├── build/ │ ├── db/ │ └── dock
一休.com 宿泊管理システムのフロントエンド設計と改善の変遷 - Developers Blog - 一休.com Developers Blog
宿泊の管理システムについて 新しい管理システムについて 開発初期のフロントエンド設計 コンポーネントは4レイヤー方式を採用 UIのコンポーネントライブラリを採用 これ以上の設計、方針は決めなかった 初期ローンチ後の課題 改善した内容 1. コンポーネント設計の見直し ディレクトリ構成の変更 大きくなったコンポーネントの分割 Fragment Colocationを導入してコンポーネントのインターフェースとFragmentを整理 2. 業務処理（composables）の分割 3. 型安全に開発できるように厳しいlint設定に変更 4. 秩序を保てる開発体制、ドキュメントの整備 現在と今後 今後やりたいこと 改善を継続するためのポイント まとめ おわりに 宿泊プロダクト開発部の田中（id:kentana20）です。 このエントリーは一休.com Advent Calendar 2023の14
Ruby on Rails Guides / Ruby on Rails ガイド：体系的に Rails を学ぼう 公式Docs。教典。 Ruby on Rails チュートリアル：プロダクト開発の０→１を学ぼう Railsやってる人で知らない人はいないRails2系の頃からある定番サイト 昔は全部無料でWebテキストが読めたが今は1000円くらいで購入することになってる。今でも進化しながらメンテナンスされており神。 Railsの練習帳 少しだけ発展的だけど必須で知っておきたい内容。データモデリングとかGraphQLのような話も追加されていっている。無料。 asyraffff/Open-Source-Ruby-and-Rails-Apps: Awesome Ruby and Rails Open Source applications 🌈 Rails製のOSSプロジェクトをまとめたページ
銀の弾丸ではないので良し悪しあるのは当然として、それを差し引いても以下の2つの要素があるのではと思った。 なんとなく使ってもメリットが十分得られない RESTでできてたことができなくなる（※ちゃんと調べればできる） なんとなく使ってもメリットが十分得られないWeb界隈は良くも悪くも新しい技術をとりあえず使ってみるところがあると思っていて、そこがGraphQLは十分に事前知識を持って導入しないとメリットが薄いところとミスマッチを起こしてネガティブな意見が出るのかなと思う。 GraphQLはもともとFacebookがReact, Relayとの組み合わせで使い始めたもので、クライアントライブラリとしてのRelayと、IDやページネーションについての追加仕様を公開している。ライブラリとしてのRelayは使わなくても仕様に乗っかることはできるのでそれをRelayスタイルと言ったりする。出典を忘れた
これは エムスリー Advent Calendar 2023 の3日目の記事です。 前日は三浦さん(@yuba)による「9時間足すんだっけ引くんだっけ問題～あるいは、諸プログラミング言語はいかにタイムゾーンと向き合っているか」でした。 こんにちは、エムスリーエンジニアリンググループ・マルチデバイスチームの藤原です。 マルチデバイスチームでは複数のスマートフォンアプリを開発しており、新機能の追加やレイアウト変更をする際はA/Bテストをすることもしばしばです。 今回は弊チームで採用しているA/Bテストの実装方法を2通り紹介します。 スマートフォンアプリのA/Bテスト Remote Configを用いた実装例 GraphQLを用いた実装例 GraphQLで実装してみてちょっとした感動があった We are hiring!! スマートフォンアプリのA/Bテスト A/Bテストとは、特定の要素を変更し
こんにちは、プログラマーのkinoppydです。最近はSmartHR内でのプロダクトを横断して開発を行うプロダクト基盤チームというところで仕事をしています。 tech.smarthr.jp GraphQL集めるマンの概念図 分散したプロダクトの課題 SmartHRは、祖業である労務管理と従業員情報を集約している「基本機能」と呼ばれる巨大なアプリケーションと、その「基本機能」にある従業員情報を使い文書配布、年末調整、タレントマネジメントなどを行う小さなアプリケーション群によってサービスが提供されています。各アプリケーションは完全に独立したリポジトリとデータベースを持っており、「基本機能」とのデータのやり取りには公開・非公開のREST APIを利用しています。 SmartHRのプロダクト間の構成概略図 APIで繋がれた基本機能とサービスの世界観には、一つ問題点があります。それは、複数のサービス
「2024年こそ使いこなす！GraphQL最前線」で発表した資料です。 ソニーのホームエンタテインメント領域では、TVやサウンドバー、ヘッドホンをはじめとする様々な製品、それらに付随するアプリケーションを取り扱っています。我々はホームエンタテインメント領域の横断組織として、それらの製品・アプリに対してクラウドサービスを提供しています。この領域において頻繁に要求される機能の一つに、データ配信があります。従来は製品・アプリの案件ごとにそれぞれ個別にサービスを開発しており、サービス間連携やリソースの共通化など横断組織ならではの利点をうまく発揮することができていませんでした。本セッションでは、この問題を解決すべく開発した共通データ配信プラットフォームについて、そこで活用されているGraphQLという技術との関係について、お話しします。
こんにちは、技術部の石川です。 ある日、社内の各種アプリケーションを眺めている中で、とあるクローズしたサービスの管理画面を担っていたウェブアプリが今も動いていると気付きました。簡単にヒアリングしたところ、サービス自体はクローズしたものの、保有していたデータが次のチャレンジに生かせるため管理画面だけ残しているとのことでした。 一方で、その管理画面へのアクセスはそう多くありませんでした。毎日ちょっとだけのリクエストを処理するためだけにデータベースとサーバーが動いており、少し無駄がある状態になっていました。 やや気になったので検討した結果、最終的にこの管理画面アプリを Next.js 製の静的なデータビューワーサイトとしてリニューアルし、社内向けの GitHub Pages として提供されている状態にできました。この記事ではその顛末をご紹介します。 技術選定 いくつか事前調査をした結果、今回の管
結論 Cloudflare WorkersでGraphQLサーバを立てて普通に動く TCPでのデータベース接続も問題ない（ベータなので使ってると何かあるかもしれないが） Node.js互換は完全ではないので、Node.jsが必要な処理はオリジンサーバを用意するのが吉 動機 Cloudflare WorkersはCDN上のプロキシやRemixやNext.jsのレンダリング用のバックエンドとして使うというようなことが多いです。フロントエンドからデータ取得や更新するためのAPIとなると別のバックエンドサーバを立てて、構築するのがほとんどだと思います。 自身も漏れなくそのパターンでNode.jsでバックエンドサーバを立てることが多いですが、そうなると簡単に建てれるCloud Runを初手で選ぶのですが、Cloud Run自体は素晴らしいサービスなんですが、更に欲が出てくるのが人間です。 デプロイを
GraphQL実践ノウハウv2
GraphQL実践ノウハウ https://speakerdeck.com/sonatard/graphql-knowhow 宣言的UIの状態管理とアーキテクチャSwiftUIとGraphQLによる実践 https://speakerdeck.com/sonatard/swiftui-graphql GraphQLの誤解 https://speakerdeck.com/sonatard/rethinking-graphql
GraphQLのFragment活用テクニック: colocationとmasking - ドワンゴ教育サービス開発者ブログ
GraphQLのFragment活用テクニック: colocationとmasking こんにちは。N 予備校 Webフロントエンド開発チームの中村です。 現在開発中のZEN CompassではGraphQLを採用しました。我々のチームでは（そして私個人としても）GraphQLを採用したのは初めてだったのですが、実際に設計を進めていくうちに色々と知見を得ることができました。今回はその中でも特に重要だと思った、GraphQLのFragmentという仕様を活用したコンポーネント設計のテクニックについてお話ししようと思います。GraphQLを使用したWebアプリケーションに興味がある方にとって何か参考になりましたら幸いです。 【ZEN Compass】 学習者を導く先生方などが利用するコーチング支援Webサービスです。 LMS(Learning Management System)として学習状況
GraphQL 成熟度モデルの紹介と、プロダクトに当てはめた事例 / GraphQL maturity model
2024/04/19 「tsukiji.graphql」で発表したスライドです。 https://tsukiji-graphql.connpass.com/event/314173/ 参照したURL - https://mh4gf.dev/articles/tags/graphql - GraphQL 成熟度モデル - とろろこんぶろぐ - GraphQL を Server Components で使いたい - Speaker Deck
GraphQLサーバーは、本当にGoがTypeScriptより早いのか。Flutterからの呼び出しで検証する。
3秒まとめ GoのパフォーマンスはNestJS（TypeScript）の2倍以上!? GraphQLのエコシステムはGo, TSともに充実 GitHub Copilotで、GoのAcceptance Rateが40%を超える体験をした GraphQL全盛の時代に、どの言語を使って開発すべきか 2015年にFacebookにより公開されたGraphQL。日本でもYahooやメルカリなどバックエンドをマイクロサービス化している多くの企業で採用され、近年はフロントエンド開発者にとって魔法の弾丸のように扱われることも多くなりました。 メルカリShopがGraphQL Client Architecture Recommendation社外版を公開していることからもわかる通り、GraphQLの利用に関する知見はかなり蓄積されてきています。 上記Recommendationによれば、BackendはG
GitHub - stepci/garph: Fullstack GraphQL Framework for TypeScript
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
はじめに Smart Craft テックリードの星井です。 前回の記事で Smart Craft の技術スタックの全体像についてお伝えしましたが、今回はバックエンドについてお話します。 Ruby on Rails / GraphQL な構成になっているので同じような構成を検討している方の参考になれば幸いです。 バックエンドのフレームワーク選定 新しくアプリケーションの開発をやるぞとなったときに、バックエンドで何を使うかというのは毎回頭を悩ませる人が多いのではないでしょうか？ フロントエンドに関しては最近だととりあえず React を使っておけば文句を言う人はいないと言う認識ですが（偏見）、バックエンドはいろいろあって迷いますよね。 自分は Rails 信者でして個人的に何かを作る時には脳死で Rails を採用することが多いですが、Smart Craft でのプロダクト開発は当然そんな安易
この記事はUbie Engineering Advent Calendar 2023の一日目です。よろしくお願いします。 背景 ユビーのシステムは言語が多様化してきたことにより、認知負荷の増加や運用負荷の増加、開発支援に仕組みづくりかけるコストの増加などの問題が発生していました。この課題を解決するためにNode.jsとGoに言語を絞っていくという意思決定をしたのが昨年です。これについては以下の記事で詳しく解説しています。 ちょうど去年のアドベントカレンダーの記事なのでこれから一年経ちました。ここでは以下のように述べられています。 Server-Side Kotlin などで書かれている既存サービスを、この技術選定の文脈でリプレイスすることは今のところ考えていません。 ただし、多くの既存サービスはドメインたくさん抱えすぎ問題があったり、色々とレガシーだったりして、徐々に別サービスに切り出して
Starting today, Cloudflare’s API Gateway can protect GraphQL APIs against malicious requests that may cause a denial of service to the origin. In particular, API Gateway will now protect against two of the most common GraphQL abuse vectors: deeply nested queries and queries that request more information than they should. Typical RESTful HTTP APIs contain tens or hundreds of endpoints. GraphQL APIs
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
30歳エンジニア転職で役に立たなかった経験と役に立った経験 - Qiita
なぜ HTML の form は PUT / DELETE をサポートしないのか? | blog.jxck.io
GraphQLはどんな時に使うか
一休レストランのふつうのRustバックエンド開発 - 一休.com Developers Blog
React Server Components と GraphQL のアナロジー
俺の管理画面 2023年冬 - KAYAC engineers' blog
最近プログラミングが楽しい - Blog::kobaken
ネットスーパーアプリ GraphQL から REST へ移行始めました - every Tech Blog
TypeScript x GraphQLで2年開発してみて
GraphQL Gatewayはフロントエンド開発を幸せにする
開発スピードを維持しながらモブプログラミングを実施した話
Plainのフロントエンドにおける技術選定(2023年8月版) - ROUTE06 Tech Blog
Railsを始める人が読むと良いサイト - 技術メモ
GraphQLのよくないところ｜adwd
スマートフォンアプリのA/Bテスト実装例 - エムスリーテックブログ
SmartHRのマルチアプリケーションに分散した従業員データを集約する - SmartHR Tech Blog
ソニー: GraphQLを活用したデータ配信プラットフォームの事例紹介
クローズしたサービスの管理画面を静的サイトにする - クックパッド開発者ブログ
現状Cloudflare WorkersでGraphQLサーバを構築するならコレ
なぜ我々はRailsを選択したのか？Smart Craftバックエンドのご紹介
Node.jsで作るモジュラモノリスの設計と技術選定
Protecting GraphQL APIs from malicious queries