BFF

2021年6月13日

最近のWeb界隈のトレンドで個人的に興味があるもの

定期的に技術動向予測とか、その時に興味があることの整理をしてみる

この手の話題は年始あたりに「今年のトレンド」とか書くのがいいと思いますが、タイミングを外したので6月に書くことにしました。
今後、1年毎か半年毎に整理も含めて書いてもいいかもしれません。

あと、この手の記事を書く人がどちらかというと自社開発系・エンジニア指向の強い方が書く傾向が高いと思います。
ですので、ここでは受託開発会社として、そしてメンバーがデザイナー寄りのケースの場合にどう考えるかも含めたいと思います。

今回はフロントエンドとバックエンドについて書きたいと思います。
長くなるのでサーバーやインフラ周りについては別の機会に書きたいと思います。

フロントエンドとバックエンドのあり方が変わってきている。

モダンな開発環境のキャッチアップに敏感な自社開発系の方からすると、今さら何をという感じでしょうが、弊社でも最近フロントエンドとバックエンドを分けて構築する、または分けたほうがより適切なケースが増えてきました。

これは技術的な背景と年代的な要素が強いと考えております。
10年前とかであれば、フルスタックWebフレームワーク(現在であればLaravelやRuby on Railsなど)でモノシリックな作りで構築するのが最も効率的でした。

当時に構築したWebサービスが、その後10年以上も稼働することを想定しているケースは少ないですし、10年後の技術トレンドを考慮できているケースはより稀かと思います。

そのWebサービスが10年以上稼働続けて、サービスのユーザーが増加して機能を追加改修を繰り返していくと、やがて諸々の弊害が出てきます。

新規構築当初に選定した技術が、やがて技術的な負債となり、最新技術に適用させようにも、一から作り直したほうが楽なぐらい、移行するのに大変な工数が必要となります。

ここで言いたいのは、スタートアップ期に最速で立ち上げる場合と、5年10年以上続いているWebサービスとでは、どの技術を選択するかの判断基準が違うので、どちらが正しい/間違っているということではないという点です。
そして、10年前は特にフロントエンドの状況が、今と全く違うという点です。

現在ならではの技術選択の判断基準

10年前と違う点は、フロントエンドの技術や環境が大きく違います。
今直面している技術選択の判断基準について、その理由の大元を辿ると主に2つに集約されるかと思っています。

  • Webとスマホ(iOS, Android)のクロスプラットフォーム対応
  • セキュリティ上の観点から、フロントエンド側とバックエンド側のサーバー分割

とくに弊社というか私の場合ですが、2番目の「セキュリティ上の観点から、フロントエンド側とバックエンド側のサーバー分割」が現実の案件として直面している課題となっています。

Backends For Frontends(BFF)という考え方

バックエンドとフロントエンドの明確な役割分担が求められているという課題がここ最近多くなっております。

何が違うの?ということですが、わかりやすい事例で言うと、Wordpressで管理画面とフロント側が同一サーバーで、テーマファイルでViewを生成するのがモノシリックな作りです。
これはWordpressだけでなく、EC-CUBEなどでも同様ですし、LaravelやRuby on RailsなどでViewにテンプレートエンジンを使って構築するのも本質的には同様です。

  • フロントエンドとバックエンドの役割を明確にする。
  • バックエンド側はAPIを通じてDBとのアクセスを担う。
  • フロントエンド側はAPIを通じてリクエスト、レスポンスを受けて画面生成する。
  • ビジネスロジックは今までバックエンド側が持つケースが多かったと思いますが、フロント側が受け持つ。

フルスタックWebフレームワークでは、いち早くこの傾向を感じ取り、Vue.jsやReactとの連携モード、APIモード等を実装しています。

バックエンド側は、APIサーバーとしての役割に徹し、テンプレートエンジンなどを使用してViewを作成せずJSONなどを返すことに徹底し、Viewの作成はフロント側に任せるということです。

これを可能にしたのが、WebではPCスペックの向上、そしてReactやVue.jsといったフロントエンド技術、スマホ側も端末スペックの向上、Flutterなどクロスプラットフォーム技術があります。

