for Startups Tech blog

このブログのデザインを刷新しました。（2023/12/26）

【フォースタ テックブログ】デザイナーがコーポレートサイトをノーコードツールのWebflowを使ってリニューアルした話

 

フォースタートアップスは2021年7月にコーポレートサイトの大幅なリニューアルを行いました。

www.forstartups.com

今回、このリニューアルに関わったデザイナー2名（甲斐・長峰）より、ノーコードでWebサイト制作ができるWebflowを利用するに至った背景や、グラフィックについてのこだわり、制作で苦労した点などについてご紹介します。

www.wantedly.com

www.wantedly.com

TechLab.でノーコードツールを使うという選択

甲斐：
エンジニアリングチームであるTechLab.には複数名のエンジニアが所属しています。SREをはじめ、バックエンド・フロント、もちろんデザイナーも在籍しています。Webサイトを制作するスキルを十分に保持したチームですので、今回ノーコードツールを選択した理由は技術や実装面の問題ではありませんでした。多くの企業が同じ課題を抱えていると思いますがコーポレートサイトという特性上、多くの時間と予算を使って作成するというものでもありません。テックラボも日々ビジネスを加速するためのタスクに追われています。今回フォースタがコーポレートサイトのリニューアルの実行に舵を切れたのは、チームが常に新しい事にチャレンジしようとする文化があったからだと思います。結果として、ノーコードツールを使用した知見は今後の開発にも大きく役にたつものになりましたし、PRやブランディング、そしてHRの観点からもメリットが大きかったと思っています。

Webflowにした理由や背景

甲斐：
「ノーコード」という言葉を耳にする機会が増えた方も多いと思います。実際フォースタでもノーコードを使ったWebページを作成した事はありました。ノーコードツールの印象としては「お手軽にWebページが作れる」といった感じです。しかし既にフォースタのコーポレートサイトをご覧頂いた方はお分かり頂けたと思いますが、決してお手軽にスピード重視で作成されたサイトではありません。今回のコーポレートサイトはフォースタのブランドを大切に、コンセプトメイキングからはじまり、ペルソナ・ユーザーストーリーなどをしっかり設計、ブランドを生かしたグラフィックとアニメーションにも挑戦しました。プロジェクトは約半年をかけたものです。

私たちが重視しこだわったのは、更新のしやすさとフォースタのブランドの再現でした。更新のしやすさでいうと、CMSやノーコードツールが挙げられると思います。フォースタでもWordPressといったCMSを利用してはいましたが、テンプレート部分などはエンジニアへの修正依頼が必要であったりして、時期に寄ってはなかなか修正の工数が割けないといった状況も発生しました。実際にフォースタのコーポレートサイトは2019年4月にリニューアルして以降、追加で開発することはあまりできませんでした。上場時にIRページを追加した以外は細かい変更を行うのみでした。しかし、フォースタという会社も事業拡大しており、その拡大しているフォースタと共に進化していくコーポレートサイトを作るということが課題でした。そこを解決してくれそうだと考えたのがWebflowです。Webflowであれば、デザイナーとコンテンツエディターが直接Webサイトを更新できます。デザイナーが直接サイトを更新出来るというのは、先に挙げたフォースタのブランドをデザイナーが直接表現できるということでもありました。

デザイナーのみで作り上げるWebサイト

甲斐：
一般的なWeb開発の場合、デザイナーが作ったカンプを元にバックエンドエンジニアとフロントエンドエンジニアが実装するというイメージが多いかと思います。しかし今回私たちは、最初に練り上げたコンセプトやユーザーストーリーを元に、UXデザイナーが作ったワイヤーから直接WebflowでWebデザインを行うという工程に移りました。

今回のコーポレートサイトに携わったデザイナーはグラフィックデザイナー（長峰）とUXデザイナー（甲斐）の2名です。10数年に渡るグラフィックデザイン歴のある長峰にとって、Web制作は大きなチャレンジでもありました。これまで担当してきたパッケージなどのクリエイティブとWebデザインでは画面内での表現やレイアウトの考え方に違いがあったからです。それにプラスして動きといったモーションデザインもとてもチャレンジングな作業となりました。さらに今回は会社のミッションのアップデートも重なり、それにともなった新しいグラフィックもうみだされました。

