追記(2020) - 本サービスは終了しています。
お断り
特に技術的に特別なことをしているわけではないので、実質サービスの宣伝ポストです。ごめんなさい。
どんなサービス?
自分のWebサイトにダウンロードストア機能を追加して、デジタルデータを簡単に販売できるようにするサービスです。
↑こんな感じのバッジをホームページやブログに配置できます。
インフラ
AWS EC2 + RDSの鉄板構成です。Route 53がDNSです。
本当はRedisを使いたかったのですが、サーバー代が捻出できないのでスティッキーセッションです。
アップロードされたファイルはS3に突っ込んでいます。
デイジョブではオンプレのサーバーばかりだったので、実はクラウドをきちんと使ったのは初めてでした。あまりの便利さに驚いているところです。
あとは値段がもう少しわかりやすくなれば良いのですが。
ログにはSentryを使っています。サーバーの監視にはAntruisです。いつもSSL証明書の更新を忘れるので……。
バックエンド
プログラミング言語はKotlinです。Javaと同じ感覚で使え、Javaの悪いところが治っているいい言語です。ScalaやClojureを選ばなかった理由は、私がScalaを使えるほど頭がよくなかったからです。KotlinはJavaプログラマーにとってなじみ深い作りで、安心してプログラミングができました。
HTTPサーバーにはRatpackを使用しています。これに関しては、おとなしくSpringにするかだいぶ迷いました。
- IoCコンテナー - 機能がコンテナーに強く統合されすぎている
- アノテーション - 何をするにもアノテーションが必要
- 重くて遅い
結局、単なるHTTPサーバーが欲しいだけなので、Springは「全部入り」なのが嫌でRatpackを選択しました。一方で、実際にRatpackを使ってみて、期待通りにいかなかったこともありました。
特にアプリケーションのロジックをサーバーと分離するという点では、Ratpackがノンブロッキングなサーバーという点で、ロジック中にPromise
が散らばってしまいました。「DBアクセスだけだから大きな影響はない」と考えていたのですが、Webアプリケーションだと大抵の個所にDBアクセスが絡むため、結局Ratpackと強く統合されてしまいました。分かりやすいAPIと使いやすさは気に入っているのですが、やはりJavaでノンブロッキングなフレームワークは無理があったかもしれません。
理想的なフレームワークを探し続けているのですが、なかなか見つかりませんね。HTTPサーバーを決めるのは、本当に聖杯探しの旅のようなものです。
フロントエンド
正直私はフロントエンドに詳しくないので、もっといいやり方があるのではないかと思っています。改善していきたいです。
フロントのコードはTypeScriptとVueで書いています。
KotlinのJavaScriptランタイムを使うことも検討しましたが、JavaScriptフレームワークは当たり前ですがJavaScript向けに書かれているので、AltJS言語ではどうしても自然に書けない部分が生じてきます。TypeScriptの良いところは、JavaScriptのスーパーセットとして、多くのフレームワークで違和感なく利用できるところです。特にVueは標準でTypeScriptのサポートがあるので、期待通りに使うことができました。
VueはReactよりもずっと導入が簡単なことが魅力だと思います。Vueのテンプレートは賛否両論あるでしょうが、JSXのようにプリプロセッサが必要ないのはメリットかと思います。
フロントのビルドにはnpmとGulpを使っています。GradleのタスクからGulpを呼ぶようにしています。
task buildTypescript(type: FluentExec, dependsOn: resolveTypescript) {
windows 'cmd', '/c', 'npm run build'
linux 'npm', 'run', 'build'
}
バンドラーはrollupです。webpackはGulpと相性が悪そうだったのでrollupを選んだのですが、webpackでもよかったかもしれません。
Babelを通してgulp-uglifyして完成です。
まとめ
技術面では、今後の安定性や拡張性がどうなるか、課題になってくると思っています。「プロダクトは技術が原因で失敗しない」とは言いますが、やはり使っていて楽しい技術を選びたいものです。
改善点はいろいろと残っていると思います。MVPという言い方は好きではありませんが、「動くものを出せ」の原則に従ってリリースです。
今後も改良を続けていきたいと思います。