Imported-from-Medium

１人でデスクトップとモバイル両方で動いて同期するアプリをどうやって作ったか

１人でデスクトップとモバイル両対応でデータ同期するアプリをどうやって作ったか

5プラットフォームで動くSaaSを個人で開発するためにやったこと

こんにちは、個人アプリ作家のTAKUYAです。InkdropというクロスプラットフォームなMarkdownノートアプリを１人で開発しています。このアプリはmacOS、Linux、Windows、Android、iOSで動作します。ご存知かもしれませんが、この5プラットフォームにアプリを対応させるのは簡単ではありません。しかしながらパワフルなフレームワークを活用すれば、それも不可能ではありません。それらに頼るだけでなく、プロジェクトを持続可能に保つための開発戦略も必要となります。本記事では、僕がこれまでどのようにして開発して来たのかシェアしたいと思います。

あなたは１人で開発しているのではない

クロスプラットフォームなアプリの開発は、往々にして多くの予測不能かつ再現不能な問題を伴います。自分の環境では正しく動いていた機能が、他の環境では思うように動かない。例えば、最近僕もそういう問題を経験しましたが、それは起動直後にアプリの画面が空白になるというものでした。僕は事前に入念にベータ配信を重ねてテストをしていましたが、それでもこの問題は見つけられませんでした。しかし、ユーザさんの素早い報告とやりとりのおかげで、24時間以内に解決する事が出来ました。

個人開発者は、実際には１人で開発しているのではありません。なぜなら、いつでもこのようにユーザに助けを求めることが出来るからです。正直に誠実に、今何を取り組んでいて何に困っているのか述べましょう。あなたのアプリを楽しんでいるユーザは、基本的にあなたのアプリの成功を願っていますし、喜んで助けようとしてくれます。ユーザの助けに頼ることはとても重要です。あなたのリソースはとても限られているからです。Inkdropもユーザの皆さんの協力がなければ、ここまでの完成度には到底辿り着けませんでした。Inkdropはプログラマ向けなので、このフォーラムでのケースのように、ユーザ側から問題を解決するためのコード例まで示してくれることもあります。その上、僕の手元で再現できないバグを修正するために、数時間も付き合って下さることもしばしばあります。このようなユーザとの緊密で双方向なコミュニケーションは、大企業に対抗できる大きな優位性でしょう。

CouchDB & PouchDB: シームレスなデータ同期とオフライン対応

Apache CouchDBはドキュメント指向データベース(NoSQL)で、HTTPベースのJSON APIを備えていて、かつマルチマスタで同期出来ます。FauxtonというウェブGUIがあり、データベースやドキュメントを簡単に管理できます。PouchDBはこのCouchDBにインスパイアされたJavaScript製のデータベースで、同様にCouchDBと同期出来ます。まず僕はデスクトップ版に取り掛かり、モバイル版は特に気にかけませんでした。というのも、PouchDBはJavaScript製で既にいくつかの選択肢が用意されていたので、大丈夫だろうと想定していました。もしうまく動かなければ、自分でモジュールを組めばいいと考えていました。CouchDBのAPIがRESTfulでシンプルだからです。

なぜ僕が他のfirebaseなどのPaaS (Platform-as-a-Service)ではなくCouchDBを選んだかというと、クライアント側での柔軟なインデクシングを必要としていたからです。3年前、僕がこのプロジェクトを始めた当時、firestoreは要件を満たすほど柔軟ではありませんでした。PouchDBはクライアントでのMapReduceに対応しており、全文検索用のモジュールもあったので有望だと判断しました。更に、CloudantというCouchDB用のDBaaSがあったのも決め手になりました。Cloudantはスループットやストレージサイズを柔軟に変えられます。サーバ運用は出来るだけ避けたかったので、最初の頃はこれを採用しました。現在はAWS EC2上でCouchDBを運用しています。理由は、BtoCサービスほど負荷が不安定だったり大きくないという事が分かったのと、Cloudantは重くて、IBM Cloud上での管理が煩雑さったためです。