これまでのフォースタのブランドを引き継ぎ、次なる進化を表現したトップ画面

 

サイトのキーグラフィックを「挑戦者の広がり」をテーマに制作し、トップ画像などに展開

 

各サービスのビジュアルを開発し、それぞれの特色を出しながら全体のトーンを合わせた。

 

トップページのサービスメニュー

 

デザイナーが直接デザインを行っていけるWebflowはとてもパワフルなツールです。HTML/CSSの基礎知識があるデザイナーであれば十分に使いこなせますし、フロントエンジニアであれば問題無く実装に利用出来ると思います。私自身Webサイトのコーディングをこれまでいくつも行ってきましたが、コーディングを行う頭の使い方でGUIを使って実装していけるのがとても便利だと感じました。これまでの方法ですと、コードを考えて、書いて、書き出して、確認する…といういくつかのステップが必要でしたが、ブラウザ上で直接GUIを使って操作できるので、そうしたステップが大いに短縮できました。必要なパーツは共通コンポーネントとして使えたりもするので、メニューやフッターなどに変更があった場合でも1回の更新ですべてに適用することができます。必要なのはブラウザだけなのです。

グラフィックデザイナーがWebデザインに挑戦

長峰：
私は前職のデザイン制作会社でグラフィックデザインに13年以上、アートディレクター・デザイナーとしてロゴデザイン・パッケージデザイン・広告・ポスター等の制作、商品撮影・モデル撮影等のディレクション・デザインに従事してきました。半年前よりプロジェクトメンバーとしてキックオフから参加し、グラフィックデザイン、WEBデザイン、実装と広く関わりました。Webflowを使って実装したのですが、過去に使用したことのあるノーコードツールのSTUDIOとは全然違いました。Webflowはコーディングと同じ仕組みで作られたアプリケーションで、クラスの設定やコードの埋め込みなど、最初ははっきり言って訳がわかりませんでした。しかし、公式の豊富なレクチャー動画や公開されているデザインデータを研究することで一つ一つ理解していきました。

コーポレートサイトのWEBデザインへの挑戦は非常にチャレンジングな仕事で幾多の壁がありましたが、心強い仲間と力を合わせることで乗り越え、リリースすることができました。

グラフィックデザイナーが苦労したポイント

長峰：
私が苦労したポイントが大きく3つあります。
1つ目は、グラフィックデザイナーならではの壁だと思いますが、WEBのデザイン・実装の経験が少ないため、何ができて何ができないか、できる場合どれぐらいの工数がかかるかがわからないことです。想像がつかないのでデザインも進めにくいという事態になりました。しかし、WebflowのいいところはGUIで実装しながらデザインできるところで、想像つかないところはまず実装してみることで感覚を掴みました。

2つ目はHTML 、CSS、CMSなど専門的な知識がないと理解しづらい部分があるということです。幸い、私はフォースタートアップスでTechLab.に所属していて優秀なエンジニア・デザイナーがいるので相談したり力を借りたりすることで乗り越えました。また公式が運営しているWebflow Universityというサイトがあり、豊富なレクチャー情報があります。英語なので最初はとっつきにくいかもしれませんが、Google翻訳などを駆使して読み解くことで解決できました。他にもWebflow Forumというサイトは様々な質問に対してみんなで答えるサイトがあり、大抵の困りごとはそこで見つけることができます。

３つ目はインタラクティブの部分です。アニメーション表現やユーザーのスクロールやカーソルに対しての表現はフォースタの進化を伝えるためにどうしてもチャレンジしたいものでした。しかし、本来そこはCSSやjsなどのコードによって実装するものでかなりハードルが高いものです。しかしWebflowであればインタラクティブに関しても多くの機能がありGUIでプレビューしながら進めることができ、表現したいイメージに近づくことができました。

