webフロントエンドからwebAPIを呼び出すのをwrapするアレの名前

twitterに書いたやつ再掲+加筆。

Webフロントエンド、というかSPAの設計で、単なるwebAPIラッパーに対して「Repository」と名付けるケースが散見されるけど、ぼくはあれあまり好きではないです。というのも、Repositoryという名前がついてると、集約的なもの、それが言い過ぎならいわゆるEntity、それも言い過ぎならひとかたまりのデータを保存、取得するだけの責務のように思えるからです。けど、実際の「Repository」を見てみると、取得されるのは画面の仕様にベッタリなJSONだったり、更新系としてもなんちゃらidとパラメータを渡すようなIFになってることが多いですよね。画面の仕様にベッタリなJSONが返ってくるようになってたり、idとパラメータ渡すだけだったりするのは、多くの場合考えることが少なくて済むし通信量も減る良いプラクティスだと思うので、それ自体は問題ではないと思っています。ただ、Repository な責務でないものにRepositoryという名前をつけるのがあまり好きではない、という話です。

とはいえ、これは「好き嫌い」の問題なので、「このプロジェクトではそういう名前なんだよ」というのがチーム内で合意が取れてればそれはそれで、とも思います。ただ誤解は産みやすいからそこんとこコミュニケーションしっかりとりたいですね。

ちなみに、じゃあぼくがそれをなんて名前にするかですが、ぼくはよく「Gateway」という名前を使います。サーバーはフロントのSPAと異なるシステムなので、その境界をまたいだ処理を行う窓口だよ、という意味でのGateway。

以上がtwitterでしゃべったことです。以下は補足です。

いま扱ってるものが（たとえば）SessionStorageに保存しているものなのかネットワーク越しにあるシステムに保存されているものなのかを意識したくない、だからRepositoryという名前を使うんだ、という話もあると思うのですが、多くの場合APIサーバーは「たんにデータの出し入れ」じゃなくて、たとえば参照系のAPIなら集計をしたり、更新系のAPIなら複雑なロジックを実行したあとになにかを保存したり、それどころか別のシステムを呼び出して結果として誰かに通知が飛んだりなどが行われるかと思います。それと同等のことをローカルでできるでしょうか？もしできないとしたら、ネットワーク越しにあるシステムの呼び出しとローカルのストレージの読み書きを意識しない、なんてこと意味があるのでしょうか？また、仮にローカルでもおなじこと（集計やら複雑なロジックを伴ったデータの更新）ができるとして、その場合それって「Repository」なのでしょうか。Repositoryと言うには賢すぎる気がしますね。

もちろん、APIが完全にリソース志向で、ロジックはほとんどローカルにあります、みたいなアプリケーションなのであれば、そのAPIのwrapperをRepositoryとして扱うことが可能でしょう。たとえばあまりユーザー同士のインタラクションがなくて、クラウドは単なるデータ置き場である、みたいなアプリケーションの場合とかは、そういうやり方が適するかもしれません。また、ユーザごとの設定値のようなものについては、たしかにローカルに保存しているのかネットワーク越しのシステムに保存しているのかは意識したくないかもしれませんね。こういったものについては、自信をもってRepositoryとすればいいと思います。

そう考えると、もしかするとひとつのSPAの中で、このAPI呼び出しはGatewayという名前、あのAPI呼び出しはRepositoryという名前、ということが起こるかもしれません。これは良いことでしょうか悪いことでしょうか。ぼくは「良いこと」だと思います。一貫性がない？　けどそもそも、実装（それがローカル保存なのかネットワーク越しのシステム保存なのか）を意識したくないから、意識しなくていい名前をつけよう、という話だったはずです。そう考えると、「別のシステムに対する処理の移譲（その別のシステムがどこにあるかは意識しない）」についてはGateway、「データの保存と読み込み」についてはRepositoryを使う、というのはかなり筋が良いようにぼくには思えます。

というわけで、「webフロントエンドからwebAPIを呼び出すのをwrapするアレの名前」について考えてみました。みなさんのご意見もぜひ聞かせてください。

