OpenAPI 3 ファーストな Web アプリケーション開発(環境編)

2018/12/25
このエントリーをはてなブックマークに追加

ソフトウェアエンジニアの花岡です。今回は OpenAPI 3 ファーストな Web アプリケーション開発における以下のような弊社の環境について書いてみようと思います。

  • API ドキュメントの捉え方
  • OpenAPI 3 ドキュメントの最もシンプルな分割方法
  • OpenAPI 3 ドキュメントの CD と Slack 通知

API ドキュメントの捉え方

弊社では、これまで Developers Blog で何度か触れてきたように、Web API ドキュメントとして OpenAPI を利用してきています。

API ドキュメントの捉え方については Falcon の FAQ を引用したいと思います。

When it comes to API documentation, some developers prefer to use the API implementation as the user contract or source of truth (taking an implementation-first approach), while other developers prefer to use the API spec itself as the contract, implementing and testing the API against that spec (taking a design-first approach).

つまり

  • 実装ファースト: API 実装をユーザ契約として、その実装から API ドキュメントを生成する
  • 設計ファースト: API 仕様をユーザ契約として、その仕様を満たすように API を実装してテストする

の 2 種類に分類できます。ただし、実装ファーストといっても実装の詳細が契約になるわけではなく、Python でいうと marshmallow のような schema ライブラリで実装した schema などが契約になるという意味です。

現在私の参加しているプロジェクトでは後者の設計ファーストアプローチをとっています。このアプローチの一番のメリットは、API の実装をしなくてもフロントエンドエンジニアが OpenAPI ドキュメントを書いて開発を進めることができる点だと思っています。

openapi-generator などを使えば、API は OpenAPI ドキュメントからスタブ実装を生成することができ、フロントエンドの開発はそれで確認しながら進めることもできます。

また API を変更する場合、サーバサイドを知らなくても OpenAPI ドキュメントを変更するだけで(フロントエンドとしては)OK なのもメリットと思います。

一方でデメリットのうちのひとつは OpenAPI の仕様を理解して API ドキュメントを書いて、それをメンテナンスすることではないでしょうか? API の規模が大きくなると、1 つのファイルに書いていくことは大変で、分割する方法はいくつか Web で見つけることができます。

OpenAPI 3 ドキュメントの最もシンプルな分割方法

今回紹介する方法は、OpenAPI 3 ドキュメントのツリー構造をそのままディレクトリ構造にマッピングするというものです。つまり

