GraphQL で REST API を作る - 技術的な挑戦と、それを支える文化の話 - LayerX エンジニアブログ
バクラク事業部の Product Enabling Team でソフトウェアエンジニアをしている @izumin5210 です。 この記事は LayerXアドベントカレンダー(概念) の54日目の記事です。 バクラクのリソースを提供する REST API を開発するにあたり、その基盤を GraphQL をベースに実装する、ということをしました。 なかなかにチャレンジングな選定であり、これを入社してすぐ作っているという背景も含めておもしろい話だと思うので、技術的な話と文化的な話をあわせて紹介させてください。 「GraphQL で REST API を作る」とは？ まず「GraphQL で REST API を作る」というのが見慣れない文字列なのではないでしょうか？ 前提を揃えるために目指す形を明確にしておくと、だいたい以下のようなものです。 外から見た API は REST に従っており、H
Next.js でリアーキテクトした話 / story-of-re-architect-with-nextjs
https://jsconf.jp/2021/
Swagger (OpenAPI 2.x) generates go-server codeの何が辛いのか
注意 まだ書くべきことはたくさんある go-swaggerは駄目だ、と見切りをつけて数年が経つので、情報が古い可能性がある OpenAPI 3.x を否定するものではない（むしろそちらには若干の希望を感じている） 解決策は書いてない 結論 Swagger generates go-server codeを採用するには、相当な覚悟が必要 どうせやるならOpenAPI 3.xに賭けたほうがいい 背景 この記事を書こうと思った動機 とつぶやいたものの、そのデメリットについて明確な言語化したことがなく、 単なる言いがかりじゃない というところをきちんとしておくため。 Swaggerはつらいよ 実際にプロジェクトで採用してみた結果、一体何が辛かったのかについて、3つの点から解説する。 問題点1: Swaggerの表現力と戦わねばならない そもそも$refがキツイ 説明まで含めて完全に同一な定義なんて
TypeScript の型生成における OpenAPI Generator のハマりどころ - READYFOR Tech Blog
こんにちは。READYFOR でフロントエンドエンジニアとして働いている菅原（@kotarella1110）です！ 嬉しいことに、READYFOR のプロダクト開発組織は急拡大中で、正社員の人数は 2019年7月時点では8名でしたが2021年4月現在は29名になりました 🎉 その反面、組織が大きくなってくると「我々はどこに向かってるんだっけ？」「あの人、最近はどんなことに取り組んでいるんだろう？」といった「見えないこと」が増えてきます🤔 この「見えないこと」を減らすために、READYFOR では毎月「プロダクト開発本部会」を開催しています。 プロダクト開発本部会では、必要な全体周知（組織やプロダクトの方針等）や月替わりプレゼンテーションを行っています。 本記事はこのプロダクト開発本部会の月替わりプレゼンテーションで発表した内容になります。 はじめに 以前 READYFOR で初主催とな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