知識問題と思考問題

最近、高校の先生が「知識問題」「思考問題」という言葉を使ってらっしゃるのを聞いて、「なるほど、面白い分類だな」と思った。それ以来「知識問題と思考問題」という視点で物事を眺めるのが自分の中でブームとなっている。

もちろん、知識問題と思考問題というのはきれいにスパッとわかれるものではなく、グラデーション状になっていると思う。この問題はやや思考問題よりだね、とか、かなり知識問題に振れてるね、とか、かなり思考問題寄りだね、とか。

ソフトウェアの設計について考えてみると、じつは、ソフトウェアをどのようなレイヤーに分割するか、というような話はかなり知識問題寄りに見える。この問題には先人の知恵がたくさんあって、それらが「傾向と対策」として未知の問題にも流用しやすい。

一方で、レイヤーの内部をどのような責務でどのようクラス、コンポーネントに分割していくのかというのは、かなり思考問題よりに見える。このとき、設計原則などは役にたつが、それは「検算」的な部分で役に立つ感じで、問題とがっぷり四つに組んで頭に汗をかいて設計しなければならないように感じる。

これがマイクロサービシーズになってくると、どのようなマイクロサービスにどのような責務を負わせ、どのように分割するのかがかなり思考問題寄りで、サービス間の連携についてはけっこう知識問題に寄っているように思えるのがおもしろいところだ。

そんな視点で眺めてみると、去年ぼくがbuildersconで話した開発現場で役立たせるための設計原則とパターンという発表は、設計原則やパターンは、このように活用すると思考問題を解く際の武器にできるよ、という話をしているというように理解ができそうだ。一方、今年のbuilderscon に応募している（たのむ！採択されてくれ！）、Ruby (off|with) the Railsという発表は、かなり知識問題よりの領域を扱っていると思う。まあこの記事で言いたかったのはそういう予告です……。

ところで、知識問題を解くための武器とも思考問題を解くための武器だったら、なんだか思考問題を解くための武器のほうが「ありがたがられ」そうな気がするけど、これらに優劣はない、とぼくは思っている。思考問題を解くための武器は錆びつくのが遅いけど、一方で「すぐに役立てる」のが難しい。知識問題を解くための武器はすぐに陳腐化するけど、明日からすぐに役立てやすい。これらは優劣ではなく、性質の違いだ。

自分が問題に向き合ってる時に、いま知識問題に向かい合っているのか思考問題に向き合っているのかは少し意識してみると、自分がいま向き合うべき問題なのかを考えられたりとか、「知識問題だけど知識が足りないから、すぐ使えるやつを仕入れてこよーっと」みたいなムーブができたりとかできて良いかもしれない。いや、しかしこれは「知識問題だとわかるためには知識が必要」という問題があるか？

あー、でも、少なくとも、ジュニアエンジニアが知識問題に戸惑ってたらシュッと知識をインストールしてあげる、思考問題に戸惑ってたら本人の気づきをナビゲートしてあげる、みたいなことはできそうですよね。知識問題と思考問題という視点はけっこう便利であるなあと思います。

なんかとりとめない話になっちゃったけどブログだからいいよね。

rubyのString#splitのおもしろ挙動

RubyのString#splitは、下記のようなおもしろ挙動を持っている

"  a\nb \t c   \rd  ".split(' ') # => ["a", "b", "c", "d"]

これは（とうぜんのことながら）ちゃんとDocumentedである

docs.ruby-lang.org

1 バイトの空白文字 ' '
先頭と末尾の空白を除いたうえで、空白文字列で分割する。

便利なんだけど知らないでいると意図せぬバグを埋め込んでしまうかもしれないので、知っておいて損はないかもしれない（ぼくは今日知った）

RailsのControllerにApplicationService相当のロジックを書くのはありなしや？

誤解を産んでいそうだったので追記します。ここでいうApplicationServiceというのは、いわゆるレイヤードアーキテクチャのアプリケーション層のApplicationServiceレイヤの話です。別の言葉だと、「Usecase層」とか言う言葉で呼ばれたりするアレのことです。追記おしまい。

