読者です 読者をやめる 読者になる 読者になる

SwiftのWeb APIとアプリをともに構築する | try! Swift Tokyo 2017 #tryswiftconf Day1-11 聞き起こし

twitter.com

この講演では、私たちのiOSアプリの1つを動かすためにSwiftでWeb APIを構築した経験を共有します。既存のインフラとWebサービスをSwiftでどのように書きかえたのかを説明します。SwiftでのWebサービス構築に必要なことと、ハイパーメディアと宣言型プログラミングを活用して長年進化していけるAPIを設計し利用する方法を探ります。

SwiftのWeb APIとアプリをともに構築する

f:id:niwatako:20170302163115j:plain

f:id:niwatako:20170302163115j:plain

f:id:niwatako:20170302163141j:plain

良いAPIとは

実装が漏れ出ない

f:id:niwatako:20170302163213j:plain

ページネーションが必要になる

f:id:niwatako:20170302163257j:plain

個々のページの投稿を取得出来る

f:id:niwatako:20170302163318j:plain

このような形でAPIがデザインされています。

次のページを要求する前にページが変わってしまう場合、内容が重複します

f:id:niwatako:20170302163347j:plain

この問題をどう解決すべきでしょう。クライアント側で回避もできますが、API側で対応することもできます。

f:id:niwatako:20170302163423j:plain

f:id:niwatako:20170302163427j:plain

idによってそれよりも前の投稿を取得する。

ではこの変更をどう導入すべきでしょうか

f:id:niwatako:20170302163440j:plain

APIを分けてしまう方法がよくあります。

f:id:niwatako:20170302163505j:plain

バージョニングをパスに用意する。

f:id:niwatako:20170302163556j:plain

既存のAPIのデザインを残していくということも残していくことが難しいわけです。APIが上手く機能していくことが必要になります。あるいは古いバージョンをサポートすることですが、実装の詳細を露呈せずにAPIを提供できるならこの問題を解決できます。

f:id:niwatako:20170302163718j:plain

Restはサーバーとクライアントが独自に変化していくことを想定する

f:id:niwatako:20170302163745j:plain

f:id:niwatako:20170302163751j:plain

f:id:niwatako:20170302163829j:plain

f:id:niwatako:20170302163838j:plain

HypermediaはRESTの重要な部分で進化性を担保します

f:id:niwatako:20170302163900j:plain

f:id:niwatako:20170302163923j:plain

f:id:niwatako:20170302163926j:plain

f:id:niwatako:20170302163958j:plain

状態遷移を内部で探すことも出来る。アプリケーションを使ってすぐに新機能を提供できアプリケーションを将来的に変えなくて良くなる。

標準化タイプ

f:id:niwatako:20170302164028j:plain

f:id:niwatako:20170302164042j:plain

f:id:niwatako:20170302164053j:plain

f:id:niwatako:20170302164104j:plain

f:id:niwatako:20170302164155j:plain

例えば投稿者であれば削除ができます

f:id:niwatako:20170302164207j:plain

クライアントはデザイン上、DeleteAfordanceが存在するかを先にチェックする。存在するかと誰が可能化を切り分けることが出来る。

クライアントがビジネスロジックを気にしなくなる。

f:id:niwatako:20170302164303j:plain

f:id:niwatako:20170302164333j:plain

HyperMediaを使うことで分離ができる

f:id:niwatako:20170302164344j:plain

言語の変更に加えて実装を行う時にクライアントを壊さない

FrameworkにはKitura、Vaporがあります。

f:id:niwatako:20170302164428j:plain

KituraはIBMのプロダクトなので非常に強いバックです。

私はFrankを使いました。軽量フレームワークです。

f:id:niwatako:20170302164504j:plain

Frankはドメインに特化している。

f:id:niwatako:20170302164530j:plain

f:id:niwatako:20170302164536j:plain

様々な変化が起きています。AppleでWorkingGroupもできています。

新しい対処も生まれるかと思います。

f:id:niwatako:20170302164601j:plain

Swift環境においてWeb環境の作り方をリストしたので後でみて下さい。

コードは割愛してテスト、モニタリングの組み合わせもお話します。

f:id:niwatako:20170302164618j:plain

f:id:niwatako:20170302164648j:plain

f:id:niwatako:20170302164700j:plain

f:id:niwatako:20170302164714j:plain

f:id:niwatako:20170302164714j:plain

f:id:niwatako:20170302164725j:plain

定義して実装してAPI Descriptionを使ってテストできる。

f:id:niwatako:20170302164743j:plain

Herokuが最もシンプルでコードを投げればOKです。

f:id:niwatako:20170302164758j:plain

パッケージを作って依存性無く使うことができます。

f:id:niwatako:20170302164820j:plain

f:id:niwatako:20170302164821j:plain

Swiftバージョンも指定できます。

コマンドラインツールで実行できます。

f:id:niwatako:20170302164855j:plain

それ以外のオプションはIBMのBluemixです。

f:id:niwatako:20170302164905j:plain

Dockerを使うこともできます。

f:id:niwatako:20170302164921j:plain

マニュアルでデプロイすることもできます。

デプロイしたらモニタリングしたくなります。

f:id:niwatako:20170302164938j:plain

f:id:niwatako:20170302164956j:plain

f:id:niwatako:20170302165002j:plain

f:id:niwatako:20170302165008j:plain

たとえばPapertrailで特定のインシデントをみていくことが出来る。

f:id:niwatako:20170302165026j:plain

WebAPIは正しくデザインすることが大事です。 言語に依存しない形で人気のツールを使うのが良いでしょう。 モニタリングの話もしました。 APIライフサイクル全体の話をしました。明日はプログラミングの部分のお話もあると思います。

f:id:niwatako:20170302165115j:plain

Resource

Kyle Fuller

Q&A

オススメフレームワーク

Sorry couldn'n write (XωX)

APIドキュメンテーションのお話が途中で出てきました。サンプルでAPI Blueprintが出ていましたが他にも色々Specがあると思いますがおすすめはありますか

  • 3つAPI Description候補
    • API BluePrint -デザインファーストなのでオススメ。みて実装しやすい
    • ほかに、swagger, RAMELがあります。

APIが既に構築されていたらswaggerが選ばれている。OpenAPIになっている。