今のところ、CouchDBとPouchDBの組み合わせは総じて満足しています。

クロスプラットフォームなフレームワーク

5プラットフォームで動かすために、デスクトップOS (Windows/Linux/macOS)ではElectronを、モバイルOS (iOS/Android)ではReact Nativeを採用しました。双方のバージョンでReactJSとReduxを使用しています。これらのフレームワークのおかげで、基本的にロジックは全部JavaScriptで組めましたし、デスクトップとモバイル間で多くのコードベースを共通化させる事が出来ました。

成功しているプロダクトから学ぶ

当時、ElectronとReactJSでアプリを組むのは初めてで知見がありませんでした。でも出来るだけ早くアプリを世に出してアイデアを検証したいと考えていました。そこで、美しいUIや拡張可能なアーキテクチャを組むための現時点でのベストプラクティスを手っ取り早く学ぶために、既存のオープンソースプロジェクトであるAtom EditorとKitematicに着目しました。これらのプロジェクトはGPLライセンスではなかったので、コードベースを自分のアプリに再利用出来る事を知りました。ありがとう、GitHubとDocker。

Kitematicのリポジトリをフォークする所から始めました。この方法は多くの良い実践を学べて、多くの問題を事前に回避できましたが、１つだけ欠点がありました — それは、技術的負債も一緒について来るという事です。技術的負債は多くのプロジェクトに大体あるものなのでしょうがないです。例えば、Kitematicはfluxアーキテクチャの実装としてAltJSを採用していました。しかしAltJSは僕がInkdropに着手した後、程なくして更新が止まってしまいました。それによって、Reactを最新版の16にアップグレードできずにいました。最終的にはAltJSをReduxと完全に置き換える事で対処しました。しかしながら、こういう事態は予期できないものです。Kitematic自身にとっても予想外だったでしょう。こういったプロジェクトから学べることは沢山あります。なので、僕がもしまた似たような状況になったら、進んで同じアプローチを取るでしょう。

また、Atomのコードを沢山お借りして、プラグイン機構、キーマップのカスタマイズ機能、テーマ機能などを実装しました。彼らのコードは読む度に発見があり驚きに満ちていました。これらを１人でイチから実装するなんて事は、到底できなかったでしょう。

コードベースを共通化する

デスクトップとモバイル版は両方共PouchDB、ReactとReduxで組んであるので、データモデルやRedux Action, Reducerなどプラットフォームに依存しない多くの部分を共通化出来ました。そのお陰で、両方を同時に効率よくメンテできるようになりました。

UIコンポーネント群はプラットフォームごとに組む

UIはデスクトップとモバイル版で分けて組みました。そもそも、まず最初にデスクトップ版から開発していましたし、自分が将来モバイル版をどうやって組むのかすら考えていませんでした。これは個人的な意見ですが、UIコンポーネント群をデスクトップとモバイル版で共有するのはあまり良い戦略ではありません（とりわけInkdropでは）。なぜなら、react-native-webのようなライブラリは基本的にモバイルファーストで、デスクトップにはフォーカスしていません。なので、もしアプリのUIがとてもシンプルで、主なターゲットがモバイルユーザである場合に限り有効な戦略だと思います。

デスクトップ版はSemantic UI、モバイル版はNative Baseを使って美しいUIとテーマ対応を実現しました。React Nativeに関する開発の知見はこちらの記事に書きました：

PouchDBをReact Nativeで動かすための四苦八苦

PouchDBはブラウザやElectron製アプリでは問題なく動作します。しかしReact Nativeとなるといくつか問題があります — pouchdb-react-nativeを使うと、AsyncStorageをアダプタにして動作するのでパフォーマンスが良くありませんでした。そこでreact-native-sqlite-2 と pouchdb-adapter-react-native-sqliteを作って、SQLiteをアダプタとして動作するようにしました。もう１つの問題は、attachmentsを上手く取り扱えないことです。これに関しては、PouchDBのコアモジュールを改造して対処しました：