Backends For Frontendsとは、その名の通り、「フロントエンドのためのバックエンド」です。
バックエンド側は裏方、つまりDB、サーバー、インフラとの連携に注力して、見た目=View側は極力フロントエンド側で構築するという考え方です。

バックエンド側の技術遷移と影響

最近マイクロサービス化が言われて久しいですが、これも先ほどの時代の流れが大きく影響しています。
10年稼働すると様々な綻びが生じて、Webサービスの特定の一部分だけを改修・スケールアップしたいケースが出てきます。
そうすると、大きなフルスタックWebフレームワークでモノシリックな作りをしていると、その部分だけ切り出して改修することが難しくなります。
中には10年のうちに、選定したフレームワークの開発が停滞したり、あるいは破壊的変更を伴うアップデートにより、新バージョンへの適用ができず、一から作り直したほうが早いというケースが出てきます。

10年前は正しかった技術選定は、サービスが10年続いた後の今では適切とは言えなくなります。
これを技術的な負債と言います。
今、Webサービスを新規構築するとして、それが運用期間が決まっていない案件の場合、もしかしたら10年以上稼働するかも?という想定で技術選択する必要があります。

工数や受注金額にもよりますので一概には言えませんが、今新規構築するのであれば・・・

  • フロントエンドとバックエンドの役割分担を明確にする。
  • クロスプラットフォーム対応や、フロントエンドとバックエンドのサーバー分割できるように設計・構築する。
  • 一部だけをスケールアップ、改修しやすいように、マイクロサービス化も視野に入れる。

こんなところでしょうか。

そうなるとバックエンド側のフレームワークの選定基準や構築方法も変わってきます。
フルスタックWebフレームワークならAPIモード的な構築方法、あるいはそもそもフルスタックではなくマイクロフレームワークの使用も視野に入れたほうがいいかもしれません。

バックエンド側を一から構築する機会も減る傾向

上記書いた流れから、バックエンド側をフルスクラッチで一から構築する機会も減る傾向にあるかと思います。
APIサーバーとして、マイクロサービス化してのバックエンドであれば・・・

  • Headless CMS(Strapi, Micro CMSやShopifyなど)で構築する。
  • AWS AmplifyやFirebaseなどのモバイル向けバックエンド構築サービス。
  • AWS LambdaやCloud Functionsといったサーバレス技術。

また別の機会に掘り下げたいと思いますが、

  • DBからデータを取得してJSONを返せればいい。
  • ビジネスロジックをフロント側に持たせる。

この2つの観点では、必然的にバックエンド側をフルスクラッチで一から構築する必要性が薄くなります。
そして、GoやNode.jsなどのマイクロフレームワークや、あるいはフレームワークそのものを使用せず、APIサーバーだけを実装という手法も増えてくるかと思います。

フロント側の技術遷移と影響

フロント側はバックエンド側より一層、技術革新の速度が速く、それゆえ1年前の情報が実勢に即していないというケースも珍しくありません。
どちらかと言えば、バックエンド側は選択肢が増えたことによるメリットが多いのに対して、フロント側の方は選択肢が増えたが、選択を間違えると、1年後とか近い将来に後悔するということも少なくありません。

ここでの選択基準ですが、現在の弊社で事業環境に当てはめて下記の条件で考えていきたいと思います。

  • 受託開発がメインのため、技術選択権限が自社開発サービスほど自由ではない。
  • アサインするメンバーがデザイナー・マークアップエンジニアが多く、フロントエンドエンジニアと分業になるケースが多い。

マークアップエンジニアとフロントエンドエンジニアの違いですが、
企業や人によっては兼業されており、明確に区分されてない場合があると思いますが、
ここでは下記のように定義します

  • マークアップエンジニア・・・デザインをHTMLとCSSに落とし込む事がメイン。CSS設計などを担当
  • フロントエンドエンジニア・・・JavaScript等でインタラクティブな部分と、バックエンドとの連携を担当
  • バックエンドエンジニア・・・PHPやRubyなどサーバーサイド言語を用いて、サーバー構築からDB設計までを担当

フロントエンドエンジニアの部分を、デザイナー(マークアップエンジニア側)が担当するのか、バックエンドエンジニア側が担当するのかは、案件ごとケースによります。
少なくとも将来はともかく現在の弊社では、フロントエンドエンジニア専業という役割は存在せず、マークアップかバックエンドとの兼業になります。