WordPressからWebflowへ

甲斐：
コンポーネントやテンプレートといった考え方はWordPressでもなじみのあるものだと思います。世界で最も導入されているCMSであるWordPressは多くのコーポレートサイトでも使用されていると思います。しかし今回フォースタで利用したWebflowは今WordPressに置き換わろうとしています。多くの人がWordPress程できることの多いCMSは他にないだろうと考えていると思います。私もその1人でした。しかし今回私が半年をかけて担当したWeb開発で、WordPressに著しく劣っていると感じた部分はありません。むしろPHPやJavaScriptの知識が無くても実装できる点で優位と言えるのではないかとさえ思います。確かに細かい点でPHPが使えれば便利（実装が早そう）だなと思う点はありましたが、結果として実現したいことでWebflowの機能で実現出来なかったことはありませんでした。

今回の開発では使用していませんが、ECの機能も付いています。コーポレートサイトだけでなく用途は大きく広がると思います。さらに作業を自動化できるZapierなどの外部ツールとの連携も可能です。例えば、お問い合わせフォームからの投稿があった場合には社内のSlackにリアルタイムに通知を送ったり、自動でスプレッドシートにお問い合わせ内容を格納したりと言うことが可能です。コーポレートサイトを入り口として発生するお客様対応などを一部自動化することで、1人に集中しがちな作業の負担を減らし、分担もしやすくなりました。

インターフェースが英語なので不安に思っている方もいるかもしれませんが、これまでWeb制作を行ってきた方にはなじみのある用語ばかりですので問題無いと思います。

おわりに

今回のコーポレートサイトのリニューアルは、デザイナー自身がWebflowというノーコードツールを使って実装しただけではなく、会社のミッションのアップデートに伴った新たなグラフィックを生み出したり、ブランディングや設計を、PRや時には経営陣と共にしっかり練り上げてゴールまでたどり着いたプロジェクトです。作業を行うだけではなく、デザインやエンジニアリングの力をフルに生かしてアイディアを形にする職場に魅力を感じるデザイナー・エンジニアの皆様の参画をお待ちしております！

【フォースタ テックブログ】技術書典への初めての出版物を書籍にしていただきました！

テックラボグループが有志を募り、2020年12月に技術書典に応募。その後2021年5月にインプレス社経由で出版を果たした。今回の記事では出版に至った経緯とその裏側に迫る。

▽▽▽今回出版に至ったVol.1▽▽▽

https://www.amazon.co.jp/dp/B097D6B8QY

 

－この度は初の技術書典での出展および本の出版、おめでとうございます！
　そもそも技術書典に応募しようと思ったきっかけや走り出しはどんなものだったのですか？

井原：
軽い気持ちで「技術書典に出してみたいね」と提案したところ話が盛り上がり、自然と集まったメンバーで書くことになりました。10月から執筆作業に取り掛かり約2ヶ月間で仕上げていったのですが、話し合いで決めたのは「10ページを目安に書き上げること」程度で、テーマに関しては特に戦略を立てて決めることなく各々の興味関心が高い分野で好きに書き始めました。

井原

 

－技術書典への応募・本の出版にあたり大変だった点や苦労した点を教えてください。

藤井：
内容の質の高さを出すのに初めはプレッシャーを感じました。執筆自体初めてのことですし、個人ブログではなく会社として発信するものだったため、読者に何かしらの発見を与え、読んで良かったと思ってもらうにどうするべきかと随分苦悩しました。後々自身で振り返って「このテーマは他の人に負けないくらい考えた」と思えるくらい考え抜こうと自問自答を繰り返しながら書きました。

藤井

 

村林：
通常業務に加え、テックブログの執筆や勉強会、ウェビナーの登壇も控えていた中、応募時と出版時で記事のフォーマットが異なっていたことが発覚しそのディレクションや編集作業に思いの外手間取りました。具体的にはRe:VIEW StarterからRe:VIEWに変える作業だったのですが、フォーマット変更に伴い表示にズレが生じてしまってないかを一つ一つ確認する必要があったのです。結果かなり出版ギリギリの提出にはなりましたが、なんとか間に合いホッとしたのを覚えています。

