年の瀬なので、私自身が今年利用した技術をベースに技術スタックをまとめてみようと思います。

とはいえ Web Standard といった広い対象から、フレームワークやライブラリまで、粒度の違うものを全て言及するのは無理があるというもの。特に強く言及できるものは個別で説明しつつ、最後に利用する機会がなかったものも最後に記載する形で。

以下常体。

追記: マイナー企業のようなので一応書いておきますが、筆者は本業ではLINE株式会社という組織でいわゆるエンジニアリングマネージャーと言われるような業務とその採用に関わる仕事をしています。

利用した技術一覧

HTML/CSS/JS みたいなことを書いてるとキリがないので、独断と偏見で区分けして適宜漉いています。特に利用する機会が多かったものは太字でピックアップ。

• Frontend
  • Language/Platform
    • TypeScript
      • JavaScript/Flowtype はほぼゼロ
      • NPM パッケージ開発も基本的には TypeScript
    • Node.js
      • ブラウザというよりは Node.js を意識する
      • OSSも自作する/最優先で意識する
  • JavaScript Framework
    • Nuxt.js (後ほど詳細を解説)
      • 2017年から言っているがこれより優れたフロントエンド技術は存在しない気がする
      • SSR/SSG/SPA で利用し、通常の Vue.js はほぼ利用しなかった
    • Next.js (後ほど詳細を解説)
    • React.js
      • Parcel との組み合わせで書き捨てのコーディング時のみ利用
  • UI Library
    • Lit Element
      • 所用で少しだけ利用
  • Styling
    • Tailwind CSS (後ほど詳細を解説)
    • Bootstrap
    • CSS
  • API Layer
    • axios
    • Firebase (後ほど詳細を解説)
  • Build Environment
    • webpack
    • Parcel
  • Developer Experience
    • Code Formatter
      • Prettier
      • ESLint
    • Package Maintenance
      • Renovate
    • Scripts
      • NPM Scripts
      • Make
  • Testing
    • Jest
  • SEO
    • Magic ではないもの
    • いわゆるリッチリザルトや Schema.org (JSON-LD)
    • Search Engine ではないが、 OGP のために SSR することもある
    • 流入を強く意識している
  • Note
    • SCSS, Angular, 素の Vue.js などが利用技術から消えた
    • API Layer で GraphQL は利用していない
• BaaS
  • Firebase (後ほど詳細を解説)
    • バックエンドとしてもクラウドネイティブとしても今年一番良く使った
    • Firestore/Auth/Storage/Hosting/Functions/Analyticsを利用
  • Note
    • Amplify を Console しか使っていなかったので変化なし
• Backend
  • Node.js(Express/NestJS)
  • 各種 FaaS の HTTP 通信
  • メモ
    • 今年は Ruby も PHP も書いていない
• Middleware/Infrastructure
  • データベース
    • MySQL/Google Cloud SQL
      • 職場が MySQL Native であるため
    • Cloud Firestore
      • Firebase で利用し、Google Datastore は利用してない
  • Web サーバー
    • NGINX
      • 職場がオンプレであるため
  • アプリケーションサーバー
    • Google AppEngine
    • Google Cloud Run
  • 静的サイトホスティング
    • Firebase Hosting
    • AWS Amplify Console
    • Netlify
  • Authentication
    • IDaaS
      • Firebase Authentication
    • Provider
      • Twitter
      • Google
      • LINE
  • 全文検索
    • Alogolia
  • CDN
    • AWS CloudFront
    • Google Cloud CDN
  • Note
    • オンプレ or GCP という仕事環境で、AWSはCDNとホスティングでしか使わなくなった
    • Node.js アプリケーションなら AppEngine の ap リージョンで良いので、 Heroku も死滅した
    • バックエンドの基本的なミドルウェアを触ることが少なかった
      • Redis/ElasticSearch あたり
      • ガッツリバックエンドを書くことがなかったことに由来
• その他
  • UI Design
    • Sketch/Zeplin
  • Note
    • Photoshop / Illustrator / Xd / Figma は登場せず
• 概念的なもの
  • JSX
    • React/Vue を問わず HTML の記述は JSX で行った
  • Universal JavaScript
    • SPA において、ほぼ全ての業務/趣味において Universal なコードを記述した
    • 基本的には SSR/SSG の開発を行い、通常の SPA はほとんど開発しなかった
    • そのため、 Node.js が primary の考えであり、Client 限定で動作する Standard については、優先度が secondary 以降になっている
  • Opinionated
    • 2018 年 3 月の Vue.js meetup のときから変わらず、 CoC な技術を使っている
    • これによりより本質的な領域の設計や価値向上を優先している

ざっとこんなところ。2019年と大きく変わらず Nuxt.js/Firebase/Tailwind が技術としてかなり強く、特に Nuxt.js については @nuxt/content で更に幅が広がったり、 Full Static もしっかりこなせたり幅が広いし、アーキテクチャ的にも通常の Vue.js アプリケーションより優れており、大きな理由がなければ積極的に利用したい。あとは、適宜利用という形。