先ほどのフロントエンドとバックエンドの役割分担の話で続けると、
今後のフロントエンド担当は、必然的にAPI連携したものをフロントに落とし込める技術が必要ということになります。
分業体制的にこれをマークアップ担当かまたはバックエンド担当が実装できる必要が出てきます。

React?Vue.js?技術的選択について

Webに限って言えば、最近はReact(Next.js、Gatsby.js)、Vue.js(Nuxt.js)などが主流かと思います。

第3候補としてよく名前の挙がるAngularは個人的な考えで外させてもらいました。
理由は半年ごとのメジャーアップデートがロードマップに敷かれており、1年前のソースが破壊的変更でサポート対象外となるなど、技術選択した場合の負荷が極めて高いと判断したからです。
Angularは半年ごとのメジャーアップデートに耐えうる技術メンバーをアサインできる環境ならではの選択肢と考えました。

それ以外の選択肢は?

例えば、Svelte.jsAlpine.jsなど、Vue.jsの影響を受けつつ、より簡易に構築できるライブラリやフレームワークはどうでしょうか?
わざわざSvelte.jsやAlpine.jsの2つを挙げたのは、「The State of JavaScript 2020」の「Front-end Frameworks」で注目度が急上昇しているからです。
注目度が急上昇しているとは言え、将来はともかく「現時点での受託案件」では、積極的に選択するのは非常にリスクが高いと考えています。

何々より簡易・高速・効率的・・・という謳い文句のライブラリやフレームワークは、フロントエンド・バックエンド問わず山のように誕生しては消えていきました。
大抵それらの技術は、1〜2年ぐらいは注目されるのですが、結局メジャーなライブラリやフレームワークに取って変わることなくオワコン化して消えていきます。
理由は、簡易・高速・効率的「だけ」では乗り換えのメリットが薄いからです。
ReactやVue.jsがメジャーになったのは従来の手法からパラダイムシフトがあったからです。

余談ですが「本当に使われているフロントエンドの技術」を測る場合は、Google TrendsやGitHubのスター数よりも「npm trends」の方が適切だと思います。(一過性の話題による急上昇をある程度フィルターかけることができるからです)

受託開発の場合、そのリスクを積極的に取るメリットは少なく、メジャーな技術の採用一択です。
技術者のアサイン、詰まった時の情報量など、「1年後消えるかもしれないし流行るかもしれないし正直わからない技術」を選択する理由は少ないためです。
どうしても使いたい場合は、自社サービスとか個人開発で使用して、いざメジャーな技術になったときに備える・・・という感じでしょうか。

React系かVue.js系、どちらを選ぶべきかのか?

React(Next.js、Gatsby.js)、Vue.js(Nuxt.js)どちらを選ぶべきかという問い、あるいはこちらを選ぶべきというポジショントークは、ブログやYouTubeなどで検索すると多々出てきます。

私の回答は「アサインするメンバー次第」です。

弊社のようにアサインするメンバーがデザイナー寄りのケースの場合、
親和性の面でVue.js系の方が馴染みやすいと思います。
ソース上のtemplateタグや、CSS・Scriptの分割が、マークアップエンジニアにとって馴染みやすい、分業しやすいのが理由です。
逆にフロントエンドエンジニアが多い環境なら、React系の方が馴染みやすいかと思います。

どちらとも言えないなら、間違いなく今現在(2021年6月13日)で、新規構築という条件ならReact系で決まりです。
理由としてはここ1〜2年ぐらいの

  • Reactの大幅改善(主にReact Hooksによる)
  • Next.jsの大幅機能強化(SSG対応、VercelへのホスティングによるISR対応)
  • Vue.js 3.xへの移行の停滞(Nuxt.jsのVue v3対応やVue2.7の進捗)

日本では割とVue.jsの方が優勢だったと思いますが、この1〜2年で逆転した印象です。
Vue.jsを推奨する記事は、おそらく2019年以前おそくとも2020年前半までに書かれた記事が多い気がします。
それ以降に書かれたブログ記事やYouTubeはReact推しの方が多いのでは・・・?と思います。

