これまで数多くのシステム障害を復旧してきました。 障害は無いに越したことは無いですし、起こらないように最善を尽くすのが我々エンジニアの使命です。 しかし、どれだけ最善を尽くしても起こる時には起こります。 今回は、これまで数多くの障害を復旧させてきたエンジニアが、復旧作業時に何を考えているのかを改めて言語化してみたいと思います。 こういう情報ってそれぞれのエンジニアの頭の中にあってあまり共有されないので、意外に参考になるかなと思います。 障害復旧対応の醍醐味 表現が適切かは分かりませんが、僕はシステム障害を復旧させるのが大好きです。目の前に起こっている事象からヒントを集め、地道に原因を切り分けてクリティカルヒットを見つけたときは名探偵になった爽快感があります。 加えて、動いているものを常に動かし続ける日頃の保守運用とは異なり、動いてないマイナスの状況を0まで戻すということで、復旧成功した際に

この記事は何か？ フロントエンドとバックエンドをGraphQL APIで連携する場合、スキーマファイル(schema.graphqls)をどうやって連携するか悩んでいました。 色々と試行錯誤して、ベストプラクティスとまでは言えないまでもベタープラクティスに近い解決策に至ったので共有してみます。 構成 バックエンドは Go, Gin, gplgen、 フロントエンドは TypeScript, React, Next.js のSPA構成でそれぞれ別リポジトリで管理しています。 やりたいこと バックエンドとフロントエンドでschema.graphqlsファイルから型を自動生成したい。 ※ schema.graphqlsファイルの管理はバックエンドが主導で行う前提です。 やりたくないこと graphqlsファイルの二重管理。バックエンドの差分を逐一フロントエンドでコピーして追従、というケースだけは