Torch プロジェクト

学祭を盛り上げるアプリを作りはじめます!(作りおわった) 2 韋駄天!バックエンド編

投稿日:

まめちしき : 1日2時間とかの睡眠を続けていると、だんだん時間感覚がなくなったり、ソファに座っていると意識が飛んで知らないうちに12時間経過して首の痛みを抱えたり、怪奇現象が発生します。

学園祭の盛り上がってる場所が知りたい

学園祭が始まる数日前、何かアプリを作ったら面白かろうということで、どこでどんなイベントがあって、どれくらい盛り上がっているかを表示するアプリ、その名も「Torch」を作ろうということになりました。

Torch メイン画面

ここでは、前回のUI/UX編に続き、爆速で仕上げられたバックエンドの話から。

MVCも無ぇ、MVVMも無ぇ、俺らの村にはレイヤードも無ぇ

Torchで採用したアーキテクチャ

RMSやgomaのバックエンドではレイヤードアーキテクチャの一種であるDDDが、フロントエンドではコンポーネントの設計(Vue.js)にMVVMが、ステートの管理(Vuex)にFluxなアーキテクチャが採用されています。近年のサービス開発の職場でも導入が増えているモダンなアーキテクチャですね。

Torchはというと、MVCでもMVVMでもDDDでもオニオンアーキテクチャでもなく……MVモデルを採用しています。Model-View。あのね、ぼくくん、PDS1って知ってるよね?この時代に密結合なアーキテクチャはだめだぞぉ。

[1]  PDS … Presentation Domain Separation。Martin Fowlerが提唱している、プレゼンテーションのロジックとドメイン知識のロジックを分離するという原則で、MVCなどのアーキテクチャの基本的な考え方

とはいえ、管見では、小規模・ワンオフ・モダン・(GoなどOOPでない)アプリには疎な設計にせず、密結合させたほうがよいのではないかと考えています。

どういうことなのか?

選択すべきアーキテクチャ、完全無欠のアーキテクチャ

山とあるOOPの原則や、日々増え続けるアーキテクチャの波、そうした大量の情報に流されない上手な判断の仕方はあるでしょうか?近年の流行に巻かれようという人もいるかもしれませんし、自分は知識があるから適切に判断できると自負する人もいるかもしれません。ある人が採る情報源、そこからくる自信は様々だとはいえ、全世界すべての知識を保有している人間はいないわけですから、結局のところ、完全で正しい設計とは仙人や神仏の手になるもののように思います。じゃあ、霞と桃だけ食う日々を送りましょうか、というわけにもいかないのが人間のつらいところです。配られたカード、今ある知識だけでなんとかプロダクトを作り上げ、口に糊するしかないわけです。そもそもイデアに近い設計かどうかなんて、サービスの売れ行きが変わるかというとそうでもない。問題が希望する形で解決されればそれでいいわけです。

さて、Torchの問題はというと、GPSとか使ってCRUDすればいいという問題のほかに、「時間がない」という最大の問題がありました。作り始めた時点ですでに円満リリースまでの猶予が48時間を切っており、開発人員は若干2名とインフラ・広報・開発補助部隊が数名、しかも開発人員の睡眠負債はテンコ盛り、要するに眠い!絶望!!こうした状態から、適切な言語、適切なアーキテクチャを採用する必要がありました。

MVCをおさらいする

古典的なMVCを概観するとこの図のようになります。ViewとModelの処理を分離し、コントローラーが橋渡しする。これがレイヤードアーキテクチャになるとModelからDBのCRUDをするRepositoryなどの層が出来たりしますが、そういうのは責任の分離に対する考え方が違うだけで、PDSに忠実な昨今のほとんどのアーキテクチャはこのMVCをベースに考えることができます。

Viewからの通信はControllerが受け取り、Viewの言葉をModelが喋れるようにしてModelに投げる。Modelでごにょごにょ処理が行われたら逆の手順でユーザーやBOTに通信を返す。こうすることで、ViewはModelの変更を意識せずに済むし、ModelはViewがやるフロントエンド的・フレームワーク的ゴタゴタを気にせずに済みます。この図ではControllerにポリモーフィズムを持たせてViewとControllerを疎にしていますが、そういう差異は別にしても、プログラマ諸兄は耳が痛いくらい聞かされた内容かと思います。

MVCを採用することで起こるメリットをざっくりまとめると、

  • プレゼンテーションロジックとドメインロジックを切り分け、変更を容易にできる
  • コードが部品化され、プレゼンテーションが増えたり変わったりしても再利用することができる

ということが言えるでしょう。

TorchのAPIサーバーはどうなっているかというと、ここからControllerを排し、ViewがModelを直接触る設計になっているほか、DBとのアクセスもレイヤード的なアプローチをせず、Modelが直に触りに行きます。(TorchのAPIサーバーにWebページの配信機能はないですが、便宜上図案化した)

「レイヤー間のプライバシーに踏み込むなんてセクハラ!なんでもかんでもべたべた触ったらOOPの良さが出ない!どうしてそんなむごいことを!」