－今回記事を書いたことで良かった点や学んだことなど簡単な感想を教えてください。

村林：
自身のやっていることの言語化に繋がった気がします。全体像を気にせずバラバラ書いていったからか普段自分が感じている点や思っていること等が文章として顕著に落とし込まれていく感覚はありました。

村林

 

戸村：
フォースタでの自身の歴史を棚卸ししていくような内容だったので、これまでの振り返りができました。ヒューマンキャピタリストとして人材紹介事業に携わっていた頃から、エンジニアとしてテックラボに参画し現在のCTOを任されるまでの軌跡とともに「組織」について触れられたのは自身にとってもとてもいい経験だったと思います。

藤井：
メンバーの新たな“強み”を知れました。例えば村林さんは大学時代新聞部だったこともあり、キャッチーなタイトルをつけるのが上手でした。本文を書き出したはいいものの、読みたいと思わせられるタイトルをつけるのは文字数が少ない分想像以上に難しかったので、それをサラッと出していた村林さんはシンプルに凄いなと。

「何よりも実際に書籍として手元に届いた時は本当に嬉しかった」と話す皆さん

 

－技術書典に出した後の反響等はありましたか？

戸村：
知人からの買いました連絡を何件かいただきました。当時、Twitterで技術書典の購入ツイートを購買者がつぶやく度Slackに流れるよう連携しており、その通知が届く度に皆で盛り上がっていました。中にはその後に個人的に挙げた振り返り記事を見て購入したとツイートしてくれた人も。
執筆当初に想像していたよりも多くの方に閲覧いただけたようです。

－書籍の話が来てから本が出るまではどんな流れだったのですか？

戸村：
技術書典を出してからすぐにインプレス社からDMが届きました。あまりに掲載直後のDMだったので思わず一瞬半信半疑になってしまった程です（笑）

ですがせっかくいただいた話ですし、Amazonや書店で並んだ方がより成果を形に残せると思い、出版することにしました。契約締結後はSlackでのやりとりに移行し、村林さんに出版準備全般のディレクションをお任せしました。

村林：
インプレス社から出版話を持ちかけられた2020年12月がちょうどサービスのリリースのタイミングだったため、準備期間は多少長めにいただきました。フォーマットの修正やAmazonでの書籍紹介文の作成、表紙をご担当いただく絵師決め、ラフ画すり合わせ等で都度やりとりしながら、無事2021年5月25日に出版することができました。

また、2021年7月に今回新たなメンバーで書き上げたVol.2を技術書典11に出しました。Vol.1とはまた違ったテーマを取り上げた渾身の一冊となっております！（急な宣伝）

techbookfest.org

－最後に、今回の総括をお願いします。

戸村：
フォースタートアップスのバリューの一つである “Be a Talent”は、「自らの生き様を社会に発信せよ」というメッセージが込められており、なかなかエンジニアとして体現が難しい中、テックブログや勉強会等で積み重ねてきたものを公に出せたのは良かったです。引き続き、技術書典も含め、よりいろんな挑戦を発信していけるチームにしていきたいと思っております。

CTO 戸村

Slackを最高に使いこなすためにフォースタがやっていること

f:id:forStartups:20210817154912j:plain

どうも、フォースタートアップスでエンジニアをやっています村林です。

皆さん「Slack」使っていますか？Slack最高ですよね。
弊社もSlackバリバリ使っていて、Slack無いと仕事できないくらいには依存しているのですが、組織が拡大する中で様々な問題が出てきました。

チャンネルが多すぎてよくわからない

弊社は誰でもチャンネルを作成できます。そのためどんどんチャンネルが作成されていき、その結果大量のチャンネルが存在しています。それだけなら良いのですが「チャンネル名のルールがない」「チャンネルの説明がない」などの理由から目的のチャンネルが探しづらい状況になってしまっていました。

これはいかんということでSlackの活用ガイドラインを一部の有志で考えました。

