APIチームでエンジニアをしているkotegawaです。CalendarではAPIのスキーマ駆動開発についての記事を書いて、APIの基盤を整える話をしました。APIを使ったアプリのプラットフォームに60以上のアプリが並ぶほどの盛況ぶりになっています。今回はそんなfreeeのAPIを使ってAPIチームがFirebaseを使って自らアプリを作ってみた話をしてみます。2019の21日目の記事です。会計のWebアプリを作った背景そもそも本体のアプリを作ろうとした背景は2つあります。freeeのAPIを使った業務アプリのユースケースを提供したいfreeeのAPIは10月にも31種類のendpointが追加されるなど、かなりのペースで増えています。一方で会計という業務ドメインの複雑な性質上、リソースベースで多くのRESTfulなAPIを提供していても、「具体的にどんなアプリを作ればいいのかわからない」「それぞれのAPIの使いみちがわからない」というフィードバックをもらうことがよくありました。APIを使った業務アプリを開発して価値提供しつつ、そのアプリをサンプルユースケースとしてアプリストアに公開しようというのがアプリを作ろうという判断になった直接的な理由です。モノリシックになりつつある本体リポジトリとは切り離して、素早く仮説検証したいfreeeは今や、個人事業主から上場企業の方々まで、幅広いユーザーに使って頂いています。幅広いユーザーに価値を届けられているというのは大変誇らしい一方で、すべてのユーザーに同じインターフェースや仕様で満足していただくのは日々難しくなっているのも現実です。事業所の規模や業種によって運用もまちまちです。これらの機能を実装するには今までfreeeにはなかったデータの概念を持ち込む必要がありますが、リリースから7年近くが経過している会計freeeのリポジトリで、データ構造を変更したりアプリケーションロジックを大きく変更しようとすると、大きなコストがかかってしまいます。そこで、クイックに仮説検証サイクルを回してより多くのユーザーにハマるUI/UX・仕様を探る手段としても、本体のプロダクトとは完全に疎にアプリを作るのは合理性があるという判断になりました。Firebaseを選択したか社内のプロダクトは基本的にAWS上で作られていますが、今回スモール業務アプリをクイックに作成する上で「freee本体とは疎に作る」という前提があったため、技術選定に制約がない中、Firebase/GCPの利用を選択しました。その最も大きな理由としては、Webアプリ構築コストの低さと認証機能の充実度にあります。Webアプリ構築コストの低さFirebaseでのWebアプリはサーバーレスで低コストで構築できます。CSS)をデプロイ・ホストできる。Firestore・・・NoSQLのデータベース(ネストできるKVSのイメージ)。オブジェクトストレージFirebaseのSDKやリファレンスはかなり充実しているのでこれらの構成要素の繋ぎこみやデプロイもローコストで実現できました。サーバーを立ててミドルウェアの設定を書いてネットワークの設定をして・・・という従来私が経験していたフルスクラッチのWebアプリ開発と比較して、かなりコストが低くなったのを感じました。充実した認証機能Firebaseの特徴の一つとして、認証機能が充実している点が挙げられます。Firebaseでデフォルトで提供されているログインプロバイダその中でも今回は、「カスタム認証」という、Firebaseの認証サーバーをから特定のタイミングでログイン用のトークンを発行できる機能を使いました。Connectのような認証基盤を持っていないため、freeeと疎にアプリを作ろうとすると、通常アプリ用のID/Passwordを持つか何か他のログインプロバイダを利用する必要があります。このカスタム認証を使えば、アプリの見かけ上、「freeeアカウントを使ってアプリにログイン」という動きを実現することができます。「カスタム認証」を用いた認証の流れこの認証の仕組みをざっくりと解説すると、以下のようになります。FunctionsでFirebaseのカスタムトークンを取得し、そのトークンが有効であればログイン中のセッションとみなすかんたんに図にまとめてみました。カスタム認証のフローこのカスタム認証を利用するために、ユーザーはわざわざアプリ用のID/Passwordを準備しなくても済むようになり、アプリ側でもログイン情報の管理が不要になります。カスタム認証に関しては、LINEなどを例にしたサンプルコードも公開されているので、大いに参考になりました。APIを利用しているアプリの特性上、freeeのAPIをコールする上でアクセストークン、リフレッシュトークンの利用が必須です。これらの情報はアプリ上で永続化しておかないと、APIコールのたびにユーザーに認可してもらわないといけなくなってしまいます。いえ、アクセストークン、リフレッシュトークンをそのままFirebaseに保存しておくわけにはいかないので、暗号化には少し工夫が必要でした。オペレーションという従量課金制を見て少し足がすくみ、他の手段を考えることにしました。今回採用した手段は、このようなものです。Rotateするセキュアな情報の取り扱いこのあたりのロジックは、後述するサンプルアプリのリポジトリにも反映させているので、興味があれば参考にしてみてください。Accountという役割を紐付けて特定の権限を付与したり外したりできるので、そのへんをうまくコントロールしていくのがポイントになります。デプロイの運用FirebaseのCLIはかなり充実していて、ログインからプロジェクトの作成・選択、デプロイまでワンコマンドで実行可能です。Functionsを同時にデプロイできるなど、projectの構成要素を「1アプリ」としてまとめて本番にアップロードすることができるので、開発をしていくうえではとても便利です。一方で、本番環境のアプリも誰でも手元のCLIからデプロイができてしまう状況を作ってしまうのはリスキーなので、CIからしかデプロイができないようにするといった仕組み作りが必要になります。freeeとそのSDKを使ったサンプルアプリをβ版としてリリースしました。APIをコールするwrapperが含まれており、そのロジックを用いてサンプルアプリを実装しています。APIに興味がある方がいれば、是非使ってみてください。さんによる脆弱性診断と管理の話です。やっている土佐と申します。みなさん、障害訓練てやってますか?やんなきゃいけないとは思いつつ、なかなか腰が重くなる仕事ですよね?わかります。当社では、今年の10月に大規模な障害訓練を実施し、非常に多くの学びがあり、継続的にやっていこうと意識が高まっております。この記事では、訓練の企画から実施までを円滑に実施するために、ある程度フレーム化したものを紹介したいと思います。障害訓練の参考になればと思います。粟津さんの知見がふんだんに盛り込まれています。彼がいてくれて本当によかったと心から思います。重い腰をあげる専任の担当者がアサインされてでもしていない限り、片手間での対応にならざるを得ないのが障害訓練です。日々忙しいなか、どうしても腰が重くなってしまいますよね。これをエイっと、みんなの「よしやるか!」を引き起こすための何かが必要になってきます。汎用的な手段ではないかもしれませんが、当社では標語を作りました。