これについてです。

結論から先にいうと、ぼくは「正しい」と思っています（ただ、自分ではあまりやらず、ApplicationServiceに切り出しちゃいますが、これは好みの問題だと思っています）。

なぜ正しいと思うのか。それを考える際に、まずは「一般的に、なぜControllerとApplicationServiceを分けるべきなのか」について考えてみたいと思います。ControllerとApplicationServiceを分けるのは、PDSの文脈において、ControllerがPresentation（ユーザーとのインタラクションに関わる部分）のレイヤーに属すものであり、ApplicationServiceはDomainに属すものである、という理解がまずあるからだと思います。

では、なぜPDSが重要なのでしょうか。原典を引きましょう

  • プレゼンテーションロジックとドメインロジックが分かれていると、理解しやすい
  • 同じ基本プログラムを、重複コードなしに、複数のプレゼンテーションに対応させることができる
  • ユーザーインターフェイスはテストがしにくいため、それを分離することにより、テスト可能なロジック部分に集中できる
  • スクリプト用のAPIやサービスとして外部化するためのAPIを楽に追加できる（選択可能なプレゼンテーション部分で見かける）
  • プレゼンテーション部分のコードは、ドメイン部分のコードと違ったスキルと知識が必要

Martin Fowler's Bliki (ja)より

ぼくのことばで言い換えると、

  • プレゼンテーションはテストしにくいから、ドメインに分けておくとテストがしやすくなる
  • 責務が明確に分離されてわかりやすくなる
  • 他のプレゼンテーションレイヤーに差し替えが可能（Railsの例で言えば、ApplicationServiceに分離しておけば、たとえばTaskからも呼べる）

の三点が、PresentationとDomainを分離する際の嬉しいポイントです。ここで、RailsにおいてControllerにApplicationServiceを書いたときにどれだけこの問題が顕在化するかについて考えてみます。

まずは「プレゼンテーションはテストしにくいから、ドメインに分けておくとテストがしやすくなる」についてです。これ実はRails使ってるとあんま問題じゃなくて、というのもRailsってControllerのテストめっちゃふつうにしやすいじゃないですか。だからこれはあんまり問題にならないと思っています。

続いて、「責務が明確に分離されてわかりやすくなる」です。これについてはちょっと丁寧に見ていきましょう。おそらく、RailsでControllerとApplicationServiceを分離すると、Controllerの各メソッドは「1,2行書いておしまい」というメソッドになるでしょう（そうじゃなかったらちゃんと分離できてないと思ったほうがよさそう）。こうなると、「Controllerいる？」って感じになってきますよね。これが静的型付け言語の場合で、しかもVannila DIだったりCakePatternしてる場合なんかは、Controller部分でDIしてたりするので、Controllerに責務が残りますよね。あと、MVVMで作ってるGUIアプリケーションの場合、ローカルステートの管理などがVMの責務として残ります。けど、Railsの場合、ApplicationServiceをControllerから切り出すとそこに責務ってほとんど残んないんですよね……。あるとしたら認証とかかな。けどこれもControllerのテスト対象メソッドでやるんじゃなくて普通はレイヤスーパータイプとかでやってますよね。というわけで、なんか特殊なHTTPの言葉の部分触ってるとかそういうのがないのであれば（あーセッション周りとかはなにかしらあるかもですね）（しかしセッションって本来Infrastructureだよな〜）、「RailsにおいてはApplicationService相当のロジックをControllerに書くとする！」ってするのは十分にメイクがセンスするし、パルスのファルシのルシがパージでコクーンなのではないかとぼくは思います。

最後に、「他のプレゼンテーションレイヤーに差し替えが可能（Railsの例で言えば、ApplicationServiceに分離しておけば、たとえばTaskからも呼べる）」についてです。ここについては実はControllerにApplicationService相当のコードを書いてしまうと問題が顕在化します。TaskからApplicationServiceを呼び出すのはとても簡単ですが、TaskからControllerを呼び出すのは簡単ではありません。しかし、ちょっと立ち止まって考えてみると、ほんとうにそんな柔軟さはRailsアプリに必要なのでしょうか？？？今まで、「あー、TaskからController呼び出せたら最高なのにな〜」って思ったこと、あります？　ぼくはほとんどないです。そのために新たな層を導入して複雑さを引き受けるの、コストがペイするのでしょうか？パルスのファルシのルシがパージでコクーンなのでしょうか？