Slack活用ガイドライン、チャンネル命名のルール

原則: 部署名_チーム名_目的で作る
特に接頭句に関しては以下のものから使ってもらっています。

  • 部署内に閉じる場合

ac_ ：アクセラレーション本部
cp_ ：コーポレート本部
hr_ ：人事
oi_ ：オープンイノベーション
ta_ ：タレントエージェンシー本部
tl_ ：テックラボ

  • 部署をまたがる場合

all_ ：全員いるチャンネル
pjt_ ：部署がまたがる(2ヶ月以上）
tmp_ ：一時的な集団（２ヶ月未満)

  • その他の用途

guest_ ：他社の方との連携チャンネル
info_ ：情報共有系
notify_ ：システムからの通知
club_ ：趣味系

以上がチャンネル名のルールです。

具体的な例としては

pjt_startupbdb
弊社が展開しているSTARTUP DBに関して話し合うチャンネル

all_branding_pr
社外向けの情報周知がされるチャンネル

club_ラーメン
ラーメンの画像を貼るチャンネル。「今日のラーメン」と書けばラーメンじゃない画像を載せても許される風潮がある。

そこまで堅苦しいものにすると、実運用されないなと考えたことから接頭句のみ縛りを加え、それ以外は比較的に自由に設定できるようになっています。このルールが作られてから半年くらいですが、最初は守られていないケースも多々ありましたが、最近は殆どこのルールに従って作成されています。

ちょっとした命名規則ですが、あるとないとでは検索性、視認性が段違いなのでSlackのチャンネル多すぎてお困りでしたら皆さんもぜひやってみてはいかがでしょうか。

DMが多い

これもあるあるですよね。
「みんなの注意を向けられるほどの内容でもない」「変なことを聞いて恥をかきたくない（恥をかく対象範囲を最小限にしたい）」などの色んな理由から人はpublicなチャンネルではなく、DMを使います。
気持ちはわかりますが、DMは完全に秘匿された状態なので、そこで交わされた内容は誰の目にも触れることがありません。知識が社員の間で偏在し、横展開されることもなくなります。

Slackの素晴らしいところのひとつに検索性の高さがあると思っています。
Slackは検索能力が素晴らしいので「なんでこうなってるんだろ？」「これ今どうなってるのだろう」ってなったときに検索すれば大体経緯が出てきます。これは対面、電話、Zoomのいずれのコミュニケーション手段も達成していない価値なので是非活用しましょう。

でもたまにDMで感謝を伝えたり、伝えられたりは好きだったりします。なんかいいですよね（個人の見解）

ということで、この状況を打破するために以下の指針を出しました。

DMはやめて個人チャンネルでやり取りする

個人チャンネルは「分報」「times」などとも呼ばれていますが、特定個人のためのチャンネルです。個人チャンネルはpublicで作られているため、誰がどこのチャンネルに入ろうが勝手ですし、検索にも出てきます。また個人チャンネルという特性上、その人に関する話題なら何を振っても良い（良さそう）なため、publicなチャンネルでありつつも投稿をする心理的ハードルを下げるという効果を狙っています。

 

ということで、slackの困りごととそれに対応した話でした。
Slackのガイドライン策定などは色んな人の思いを汲んでやらなければいけないため、正直とても面倒くさいし、別に誰からも喜ばれない行為ではあります。
ただ、ちょっとした指針があるだけでみんなハッピーになりますし、Slackをみんなが使いこなす様を見ていると嬉しいので引き続き改善していければ良いですね。

We are hiring !

フォースタートアップスはエンジニア・デザイナーを積極採用中です😃

もしこの記事を読んでフォースタートアップスに少しでもご興味をお持ち頂けましたら、下記の「話を聞きに行きたい」ボタンより気軽にエントリーしてください。

事業やチームについての説明から技術スタックの解説まで、CTOやチームメンバーからさせていただきます。

【フォースタ テックブログ】RepositoryFactoryパターンをVueのAPIリクエストに導入する