いや、ぼくたち(バックエンドの開発者はぼくなのでぼく?)にとっては、これが正解だったのです。

ぼくたちはOOPのメリットを全部享受できない

なぜOOPは様々な原則やアーキテクチャに囲まれているのか?それは様々な開発上の問題を解決するためです。利用形態が増えることへの対応をしやすくするためとか、スパゲッティーコードを産まなくするためとか、複数人開発を楽にするためとか、ひとつひとつのテクニックが対処する問題は本当に多種多様ですが、全部の原則を盛り込んだだけではYAGNI部族のマサカリが飛んできてしまいます。

そこで、適切な原則を見つけるべく、Torch(のバックエンド)はどういうアプリケーションかを考えてみましょう。

  • Torchは、フロントエンドをVue.js(Nuxt.js / Vuetify.js)、バックエンドをGoで作り、APIを叩いて結果を表示するようなアプリケーションにする
    • これは開発の慣れから
    • たくさんのユーザーが同時にアクセスしていいねを連打することは決まっていたので、 バックエンドはできれば省メモリ・高速なマルチスレッディングの処理が求められていたためにGoが選ばれている
  • Torchは、ユーザーを識別する必要がない
    • いいねをするのが誰かは判別する必要がないと判断したため
  • Torchは、Protocol Buffersか multipart/form-data な通信をWAF(Echo)で受け取る
    • すでに資産があったため
  • Torchは、DBをMariaDBとし、DBとのアクセスにはORM(gorm)を使う
    • いちいちクエリ書いたりトランザクション張ったりマイグレーションを自分でやる時間がないため
  • Torchは、今回の学園祭のために作られている
    • 今回の学園祭で使わないのは論外だし、今回の学園祭以外で使うことはそこまで考慮していない
    • 実装する機能・利用するライブラリは開発中~EOLまで変更点はない
  • Torchは、バックエンドの開発はほとんど1人でやる

APIサーバー以外の機能を提供する気がさらさら無いので、APIサーバーだけ提供できればそれでよく、とはいえ通信する手段は複数あり認証できたとき・できなかったときの処理の分岐が要らず提供する機能を変更するつもりはなくDBとその利用方法も変更はなく、かつORMを利用しているためにほぼワンライナーでDBとデータをやりくりできGo/Echoを使っているので、不自由なOOPアプローチを強引にやるぶんアプリケーションにレイヤーを作るほどコード量が増えモジュールを密にして複数人の開発に向かない状態になってもいいアプリケーションだ、ということです。

つまり、DBの変更や、Model・View間の複雑な分岐や多態性といった事情を考えなくていいこと、レイヤーは減らさねばならないことが事前にわかっていたわけです。そのため、RepositoryはおろかControllerすら必要なく、Viewの多態性だけはあったのでプレゼンテーション層はドメインロジックから分離され、View・Modelの最小限のレイヤからなる設計になったのです。

まとめ

こうした理由から、Torchのバックエンドでは、MVモデルが採用されています。

……またまとめって言葉の意味が無に帰しましたが、些事ですね。

MVモデルのほかにも、リリース後に問題があったら即時解決するために開発部隊が継続してアサインされていたことからテストカバレッジは100%ではないままですし、nginxでフロントエンドと同Originになるようにリバースプロキシを張ることも決まっていたので、SSL化やCORS対策もやりませんでした。見た目的にそれっぽければいいということから、盛り上がり度合いは数学屋さんに殴られるくらいバイアスをかけて実装しましたし、レビュワーが忙しければPull Requestをセルフマージして後でバグが見つかったらまた対処するとかいうダーティな手段も採りました。

それでもぼくたちにとっては、ぼくたちの眠さ、ぼくたちの時間、ぼくたちの知識、ぼくたちのプロダクトでは、これが最善な解決策だったのです。

今回の開発で気付いたのですが、工房で深夜までカンヅメしたり、フリーランスまがいのことをして納品を遅滞させてしまったり、そんな生活を続けている間に、多少ではあるものの動くものが作れるようになっていたようです。大学に入って数年、開発実績が中学生のころのXNAとか.NET Frameworkな作品から進展がなく、研究室で太古のアプリケーションを発掘して動かすくらいしか才のなかった学生でしたが、ここにきてようやく工房に入ったうまみが出たように思います。まあ、自分の中での大きな変化があったところで、別に大学とか同級生から理解されるわけでもないですし、給料も単位も出ないので若干悲しくもありますが……。

それはそれとして、飯もロクに食わず風呂にも入れず睡眠も劣悪で、指が痛くなるほどの開発はこれっきりにしようとも思いましたし、数日間はエディタもターミナルも見たくありません。

次回はフロントエンド担当により、バックエンドよりさらに爆速な開発と、あるおばちゃんとの邂逅が語られる予定です。おたのしみに。

-Torch, プロジェクト

Copyright© ソフトウェア工房 , 2019 All Rights Reserved Powered by AFFINGER5.