概要
ここに概要を書く、本文の内容を要約したものを目的から本文の内容を短い文章で書く
※ 最初に概要を書いて何をやるかを明確にしてから調査や考察をし、実際に調査をすると方向性や結果が予想とずれるので、その後書き直すとまとまりやすいでしょう
目次
- 概要
- 目次
- 目的
- 対象読者
- PR
- 本文
- 従来方法
- 実験・調査・比較結果
- 考察・提案
- まとめ
- 参考リンク
- RailsとNext.jsを使ったスキーマ駆動開発による継続的インテグレーション:OpenAPI編
- バックエンドとフロントエンド:リポジトリの分割のメリット
- バックエンドとフロントエンドのデプロイ先の差異と対策
- OpenAPIとGraphQLで共通に行うこと
- パターン:バックエンドとフロントエンドがプルリクエストを受け付けた際の処理
- バックエンドがプルリクエストを受け付けた際の処理
- フロントエンドがプルリクエストを受け付けた際の処理
- まとめ
- PR
目的
何のためにこれをするのか、xxxの開発効率を上げる。xxxのパフォーマンスが良くするなど。
対象読者
プロダクトオーナー向けなのか、アーキテクト・リードエンジニアなどアーキテクチャ設計を担当する向けかビジネスサイドの人向けなのかを明確にする。※読者を明確にすると文章の内容や構成をその人たち向けにかけるので独りよがりにならず良いです。
PR
UZUMAKIではアジャイル開発で新規事業の開発から、大規模Webアプリケーションのアーキテクチャ更新などの開発をしています。
お問い合わせはUZUMAKIのHPのお問合せフォームから
本文
従来方法
従来手法があれば書く
実験・調査・比較結果
内容によって、実験や、調査、比較するものがあれば観点をまとめて比較を書く
箇条書きでダラダラ書くのではなく、表やグラフを用いるべし
考察・提案
実験した結果や調査した内容から得られた知見をまとめる
例: こういうパターンにはAが適しており、次のパターンではBが適している
Githubに検証した際に作ったURLがあればここに貼る
まとめ
行なった内容のまとめ目的から本文の内容を要約する。概要とほぼ同じで良いが、もう少しフランクに感想なども付け加えて良い
参考リンク
あなたはプログラミング関係の編集者として振る舞ってください これから示す【本文】を【制限事項】を満たして読みやすいブログポストに書き直してください 【制限事項】 - 対象者はミドルクラスのソフトウェアエンジニアです。 - "てにをは"が間違っている箇所は修正してください - 全体像から始めて、段階的に詳細を記述してください - 補足が必要なプログラミング用語については用語の説明を補足してください - 文章の長さは3000-5000字を想定しています 【本文】 ``` - タイトル - RailsとNext.jsを使ったスキーマ駆動開発で継続的インテグレーションを行う方法 OpenAPI編 - 前提 - APIのスキーマはバックエンドで生成する - バックエンドはRailsでフロントエンドはNext.jsを使用する - Next.jsはTypeScriptで実装している - コードはGithubでホスティングし、Github actionsでCIを実施する - バックエンドとフロントエンドはリポジトリを分割するメリット - リポジトリのサイズが小さくなり見通しが良くなる - それぞれで使う開発用のソフトウェアの設定等がごちゃごちゃしない - 特にスマートフォアプリもある想定だとSPAのフロントエンドもリポジトリはバックエンドと分けるべきである - バックエンドとフロントエンドのデプロイ先が違う場合に発生する問題 - バックエンドとフロントエンドのデプロイのタイミング違うとスキーマが変更された場合、障害が発生する - サービスをメンテナンスにして止めることはできる - サービスをできるだけ止めないように、WebAPIの変更したい - そのためスキーマの変更には非推奨`deprecated`機能を使う - OpenAPIとGraphQLで共通で行うこと - 下記のパターンに対応する - フロントエンドのTypescript型があることを利用して、存在しなくなったAPIを呼び出そうとする場合にビルドエラーにする - パターン - バックエンドがプルリクエストを受け付けた際の処理 - バックエンド側の自動テストや静的解析の他にやる作業として - フロントエンドのmainブランチにおいて - プログラム修正により発生したAPIスキーマをダウンロードし - APIスキーマからコードを自動生成 - フロントエンドのビルドおよび自動テスト - 目的 - プルリクエスト対象のブランチのバックエンドで生成したAPIスキーマを使って、常にフロントエンドのmainブランチをビルド及びテストするので、バックエンドでプルリクエストをマージしてデプロイした際に現在使用中のフロントエンドで障害が発生しない - フロントエンドがプルリクエストを受けた際の処理 - プログラムが自動テストする前にバックエンドからのスキーマを使ってやる前処理 - プログラム修正により発生したAPIスキーマをダウンロードし - APIスキーマから**非推奨をAPIを取り除く** - APIスキーマからコードを自動生成 - フロントエンドのビルド - 自動テスト - 目的 - バックエンドのmainブランチで生成した最新のAPIスキーマを使って、プルリクエスト対象のフロントエンドのブランチをビルド及びテストするので、フロントエンドでプルリクエストをマージしてデプロイした際に現在使用中のフロントエンドで障害が発生しない - このようにするとフロントエンドは非推奨のAPIを利用していることに気づき、常に最新のAPIを利用する ``` 【リライトした文章】 ```
ChatGPT
RailsとNext.jsを使ったスキーマ駆動開発による継続的インテグレーション:OpenAPI編
皆さん、こんにちは。今日は、バックエンドのRailsとフロントエンドのNext.jsを使ったスキーマ駆動開発での継続的インテグレーション(Continuous Integration、以下CI)についてお話します。特に、OpenAPIを使った取り組みにフォーカスします。ここではAPIのスキーマはバックエンドで生成し、Next.jsの実装はTypeScriptで行い、Githubを利用してコードをホスティング、Github actionsでCIを実行する前提としています。
バックエンドとフロントエンド:リポジトリの分割のメリット
開発プロセスの第一歩として、バックエンドとフロントエンドのリポジトリを分割することをお勧めします。その理由は主に二つです。
- リポジトリのサイズが小さくなり、全体像が見やすくなる。これはプロジェクトの管理やモジュールの追跡を容易にする。
- それぞれで使う開発用のソフトウェアの設定等が混ざることを防げる。特に、同時にスマートフォン用のアプリも開発している場合には、SPAのフロントエンドもリポジトリをバックエンドと分けるべきです。
しかし、リポジトリを分割することにより、バックエンドとフロントエンドのデプロイ先が異なる問題が発生します。
バックエンドとフロントエンドのデプロイ先の差異と対策
バックエンドとフロントエンドのデプロイのタイミングが異なると、スキーマが変更された際に障害が発生する可能性があります。サービスを一時的に停止させてメンテナンスすることは可能ですが、理想的にはサービスを可能な限り停止させないように、WebAPIを変更したいところです。そのため、スキーマの変更には非推奨deprecated
機能を活用します。
OpenAPIとGraphQLで共通に行うこと
OpenAPIやGraphQLを利用した開発では、以下の対応を行います。フロントエンドのTypescript型が存在するという特性を利用し、存在しなくなったAPIを呼び出そうとする場合には、ビルドエラーにすることが可能です。
パターン:バックエンドとフロントエンドがプルリクエストを受け付けた際の処理
プルリクエストがバックエンドやフロントエンドに提出された際、自動テストや静的解析以外に行うべき処理があります。これにより、バックエンドやフロントエンドでプルリクエストをマージしてデプロイした際に、現行のフロントエンドで障害が発生するリスクを防ぐことができます。
バックエンドがプルリクエストを受け付けた際の処理
- フロントエンドのmainブランチでプログラムの修正により発生したAPIスキーマをダウンロードします。
- APIスキーマからコードを自動生成します。
- フロントエンドのビルドおよび自動テストを行います。
これにより、プルリクエスト対象のバックエンドのブランチで生成したAPIスキーマを使って、常にフロントエンドのmainブランチをビルド及びテストすることができます。
フロントエンドがプルリクエストを受け付けた際の処理
- プログラムの自動テストを行う前に、バックエンドからのスキーマを使用して前処理を行います。
- プログラム修正により発生したAPIスキーマをダウンロードします。
- APIスキーマから非推奨のAPIを削除します。
- APIスキーマからコードを自動生成します。
- フロントエンドのビルドを行います。
- 自動テストを行います。
このプロセスにより、バックエンドのmainブランチで生成した最新のAPIスキーマを使用して、プルリクエスト対象のフロントエンドのブランチをビルド及びテストすることができます。
まとめ
上記のようにプロセスを設計することで、フロントエンドは非推奨のAPIを利用していることに気づき、常に最新のAPIを利用するようになります。これにより、開発の効率化と同時にサービスの安定性を確保することができます。
PR
XではUZUMAKIの新しい働き方や日常の様子を紹介!ぜひフォローをお願いします!
noteではUZUMAKIのメンバー・クライアントインタビュー、福利厚生を紹介!
UZUMAKIではRailsエンジニアを絶賛募集中です。
↓の記事を読んでご興味を持っていただいた方は、ぜひ応募よろしくお願いします!
是非応募宜しくおねがいします!