こんにちは。エンジニアの藤井（@yutafujii）です。
社内向けのプロダクト「タレントエージェンシー支援システム（SFA/CRM）」のエンジニアをしています。

プロダクトはフロントエンドをNuxt/TypeScript・サーバーサイドをRailsで実装しているのですが、今回はフロントエンドのAPIリクエスト処理にRepositoryFactoryパターンを導入した話をさせていただきます。

RepositoryFactoryパターンとは

RepositoryFactoryとはAPIを呼び出す設計のデザインパターンとして、JorgeというVueエヴァンジェリストによって2018年に紹介されました。

（原文）Vue API calls in a smart way
https://medium.com/canariasjs/vue-api-calls-in-a-smart-way-8d521812c322

（日本語訳）【Vue.js】Web API通信のデザインパターン (個人的ベストプラクティス)
https://qiita.com/07JP27/items/0923cbe3b6435c19d761

Jorge氏のブログでは以下のような問いかけがされます。

How many times have you seen examples with an instance of axios in each component?
（各コンポーネントにaxiosインスタンスが書かれてるような実装をどれくらい見たことがありますか？）

そしてそのように実装されているコードに対してJorge氏は問題提起しています。

What happens if the endpoint changes?
（エンドポイント変更したらどうする？）
How I can handle mocks or different endpoints to test it?
（動作確認のためにエンドポイントをモックしたくなったらどうする？）
What happens if you need to reuse a call?
（再利用したくなったらどうする？）
What happens if you need to refactor some call or move it to a Vuex actions?
（Vuexに処理を移植するとかリファクタするとなったら？）

後述しますが、最後の”リファクタリングしたくなった”のがまさに私たちの陥った状況でした。
この問題に対処するために考えられたのがRepositoryFactoryパターンのようです。

これは名前の通りRepositoryパターンとFactoryパターンを組み合わせた設計ということになります。Repositoryパターンはドメイン駆動設計（Domain-Driven Design, DDD）で提唱された考え方、Factoryパターンはオブジェクト指向言語のCreational Design Patternsの一つです。

Repositoryパターンは、ドメインモデルのまとまり（Aggregateと呼ばれます）ごとにデータアクセスを1箇所に集約するRepositoryを作成し、データレイヤのロジックとドメインを疎結合にするというもの、Factoryパターンとはインスタンスの生成ロジックを一元管理するFactoryを作成し、インスタンスを必要とするクライアントから生成ロジックを分離するものです。

雑な言い方をすれば、両者を組み合わせることで以下のようなメリットを享受できるということになります。

  • コードのメンテナンス性が向上（DRYに記述できる）
  • 拡張性が向上（横展開するときに短時間で実装ができる）

導入背景

さて、弊社では2019年ころからモノリシックなRailsアプリケーションをフロントエンドとバックエンドに分離してきています。フロントエンドはVue/Nuxt/TypeScriptを採用していますが、詳細は下記ブログに記載しています。

tech.forstartups.com


ゼロから作ってきたばかりということもあり、APIへのリクエストは各コンポーネント中からaxiosを利用していました。

しかし、実装量が増大するにつれてAPIへのリクエストで共通の修正を行う場合に該当箇所や対象ファイルも増大し、メンテナンスが難しくなりました。そして、あるタイミングで実際にaxiosの処理をrescueしたいという話になりました。

「axiosを書いた各コンポーネント全部の箇所に修正を入れていく方法は避けた方がよいので別の方法を考えましょう」と一緒に働くメンバーの方が色々調査してくれて、RepositoryFactoryパターンを採用することにしました。

実装する

まずRepositoryパターンを導入していきます。

ドメインごとにデータへアクセスする処理をそれぞれ1枚のRepositoryに集約し、axiosによるAPIリクエストはこのファイルから（このRepositoryを通して）のみ行われるようにします。

次にFactoryパターンを導入します。

今回のFactoryパターンにおける具体的な生成物はRepositoryです。
Factoryを記述するファイルを作成し、どのRepositoryを生成するかを（呼び出し元のクライアントではなく）Factoryが決定できるようにします。