しかし、じつは、ここがぼくの「趣味」の部分で、ぼくはこれのためにApplicationServiceを分離してんですね。なぜか。そうすることで、たとえばテストの、しかも「前提データ」を用意するときに嬉しいことが起こります。Rails文化ではなぜか（なぜかと言ってしまおう）FactoryBotが人気で、FactoryBotを利用して前提データ（たとえば、ログイン可能なユーザーアカウントとかね）を作るプラクティスが横行していますが、ぼくは以前から、なぜここでみんな（たとえば）「UserSignupApplicationService」を作ってそれを呼び出すだけにしないんだろう、と不思議に思っています。適切にApplicationServiceが書かれていれば、UserSignupApplicationServiceを呼び出すだけで前提データは作れるはずです。FactoryBotを利用して前提データを作る場合、「サインアップ」の仕様が変わると「UserSignupApplicationService」と、「サインアップ済みユーザー」を作り出すFactoryBotを使った部分両方のメンテが必要になってきます。一方、FactoryBotではなくてApplicationServiceを利用すれば、ApplicationServiceのメンテのみで済みます。なぜ「テスト済みの、前提データを作れる部品」があるのに、FactoryBotを使う必要があるのでしょうか？

という観点に立つと、意外とApplicationServiceを分離することには価値がありそうですが、世の中的にはFacyoryBotが主流だし、「Railsにおいて」という前提に乗っかるなら、これはかなり「異端児の意見」であろうな、というのもわかるので、アンケートの答えとしては「正しい」を選ぶ、けど自分はあまりやらない。という感じになるわけでした！

以上、ぼくの意見です。みなさんの意見もぜひ聞かせてください。

Sounds Around (My Life) has released！

まずこちらをお聞きください。つるえさんというボーカリストの方に楽曲提供をさせていただきました。ぼくは作詞・作曲・編曲・コーラス・ギター・ベース・打ち込みを担当しています。

soundcloud.com

つるえさんと知り合ったのは荻窪にあるアルカフェというアコースティックライブバーで、初めてお会いした時にその歌のうまさに衝撃を受けたのをとてもよく覚えています（この音源も、ボーカル補正なしですよ。めっちゃうまくない？）。

歌がうまい、というのには、いくつかの要素があるとぼくは思っています。まず、ピッチが正確であること。自分の歌を棚に上げて言うと、これが大前提。そこから先は個性や好みの話が関わって来て、たとえば一聴してそのひとの歌だとわかる強い個性、あるいはクセを持ったボーカル、というのがひとつあると思います。日本のポップシンガーで言うと、たとえば山崎まさよしさんとか奥田民生さんをイメージしていただくとわかりやすいのではないでしょうか。

実は、つるえさんの歌唱にはそういう「一聴してこのひとだとわかるクセや個性」はあまりありません。ただ、誤解して欲しくないのは、ここで言っているのは、アーティキュレーションのクセや発音のクセの話であって、声そのものの話ではないです。つるえさんの声は、地の声に芯があり、その芯の周りにツヤのある響きを纏わせていて、とても魅力的な個性があると感じます。そして、おそらく意図的に、歌唱法で「ここはこういう表情」「ここはこういう表情」というのを非常に幅広く、自覚的に使い分けています。アーティキュレーションや発音に、強烈な個性がないからこそ、とても幅広く表情をつけていて、変幻自在ですごい。

そして、そういうボーカリストに出会ってしまった、自分自身は歌が下手なコンポーザーが思うことと言ったらひとつしかないですよね。「このボーカリストに歌ってもらう曲を書きたいなあ」。その夢がかないました。書きました。歌ってもらっちゃいました。それが冒頭に貼った「Sounds Around (My Life)」という曲です。