理由として推測されるのは、上記に挙げたReact系が周りのエコシステム(Next.js含む)込みで大きく改善・強化されたのに対して、Vue.jsが、Vue.jsそのものがv3の登場で大幅強化されたが、移行前提のVue.js v2.7が未だ目処が立っておらず、Nuxt.jsも同様にVue v3対応が進んでいません。

移行状況を確認するには、GitHubのプルリクエストやプロジェクトの進捗バーを見るとわかりやすいです。

おそらくVue.jsは、2.x系と3.x系が、かなり長期間にわたって並走すると見ています。
主にNuxt.jsのVue v3対応版と移行用Vue2.7の2つが正式公開されるまでは、Vue.js系の新規採用は熟考したほうがいいかもしれません。
ただし繰り返しますが、アサインするメンバー次第です。
マークアップエンジニアとの分業が多いなら、Vue.jsの方が楽かと思います。(まさに弊社がそれに該当します)

React系かVue.js系どちらか選ばなくては行けないのか?

そうは言っても、ReactやVue.jsは学習コストが高く、とくに現在のVue.jsは2.x系と3.x系の情報が混在していて、1年前の記事が参考になりません。
ReactもReact Hooksが登場する前の記事は参考にならないというか適切とは言えない(現在は非推奨)ケースが多く、適切な情報に辿り着くのも一苦労です。

だからと言って、より情報の少ないSvelte.jsやAlpine.jsなどを採用した日には、
最悪「詰む」可能性も非常に高いです。
特にSvelte.jsはフレームワーク(Vue.jsにおけるNuxt.jsのようなもの)がSapperの開発中断からSvelteKitへ移行中(それも開発途中)なので少なくともSvelteKitの正式版とその普及度合いを見てからでいいと思います。

そんな時は、JavaScriptの基本から徹底するためにも、
いっそVanilla JavaScript(そういうフレームワークがあるわけではありません。素のJavaScriptのことです)で作るというのも手です。

APIでJSONを受け取って、それをHTMLに展開するだけであれば、何かのライブラリやフレームワークは不要です。

Fetch APIなどのJavaScriptの基本構文で実装は可能です。
ちょっと凝ったこともWebComponentsを使えば可能です。
むしろJavaScriptの習熟を考えるのあれば、いったん素のJavaScriptでやってみるのもいいかと思います。
勿論ES5ではなく、ECMAScript2015(ES6)以降の話です。(現在はES2020(ES11)まであるとか正直ついていけませんが)

個人的にも、もう一度原点かつモダンなES6 – ES11をしっかりやり直そうかなと思っています。

締めくくり

ここまで書いた流れから、今後半年から1年程度のスパンで追っていきたい技術トレンドは下記になります。

バックエンド側

  • APIサーバーに徹するマイクロサービスとしてのバックエンド構築手法(Laravelで構築する場合もあくまでAPIサーバーとして構築)が主流となる。
  • Headless CMSでバックエンドを構築する機会が間違いなく増加する(WordpressではなくStrapiやMicro CMS、EC-CUBEでなくShopifyなど)。
  • PHPやRubyではなく、よりAPIサーバーの分散・並行処理が得意なGoかNode.jsでの構築事例が増える(というかチャンスがあれば挑戦したいという希望的な意味です。)

フロントエンド側

  • React系かVue.js系いずれかの技術は必須になる。(それ以外の技術選択は、近い将来に技術的負債にならないか要熟考)
  • アサインするメンバー次第になりますが、React系かVue.js系のどちらかで会社としての開発フローの確立が必要。

サーバー・インフラ側

  • ここでは書ききれなかったのでまた別の機会に。

半年後か1年後かいずれかの機会に、興味の対象がどのように変わったのか、業界の動きがどのように変わったのか、どこまで個人として会社として取り組めたのかを「答え合わせ」をしたいと思います。

LINEで送る
Pocket

label

Written by
isaka

バックエンドエンジニア

CONTACT

お問い合わせ、ご依頼などは下記電話番号かメールアドレスまでご連絡ください。
※内容により回答までお時間をいただく場合がございます、予めご了承ください。

tel. 06-6534-9333

10:00-19:00(※土日祝を除く)