技術として抜ける代表は Firestore。開発の生産性は高いが ap リージョンでも依然としてパフォーマンスに難があるので、場合に応じて AppEngine(or CloudRun) + Cloud SQL で組むと良い。

その際も、 Firebase の Authencitaion だけを IDaaS として利用すると良い。Email 認証に Google Authenticator 対応の 2FA がつかないのがネックなので、外部 Provider の認証によって間接的に 2FA の恩恵を得るか、あるいは Email + 2FA が必須なら Auth0 のほうが良さそう。

特記事項

JavaScript Framework

Next/Nuxt の話から。

Nuxt.js

2017 年から一度も使わなかったタイミングがなく、2018年には書籍も書いて愛用し続けるスタックの中心技術。

SSR/SSG/SPA 全てをうまく行うことができ、ブログやコーポレートサイトから、重厚なSPA開発やSSRが必要な複雑なアプリケーション要求までのほとんどをこなすことができる。

Vue 3 にて Provide/Inject の型周りの強化や Composition API による use パターンの台頭によって、状態管理や DI 的な依存注入をやりやすくなったが、 Vue 2.x におけるそれらが存在しない課題の解消手段も備えており、Vue 2.x 時代においてのアンサー的立ち位置の技術になった。

現状 Nuxt v3 のリリースが年を跨ぐように見られており、 Vue 3 の最新の現場に追従できない点がネックではあるものの、それを補って余りある程のパワーとポテンシャルを持っているので、しばらくは Vue.js での開発はこれ一本で問題ない印象。

2019 年には Intersection Observer によるリンクの先読みが入ったり、2020 年には Full Static が強化されたりと、 Next.js に負けず劣らずパフォーマンスに関する改善は常に行われているため、ただ使うだけで本来であれば相応のコストを書けないと得られない品質を享受することができるため、とにかく使えば良い。

Next.js

React.js を使う場合には Next.js を使わない理由が基本的にはないという形で採用している。

基本的に多くのフロントエンドエンジニアにとってそれなりのコストを払ってようやく成すことができる最適化が事前に施されている部分に魅力を感じており、アーキテクチャ支援も兼ねて使う Nuxt.js とはまた違う方向性の期待値を持っている。

アプリケーションアーキテクチャではなく、あくまでもユーザーがリクエストを送ってサーバーからレスポンスが返却される領域に関して期待している形。

その部分をそれぞれの現場で半端に最適化するのはナンセンスなので、突き詰めるつもりがなければ素直に Next.js が良い。

Styling

Tailwind CSS

推し続けて数年の大本命。これだけあれば良い。

UI というものは基本的にそれに相当するロジックがあった上で限定的に余白感やサイズが変わることが頻発するので、それに耐えうる柔軟性が何よりも重要。

生産性と柔軟性がどちらもあり、それらを style タグ直書きよりは圧倒的に上位のレイヤーで解決できるのが嬉しい。コンポーネントに CSS への関心がなくなるところも Good。

API Layer

axios

俺々 Fetch ライブラリをそれぞれの現場で再生産するよりは圧倒的に筋が良いと考えているため、互換を謳うタイプの軽量ライブラリは Universal でないことが多いため。

特別こだわりがあるわけではなく、同じように扱えるものがあったら乗り換えて良いという程度。moment.js は moment.js という共通言語がほしいだけで、その実装はなんでも良いというのと同じ認識。

なので Datetime は @nuxtjs/dayjs を開発・管理するくらいには概ね compatible な Day.js を使っているし、おそらく必要があれば乗り換える。

Firebase

Firebase を利用していてかつ Firestore を利用しているプロジェクトでは、Firebase JavaScript SDK 経由で Firestore にアクセスするので利用している。

採用数が多いのは単純に Firebase を利用しているプロジェクトが多い(ElevenBack LLC. のアプリケーションは全て Firebase で作られている)ため。

インフラストラクチャ/サーバーレス

Google AppEngine

なんだかんだで Node.js を利用する場合は Google CloudRun より圧倒的に優秀だと感じており、大抵の場合は AppEngine で良い。

利点はセキュリティパッチが自動で当たる・静的サイトホスティングが組み込まれており、それが自動的に Cloud CDN とも連携されている・デプロイが高速・app.yamlの柔軟性など。

Node.js アプリケーションで PaaS の機能を飛び出してコンテナとして重厚な機能が要求されることはほぼない(AppEngine は puppeteer でも十分動く程度にはランタイムは揃っている)ので、より取り回しやすいほうが良いという主張。

とりあえず Cloud Run ではなく、とりあえず AppEngine にしておいて、無理なら Run を使うくらいが良さそう。

Firebase