このコラボレーションは、スタジオ録音などをしているわけではなく、リモートでコラボしていて、なんとボーカル録りは「iPhoneのボイスメモ」でやっていただくという荒業を見せています。このあたりにもっとリソース使えれば、もっともっとダイレクトにつるえさんの歌の素晴らしさを音源に残すことができたのですが、それができなかったことだけがとても残念です（ていうか、その録音環境でこの歌のクオリティなの、いい意味でヤバすぎませんか？大事なことだから二回言うけど補正もほとんどしてないんですよこれ）。

そんな心残りはあれど、ぼくが思うつるえさんのボーカルの「美味しいところ」のためにメロディを作り、つるえさんの声の魅力の邪魔しないように控えめな、しかし丁寧な編曲を心がけて、つるえさんの声で聴いたらとても綺麗にイメージが届くであろう歌詞を頑張って書いて、つるえさんの歌が主役になるようにミックスをしました。ソングライター、アレンジャー、DTMerとしての「このボーカリストに歌ってもらいたい」というエゴにめちゃめちゃに素直になった結果、全ての要素がつるえさんのボーカルに奉仕するようなつくりになっています。これでつるえさんの歌の魅力が伝わらなかったとしたら、それはもう完全にぼくの力不足以外のなにものでもありません。ぜひ多くの方に聴いていただきたいと思います。よろしくどうぞ。

2019年のwebAPIの設計を取り巻く問題と技術シリーズ そのに 「ビジネスロジック」は誰が持つべき？

前回の記事の続きです。

前回は、「時代が変わるとサーバーアプリケーションの役割も変わるよね。そうすると必要な要素技術も変わっていくよね」という話でした。今回は、じゃあ「サーバーアプリケーションがJSON喋るマンになって、クライアントアプリケーションとの協働でユーザー体験が実現されるようになってきた今、"ビジネスロジック"はだれが持つべきなの？」って話をしたいと思います。

基本的にはサーバーでもってあげたほうが楽

さて、サーバーサイドでなんでもやる牧歌的な時代は過ぎ去り、クライアントサイドとサーバーサイドがコラボレーションしてひとつの体験を提供するようになった昨今、「そのアプリケーションの体験を成り立たせるための"ロジック"をどっちに書くのか」という問題が立ち上がってきます。わたしの私見ですが、これはなるべくならサーバーサイドで請け負ってあげるのがよいのではないでしょうか。その理由は、クライアントサイドにはクライアントサイド特有の複雑な問題を抱えているため、そのほかの問題はサーバーサイドで抱えてあげたほうが全体の複雑さが減るからです。

HTTPというのは基本的にステートレスなプロトコルです。そのため、基本的にはサーバーサイドの状態は1リクエストごとに閉じています。リクエストを受け付ける時にはまっさらな状態で、レスポンスを返すまでには様々な状態をもちそれらに対して様々な計算をして、レスポンスをかえします。このとき状態は一度破棄され（あるいはRDBなどの外部に書き出され）、次のリクエストのときにはまたまっさらの状態でそのリクエストを処理し始めます。

一方、クライアントサイドでは、ブラウザSPAアプリならばブラウザをリロードするか別のサービスに遷移するまで、メモリ上に状態を持ってしまいます。とうぜん、これはネイティブアプリでも事情は同じです。やったことのあるひとにはわかると思いますが、この状態の管理は、それだけでけっこうめんどくさいものです。

また、その「状態」から複雑な画面を構築しなければいけないというめんどくさい問題も、クライアントサイドは抱えています。画面作るのほんとに面倒で、そこにユーザーインタラクションがからむともっともっと面倒です。そういうめんどくさい問題を抱えているのに、さらに複雑なビジネスロジックまで押し付けられるのはあまりに大変ですので、困難を分割するためにも、サーバが出来る限り複雑さを引き受けてあげるのがよいのではないかと思います。