.
|-- base.yaml
|-- build.sh
|-- components
|   |-- parameters
|   |   `-- pet_id.yaml
|   `-- schemas
|       |-- Pet.yaml
|       |-- PetNew.yaml
|       `-- PetUpdate.yaml
`-- paths
    `-- v1
        |-- pets
        |   `-- {pet_id}.yaml
        `-- pets.yaml

のようなディレクトリ構成に分割します。base.yaml は

openapi: 3.0.2
info:
  title: Example API
  version: 0.1.0

のようになっています。openapi.yaml をビルドするには、components と paths 以下のファイルに対して、相対ファイル名から .yaml を削除しインデントを調整しながら base.yaml に結合します。以下のようななかんじです。コードをきれいに(リライト)してくれる方を募集しています…

#!/bin/sh
#
# Usage: ./build.sh > openapi.yaml
#

here=$(dirname $0)

echo '# This file was auto-generated by build.sh.'
cat $here/base.yaml

(
    cd $here/paths
    echo 'paths:'
    for file in $(find . -name '*.yaml' | sort); do
        echo "  ${file:1:${#file}-6}:"
        sed 's/^/    /' $file
    done
)

(
    cd $here/components
    echo 'components:'
    for component in $(ls); do
        (
            cd $component
            echo "  $component:"
            for file in $(ls *.yaml); do
                echo "    ${file::${#file}-5}:"
                sed 's/^/      /' $file
            done
        )
    done
)

この方法のメリットは

  • 分割方法として最もシンプル
  • ディレクトリのツリー表示で API の path のツリー構造が把握できる
  • RESTful のリソース = OpenAPI の Path Item Object = ファイルがわかりやすい
  • OpenAPI 3 の Map 型に対してキーがファイル名になるため何も考えなくても一意になる
  • ファイルの移動で path が変わるのが楽しい

などがあります。

デメリットとしては個々のファイルで validate できないことです。そのため編集時には以下のように .yaml ファイルを watch して build してビルド結果の openapi.yaml を validate するようにしています。

{
  "scripts": {
    "build": "./build.sh > openapi.yaml && swagger-cli validate openapi.yaml",
    "watch": "chokidar '**/*.yaml' -i openapi.yaml -c 'npm run build'"
  },
  "devDependencies": {
    "chokidar-cli": "^1.2.1",
    "swagger-cli": "^2.2.0"
  }
}

間違ってもすぐにフィードバックが得られる状態です。

OpenAPI 3 ドキュメントの CD と Slack 通知

OpenAPI 3 ドキュメントの Web インタフェースとしては Swagger UI を使うのが簡単で openapi.yaml と同じディレクトリに以下のような index.html を配置して python3 -m http.server とすると localhost:8000 でいいかんじに OpenAPI 3 ドキュメントを確認することができます。開発時にローカルで確認するのに便利です。

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>API docs</title>
  <link rel="stylesheet" href="//unpkg.com/swagger-ui-dist@3/swagger-ui.css">
</head>
<body>
  <main id="swagger-ui"></main>
  <script src="//unpkg.com/swagger-ui-dist@3/swagger-ui-bundle.js"></script>
  <script src="//unpkg.com/swagger-ui-dist@3/swagger-ui-standalone-preset.js"></script>
  <script>
    window.addEventListener('DOMContentLoaded', function() {
      window.ui = SwaggerUIBundle({
        url: '/openapi.yaml',
        dom_id: '#swagger-ui',
        presets: [
          SwaggerUIBundle.presets.apis,
          SwaggerUIStandalonePreset,
        ],
        layout: 'StandaloneLayout',
      });
    });
  </script>
</body>
</html>

これを Google Cloud Build で App Engine の api-docs サービスとして CD してみます。

app.yaml は以下のようになります。

runtime: python27
api_version: 1
threadsafe: true
service: api-docs

handlers:
- url: /?$
  static_files: index.html
  upload: index\.html
  login: admin
  secure: always

- url: /openapi\.yaml
  static_files: openapi.yaml
  upload: openapi\.yaml
  login: admin
  secure: always

skip_files:
- ^(.*/)?#.*#$
- ^(.*/)?.*~$
- ^(.*/)?\..*$
- ^node_modules/

cloudbuild.yaml は以下のようになります。ここではブランチ名をもとにサービスのバージョンを決めています。

steps:
- name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args:
  - -c
  - |
    set -ex
    version=$(echo $BRANCH_NAME | tr [:upper:]. [:lower:]-)
    url=&#34;https://${version}-dot-api-docs-dot-$PROJECT_ID.appspot.com&#34;

    gcloud app deploy app.yaml --no-promote --version=$version --project=$PROJECT_ID --quiet
    echo &#34;{\&#34;gcb-tools.link\&#34;: {\&#34;name\&#34;: \&#34;API docs\&#34;, \&#34;url\&#34;: \&#34;${url}\&#34;}}&#34; &gt; $$BUILDER_OUTPUT/output

さらにデプロイした api-docs の URL を JSON 形式で $BUILDER_OUTPUT/output に出力しています。こうすることでビルド結果の Build.results.buildStepOutputs にステップごとの出力が含まれます(参考)。

https://cloud.google.com/cloud-build/docs/configure-third-party-notifications#slack_notifications をベースに Build.results.buildStepOutputs からリンク情報を取り出すと、こんなかんじに Slack 通知されます。

さいごに

OpenAPI 3 ファーストな Web アプリケーション開発に関する弊社の環境について書いてみました。次回は Python による API 実装などについて書きたいと思っています。

弊社では柔軟なこだわりのあるエンジニアのかたを募集しています。

その他の記事

Other Articles

2019/12/04
WebXR AR Paint その2

2019/11/06
GraphQLの入門書を翻訳しました

2019/09/20
Kabuku Connect 即時見積機能のバックエンド開発

2019/08/14
Maker Faire Tokyo 2019でARゲームを出展しました

2019/07/25
夏休みだョ!WebAssembly Proposal全員集合!!

2019/07/08
鵜呑みにしないで! —— 書籍『クリーンアーキテクチャ』所感 ≪null 篇≫

2019/07/03
W3C Workshop on Web Games参加レポート

2019/06/28
TypeScriptでObject.assign()に正しい型をつける

2019/06/25
カブクエンジニア開発合宿に行ってきました 2019夏

2019/06/21
Hola! KubeCon Europe 2019の参加レポート

2019/06/19
Clean Resume きれいな環境できれいな履歴書を作成する

2019/05/20
[Web フロントエンド] 状態更新ロジックをフレームワークから独立させる

2019/04/16
C++のenable_shared_from_thisを使う

2019/04/12
OpenAPI 3 ファーストな Web アプリケーション開発(Python で API 編)

2019/04/08
WebGLでレイマーチングを使ったCSGを実現する

2019/04/02
『エンジニア採用最前線』に感化されて2週間でエンジニア主導の求人票更新フローを構築した話

2019/03/29
その1 Jetson TX2でk3s(枯山水)を動かしてみた

2019/03/27
任意のブラウザ上でJestで書いたテストを実行する

2019/02/08
TypeScript で “radian” と “degree” を間違えないようにする

2019/02/05
Python3でGoogle Cloud ML Engineをローカルで動作する方法

2019/01/18
SIGGRAPH Asia 2018 参加レポート

2019/01/08
お正月だョ!ECMAScript Proposal全員集合!!

2019/01/08
カブクエンジニア開発合宿に行ってきました 2018秋

2018/12/23
いまMLKitカスタムモデル(TF Lite)は使えるのか

2018/12/21
[IoT] Docker on JetsonでMQTTを使ってCloud IoT Coreと通信する

2018/12/11
TypeScriptで実現する型安全な多言語対応(Angularを例に)

2018/12/05
GASでCompute Engineの時間に応じた自動停止/起動ツールを作成する 〜GASで簡単に好きなGoogle APIを叩く方法〜

2018/12/02
single quotes な Black を vendoring して packaging

2018/11/14
3次元データに2次元データの深層学習の技術(Inception V3, ResNet)を適用

2018/11/04
Node Knockout 2018 に参戦しました

2018/10/24
SIGGRAPH 2018参加レポート-後編(VR/AR)

2018/10/11
Angular 4アプリケーションをAngular 6に移行する

2018/10/05
SIGGRAPH 2018参加レポート-特別編(VR@50)

2018/10/03
Three.jsでVRしたい

2018/10/02
SIGGRAPH 2018参加レポート-前編

2018/09/27
ズーム可能なSVGを実装する方法の解説

2018/09/25
Kerasを用いた複数入力モデル精度向上のためのTips

2018/09/21
競技プログラミングの勉強会を開催している話

2018/09/19
Ladder Netwoksによる半教師あり学習

2018/08/10
「Maker Faire Tokyo 2018」に出展しました

2018/08/02
Kerasを用いた複数時系列データを1つの深層学習モデルで学習させる方法

2018/07/26
Apollo GraphQLでWebサービスを開発してわかったこと

2018/07/19
【深層学習】時系列データに対する1次元畳み込み層の出力を可視化

2018/07/11
きたない requirements.txt から Pipenv への移行

2018/06/26
CSS Houdiniを味見する

2018/06/25
不確実性を考慮した時系列データ予測

2018/06/20
Google Colaboratory を自分のマシンで走らせる

2018/06/18
Go言語でWebAssembly

2018/06/15
カブクエンジニア開発合宿に行ってきました 2018春

2018/06/08
2018 年の tree shaking

2018/06/07
隠れマルコフモデル 入門

2018/05/30
DASKによる探索的データ分析(EDA)

2018/05/10
TensorFlowをソースからビルドする方法とその効果

2018/04/23
EGLとOpenGLを使用するコードのビルド方法〜libGLからlibOpenGLへ

2018/04/23
技術書典4にサークル参加してきました

2018/04/13
Python で Cura をバッチ実行するためには

2018/04/04
ARCoreで3Dプリント風エフェクトを実現する〜呪文による積層造形映像制作の舞台裏〜

2018/04/02
深層学習を用いた時系列データにおける異常検知

2018/04/01
音声ユーザーインターフェースを用いた新方式積層造形装置の提案

2018/03/31
Container builderでコンテナイメージをBuildしてSlackで結果を受け取る開発スタイルが捗る

2018/03/23
ngUpgrade を使って AngularJS から Angular に移行

2018/03/14
Three.jsのパフォーマンスTips

2018/02/14
C++17の新機能を試す〜その1「3次元版hypot」

2018/01/17
時系列データにおける異常検知

2018/01/11
異常検知の基礎

2018/01/09
three.ar.jsを使ったスマホAR入門

2017/12/17
Python OpenAPIライブラリ bravado-core の発展的な使い方

2017/12/15
WebAssembly(wat)を手書きする

2017/12/14
AngularJS を Angular に移行: ng-annotate 相当の機能を TypeScrpt ファイルに適用

2017/12/08
Android Thingsで4足ロボットを作る ~ Android ThingsとPCA9685でサーボ制御)

2017/12/06
Raspberry PIとDialogflow & Google Cloud Platformを利用した、3Dプリンターボット(仮)の開発 (概要編)

2017/11/20
カブクエンジニア開発合宿に行ってきました 2017秋

2017/10/19
Android Thingsを使って3Dプリント戦車を作ろう ① ハードウェア準備編

2017/10/13
第2回 魁!! GPUクラスタ on GKE ~PodからGPUを使う編~

2017/10/05
第1回 魁!! GPUクラスタ on GKE ~GPUクラスタ構築編~

2017/09/13
「Maker Faire Tokyo 2017」に出展しました。

2017/09/11
PyConJP2017に参加しました

2017/09/08
bravado-coreによるOpenAPIを利用したPythonアプリケーション開発

2017/08/23
OpenAPIのご紹介

2017/08/18
EuroPython2017で2名登壇しました。

2017/07/26
3DプリンターでLチカ

2017/07/03
Three.js r86で何が変わったのか

2017/06/21
3次元データへの深層学習の適用

2017/06/01
カブクエンジニア開発合宿に行ってきました 2017春

2017/05/08
Three.js r85で何が変わったのか

2017/04/10
GCPのGPUインスタンスでレンダリングを高速化

2017/02/07
Three.js r84で何が変わったのか

2017/01/27
Google App EngineのFlexible EnvironmentにTmpfsを導入する

2016/12/21
Three.js r83で何が変わったのか

2016/12/02
Three.jsでのクリッピング平面の利用

2016/11/08
Three.js r82で何が変わったのか

2016/12/17
SIGGRAPH 2016 レポート

2016/11/02
カブクエンジニア開発合宿に行ってきました 2016秋

2016/10/28
PyConJP2016 行きました

2016/10/17
EuroPython2016で登壇しました

2016/10/13
Angular 2.0.0ファイナルへのアップグレード

2016/10/04
Three.js r81で何が変わったのか

2016/09/14
カブクのエンジニアインターンシッププログラムについての詩

2016/09/05
カブクのエンジニアインターンとして3ヶ月でやった事 〜高橋知成の場合〜

2016/08/30
Three.js r80で何が変わったのか

2016/07/15
Three.js r79で何が変わったのか

2016/06/02
Vulkanを試してみた

2016/05/20
MakerGoの作り方

2016/05/08
TensorFlow on DockerでGPUを使えるようにする方法

2016/04/27
Blenderの3DデータをMinecraftに送りこむ

2016/04/20
Tensorflowを使ったDeep LearningにおけるGPU性能調査

→
←

関連職種

Recruit

バックエンドエンジニア(Python・Go)

業務内容

当ポジションは弊社Webサービスのバックエンド機能設計及び実装を担当します。 サービス毎の開発チームで2週間スプリントのスクラム開発を実施しています。 週次で開発チームミーティングを実施し、実装設計の相談や工数見積もりを行います。 全ての開発コードはレビューと自動テストによって品質を保っています。 また、リファクタリングやフレームワークのバージョンアップも開発フローに組込み、技術的負債を放置しない開発を目指しています。

フロントエンドエンジニア(TypeScript)

業務内容

当ポジションは弊社Webサービスのフロントエンド機能設計及び実装を担当します。 サービス毎の開発チームで2週間スプリントのスクラム開発を実施しています。 週次で開発チームミーティングを実施し、実装設計の相談や工数見積もりを行います。 全ての開発コードはレビューと自動テストによって品質を保っています。 また、リファクタリングやフレームワークのバージョンアップも開発フローに組込み、技術的負債を放置しない開発を目指しています。

インターン(Webエンジニア)

業務内容

業務から独立した、調査・研究系のタスクをおまかせしています。コードレビュー、 社内での報告会、 ブログ記事執筆を通して着実にスキルアップしていただくことを目指しています。 (希望があれば、プロダクトの開発業務もおまかせします。)

→
←

お客様のご要望に「Kabuku」はお応えいたします。
ぜひお気軽にご相談ください。

お電話でも受け付けております
03-6380-2750
営業時間:09:30~18:00
※土日祝は除く