webフロントエンドからwebAPIを呼び出すのをwrapするアレの名前 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

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

[shimmering]

gatewayという呼び方ありな気もするけど直接意味が伝わってこないことのデメリットが大きい気がするのでapi派

[nunulk]

"単なるwebAPIラッパーに対して" であるのならば、api という名前でいい気はするけど、repository や gateway みたいな比喩的な名前にするメリットを知りたくもある（詳細を隠す、というのはメリットなんだろうか…🤔

[ryousanngata]

深く考えずにHogeServiceとかにしちゃってます

[infobloga]

自分Resourceって良く使う。その実装は、localStorageだったり、Indexed DBだったり、Web APIだったり、あるいは、ネイティブのプラグインだったりするので、それらを包括する用語として。

[takezaki]

vte.cxではサービスと呼んでいる>“webフロントエンドからwebAPIを呼び出すのをwrapするアレの名前”

[laiso]

わかる。全然いい名前思いつかない。画面のためのひとまとまりのデータをページ送り可能な単位で取ってくるものの名前が欲しい

[uehaj]

ServiceWorkerで抽象化したい

[a_suenami]

ブコメに対するブコメになるけど、生えてるメソッドがget(path)とかpost(path)とかだったらapiとかapi_clientとかで、search(conditions)とかcomment_to(article)とかだったら一段階も二段階も抽象化されてるので別の名前にしますね