また、サーバーサイドに複雑なロジックを持っておくことで、複数のプラットフォームでのアプリ展開がやりやすくなる、という面もあります。たとえばiOSアプリもAndroidアプリもwebアプリも作る、というような場合に、クライアントサイドにビジネスロジックを持っている場合、それぞれのアプリで毎度実装する必要が出て来ますが、サーバーサイドでロジックをもってあげればサーバーサイド一回の実装ですみます。

また、クライアントサイドで一生懸命複雑なことをやったとしても、サーバーにとってリクエストは「だれから送られてきたかわからないもの」なので、結局サーバーサイドでデータの不整合が起こらないように検証はしなくてはいけません。そういった検証はまさにビジネスロジックの一部であり、クライアントサイドでビジネスロジックを持った場合、サーバーサイドでも重複したロジックを書かなければならない、というようなことは容易に起こり得ます。

ファーストパーティに閉じたサービスとサードパーティに開かれたプラットフォームの違い

しかし、これらの状況は、そのサービスが、ファーストパーティに閉じたサービスなのか、それともサードパーティに対して開かれたプラットフォームを目指すのかによって、事情が変わってきます。

ファーストパーティに閉じたサービスの場合、APIは「このアプリ専用」に作ることができます。いわゆる「顧客-供給者の関係」ですね。アプリ側の都合に合わせてAPIを作ることで、「複雑なビジネスロジック」をサーバー側が引き受けることになります。

一方で、サードパーティに開かれたプラットフォームの場合、不特定多数のクライアントに対して応答する必要があります。そのときに、サーバーサイドは、あるクライアントが解こうとしている問題に特化したAPIを提供するわけにはいきません。そんなことをしたら、クライアントの数だけAPIの種類が増えてしまいます。そのため、サードパーティに開かれたプラットフォームでは、サーバーサイド側になるべくロジックをもってあげることが難しくなります。プラットフォーム側の「ビジネスロジック」は薄くなる傾向があるでしょう。

しかしこれは、考えてみると当然のことです。というのも、プラットフォームというのは、「ぼくたちのデータや資源を使って、きみたちの問題を解決してね」というサービスなわけで、そうなってくるとどうしても問題を解く主体は、プラットフォームではなくてそのユーザーとなるでしょう。つまり、ユーザーは、ユーザーごとに異なる問題と向き合うことになるわけです。そのときに「ドメインロジック」がクライアント側にもたれるようになることは、ある意味当然となります。もちろん、このときプラットフォームにとっての「クライアント」が、webブラウザであるとは限りません。プラットフォームのユーザの選択によっては、webブラウザだけで完結するかもしれませんが、あるいはプラットフォーム利用者が自前でサーバーを立てて、そのサーバーサイドアプリケーションがプラットフォームにとってのクライアントとなるかもしれません。しかし、プラットフォーマーが持つサーバーアプリケーションは、特定の問題のための「ビジネスロジック」を持たない、ということには変わりがないでしょう。

まとめ

というわけで、まとめると、

  • 基本的には複雑なビジネスロジックはサーバーにもってあげるのが筋がよいと思う
  • 一方で、サードパーティに広く開かれたプラットフォームの場合はクライアント側にビジネスロジックを持ってもらい、サーバーはファンダメンタルな操作を提供するほうがよい

という感じになります。

前者の場合、最近だとリソース指向なAPI（いわゆるRESTfulなAPI）よりも「ユースケース指向」なAPIが増えてきていると感じます。ユースケースと1:1になるようなエンドポイントが生えてるようなAPIですね。

一方で後者の場合はユースケースはクライアントに依るので、mutationに関してはリソース指向のAPIがマッチしそうです。一方、リソースの取得についてはクライアントによってほしいデータが違うという問題があり、そのあたりにはGraphQLの恩恵がききやすいのではないか、という理解をわたしはしています。

次回書く気になれば、次回は

  • サーバーサイドに寄せられた、複雑なロジックやミドルウェアとのやり取りと向き合うための技術
  • クライアントサイドに残された「状態管理」と「複雑な画面」と「ユーザーインタラクション」と向き合うための技術