最後にaxiosを直利用していたコンポーネントを修正します。

データに対するCRUDアクションを行うときは必ずRepositoryを通すのがRepositoryパターンです。従ってaxiosを直で利用せずにRepositoryを指定するということになりますが、直接Repositoryインスタンスを生成せずにFactoryに”生成依頼”するのがFactoryパターンなので、最終的にはコンポーネントはFactoryに対してRepositoryインスタンス生成の依頼を行うよう修正します。これが下の図の .$repository(‘user’) です。

これによって得られたRepositoryは共通のInterfaceが備わっているので、あとは取得したRepositoryへのメソッド呼び出しを行うよう書き換えます。

 

なお、実際にはFactoryを呼び出すにあたって事前にpluginでFactoryをNuxtAppにインジェクトしておきます（repositoryという名称をつけました）。こうすることで context.root.$repository でFactoryを呼ぶことができます。

import { Inject, NuxtApp } from '@nuxt/types/app'
import {
 ApiRepositoryFactory,
 RepositoriesType,
} from '@/factories/api-repository-factory'
 
export default ({ app }: { app: NuxtApp }, inject: Inject) => {
 const repositories = (name: string) => {
   return ApiRepositoryFactory.get(name)(app.$axios)
 }
 inject('repositories', repositories)
}
 
declare module 'vue/types/vue' {
 interface Vue {
   $repositories: RepositoriesType
 }
}

また、コンポーネントにおけるRepositoryを通したCRUDアクションはcomposition APIを利用してcompositionとして切り出し、コンポーネントでは当該compositionをimportして使っています。

pages/index.vue

import useUsers from '~/composables/useUsers'
 
export default defineComponent({
 components: { },
 setup(_, context: SetupContext) {
   const {
     get,
     post,
     // ...
   } = useUsers(context)

composables/useUsers.ts

import { computed, reactive, toRefs } from '@vue/composition-api'
 
export default (context: any) => {
 const state = reactive<{
   user: UserType
   loading: boolean
 }>({
   user: {},
   loading: true,
 })
 
 const get = async (userHash: string) => {
   const response = await context.root
     .$repositories('user')
     .get()
   // ...
 },
 
 return {
   ...toRefs(state),
   get,
   post,
   // ...
 }
}

実装の概要は以上ですが、RepositoryFactoryパターンをAPIリクエストに導入した全体像を記載しておきます。

実装してみて

実装を終えて数ヶ月が経ちますが、当初の目的であったAPIクライアントに関するエラーハンドリングを1箇所に集約して管理することができるようになり（そしてそれは再利用が可能）、設計を一度理解すればコード管理が行いやすくなりました。

フロントエンドにとってはBackend For Frontend（BFF）サーバー以降のAPIサーバー・各種データソースをデータレイヤと見做すことができますが、その意味でドメインモデルとデータレイヤの中間にドメインごとに（正確にはAggregateごとに）1種のRepositoryレイヤを設けたことのメンテナンス性の高さをチーム一同実感しています。

副次的な効果として、以前の実装では設計から落ちておりスクリプトエラーとして拾っていたAPIのエラーを全てリクエスト段階で捉えて監視ツールにロギングできたことで、バグ発見までの時間を短縮できたことがありました。

Factoryパターンに厳密に従っているわけではないものの、それでもDRYに書けた部分が多く、今後もこのパターンに沿ってAPIクライアント側の機能開発は拡張していきたいと思います。

参考文献

以下のブログは実装の際に参考にさせていただきました

Vue API calls in a smart way
https://medium.com/canariasjs/vue-api-calls-in-a-smart-way-8d521812c322

【Vue.js】Web API通信のデザインパターン (個人的ベストプラクティス)
https://qiita.com/07JP27/items/0923cbe3b6435c19d761

Repositoryパターン
https://medium.com/canariasjs/vue-api-calls-in-a-smart-way-8d521812c322

Factoryパターン
https://www.oodesign.com/factory-pattern.html