なんだかんだで今年も技術の軸として使う機会が非常に多かった。Authentication が優秀、クライアントサイドを中心としてアプリケーション構築がしやすいなどが理由。

基本的に有している機能面においては不満はないものの、Firestore が AP リージョンでも遅い、Firebase Authentication も初期化に500ms程度は平気でかかるなど、パフォーマンスを重視する Google の広告勢との社内的な派閥を感じる部分がつらい。

需要は常にある技術だと思うので、とにかくやり得。

あと Firebase Hosting は裏側が Fastly なので配信基盤としてもかなり優秀で、十分な品質がありつつも最近はプレビューも可能になったりと開発も続けられている点に安心している。

Netlify が静的ホスティング基盤としてはレイテンシが激しく、それこそ Firebase の重いほうの技術を使うのと同じかそれ以上にボトルネックになりやすいため、高品質の静的サイトホスティングを行いたいなら Firebase Hosting か Amplify Console という感じ。

デザインについて

今年は OOParts の UI デザインや自社サービス Koibumi の UI を作成したりしたが、基本的に全て Sketch で実装してから Tailwind で UI に起こすというフローだった。

職場も Sketch だが、徐々に Figma の流れは来ているので変えないといけない流れが出たら差し替える。とはいえ本職ではないので、必要ならというところ。

その他概念

React/Vue 共に JSX を中心に記述するという部分と、基本的に Node.js-first で Universal なコードを記述するという辺りは特徴的な部分に見える。

結果としてバックエンドやクラウドネイティブも意識する機会が増え、フロントエンドに関わる○○を触れる機会が多くなっている印象。

2018年あたりまでは単純にバックエンドで開発するからその付属技術としてクラウドに対する理解が深まるということが多かったが、最近のものはフロントエンドのために Node.js サーバーが立つことに由来しているという自己理解。

またそのフロントエンドのために Node.js サーバーが立つことは、動的に生成されたコンテンツに対して、OGP などを始めとした Google Bot ではないものからの流入が多分に含まれるコードを書く機会が多いことに由来している。

利用しなかったもの

Vue.js

全く使っていないというわけではないが、Nuxt.js が支配的になっている。結果として Nuxt.js v3 の影響を請けて Vue 3 の Production 投入が遅れているエンジニア的なデメリットはあるが、アプリケーション本体のデメリットにはなりえていない状態。

Angular

単純に今採用してる現場にいないから以上でも以下でもない。

AWS 全般

CloudFront 周りと Amplify Console を除く。

個人的には別に AWS と GCP の間にこだわりがあるわけではないが、Google Way に従う場合に高い生産効率を出してくれる GCP が Node.js を中心言語の一つに据えているからというだけ。

Dynamo DB を仕事で最後に利用したのが 2018 年であり、2019 年公開の On-Demand 以降の実態を知らないあたりの危機感があるが、それ以外はコンテナ中心なのであまり気にしていない。

Ruby/PHP

単純に組織にないのと、Developer にとっては Rails/WordPress が組織にないことは福利厚生の一種だと認識していることから新規で使うこともないため。

クライアントワークの場合は WordPress 使うのはもちろん悪くないけれど、いわゆるWeb制作ながらくやってないことから使わずに完結。

筆者は WordPress の運用やプラグイン開発などを過去に行っており、 エンジニアが存在する組織においては「WordPress の柔軟すぎる WYSIWYG によるルック・アンド・フィールの壊滅リスク」や「WordPressのシェアからくる攻撃の多さ」などのリスク要因が CMS としての利便性を勝るケースがあり、エンジニア観点でコストが高いという意味で言及しています。 Biz 観点を含めた合理性で採用が視野に入る場合でも、上記のような開発リスクを勘案し採用しないという選択肢があり得ることを、合理性より従業員のエンゲージメントを優先する意味で、ここでは「福利厚生」と呼びます。

GraphQL

単純に現場にいないことと、個人として積極的に採用するのはペインのほうが多いと感じている技術のため。

Hasura が個人的に GraphQL に対して持っている課題感に対して有効そうなので、年末年始は触ってみることにする。

おわりに

というわけで、元々関心の対象であるクラウドネイティブと、軸にある Node.js にフロントエンド事情が合わさっているようなスキル構成になっているなという印象でした。

深い部分と浅いけれど話せる/最低限の構築ができる部分がほどよく並んでおり、ハードスキルを伸ばしたい場合は今浅いけれど深めたい部分にフィーチャーしていく形が喫緊だとベスト。ただソフトスキル系(特に Hiring や人事ごと、ピープルマネジメント)にリソースを割いている部分が現状は多分にあるので、強みが失われないようにハードスキルのコアは維持しつつ、その他はできることをしていくような状態です。

ただの一例ではあるものの、試しにカテゴライズしてみると色々と見えることもあると思うので、よければ同じフォーマットで他の人もやってみてもらえると。