あたりを書けたらいいなと思います。が、もしかしたらtwitterでバーっと書いて満足してしまうかも……。

2019年のwebAPIの設計を取り巻く問題と技術シリーズ そのいち 導入

最近、2019年のwebAPIの設計まわりの問題について考えていて、問題とその周辺技術の整理を自分の頭の中でしています。　で、その内容をたぶん何回かに分けて書きますが、初回の今日はちょっと導入として浅めの部分を整理してみようと思います。

昨今、サーバーサイドの仕事はもっぱらJSONなどをしゃべることに終始して、エンドユーザーが触る画面をサーバーがレンダリングする事例は減ってきているのではないでしょうか。これはぼくが考えるに不可逆な事態で、今後もユーザーが使うインターネットにつながるデバイスは多様化していくし、それぞれがそれぞれにネイティブな環境を持ち、それらがHTTPSを喋ってインターネットとつながる、という世界はしばらく変わらないでしょう。言葉を変えれば、サーバーサイドでHTTPをしゃべるお客さんが、エンドユーザーからクライアントアプリケーションというプログラムに移行してきている、ということです。

その結果、サーバーサイドからは「複雑な画面を作る」という責務が奪われます。その結果がサーバーサイドアプリケーションになにをもたらすのかを考えてみたいと思います。

まず、Railsなどでよく使われる文脈でいう「decorator」は、昨今においてはその存在感を少しづつ失っていくでしょう(Pythonとかのデコレータとは文脈が違うので注意)。そもそも、この文脈におけるdecoratorは、「画面が要求する様々な"ちょっとした計算"」というプレゼンテーションの関心がモデル（ここでいう「モデル」というのはRailsの文脈でいうような「モデル」です）に混じってしまうことを避けるためのソリューションでした。しかし、昨今ではサーバーサイドアプリケーションがそのような複雑な画面をレンダリングすることはなく、jsonをペロッと吐けばいいだけです。そこには「画面が要求する様々な"ちょっとした計算"」は必要なく、むしろそれは画面を構築するクライアントサイドのプログラムでやってもらうべき仕事となるでしょう。

この「デコレータいらなくなったよね」という話は、牧歌的な「サーバーで全部やります」な時代が終わり、解くべき問題が変化した結果、必要な要素技術が変化していく1例として考えられるのではないでしょうか。ここで確認したかったのは、「デコレータがいらない」という話ではなく、　むしろ「問題がかわったら必要な技術が変化する」ということです。

さて、サーバーサイドからは「複雑な画面を作る」という責務が奪われたわけですが、昨今新たに出てきた新しい問題として、「じゃあサーバーとクライアントの間でどういう責務分割をするべきなの？」「サーバー側はサーバー側で昔と比べて複雑さ増してきてるよね？それをどうする？」というものがあります。次回以降、そのあたりの問題を整理しながら、どういう問題に対してどういう技術が効いてくるのかを書いていこうと思います。

まだ詳細未定ですが、予告としては、

  • webAPIとクライアントのどちらに「ロジック」を寄せるべきかという問いを整理
    • ファーストパーティに閉じたサービスとサードパーティに開かれたプラットフォームでの違い
  • ファーストパーティに閉じた場合
    • サーバーサイドに寄せられた複雑なロジックやミドルウェアとのやり取りとどう向き合うか、その解決としての設計パターンとmicroservices
    • クライアントサイドに残された「状態管理」と「複雑な画面」と「ユーザーインタラクション」とどう向き合うか、そのための技術、その解決としてのFlux系技術
  • サードパーティに閉じた場合
    • クライアントサイドにさらに積まれる責務とどう向き合うか、そのための技術（「いわゆる」DDD的な手法）
    • 多種多様なクライアントに対してどのようにレスポンスを返すのか、そのための技術（GraphQLあたりの話につながる気がしている）
  • コネクションにぎりっぱなし問題
    • なんか書くことあるかな。2019年においてはもうそろそろ書くことなくなってきてる気はする。

あたりを書きたい。本当に書くのかは不明。@qsonaさんあたりとtwitterで喋ったら満足して書かない可能性もあります。