思いついたまま書き連ねたメモです。
「これが唯一の正解」だとは全く考えてなくて、あくまで「便利な方法の1つ」として書いてます。
機会あれば清書したい。
動機: https://twitter.com/mazgi/status/1223273907555192832
サンプル+説明 
関連: https://qiita.com/mazgi/items/6892d3f5e8223fd6ba6b
開発環境: Linux + Docker + Docker Compose
ローカルでもクラウドでも良いのでLinuxマシンを1つ用意して docker-compose up するのが楽です。
本番環境がKubernetesなどのコンテナプラットフォームなら開発も本番もDocker上で済むのは開発→本番差分でのハマりも軽減できて特におすすめです。
(気軽にローカルファイル読んでたとか、本番はフロントエンドとWeb API分かれるのにいつの間にか同じホストで動く前提の構成になってたとか、 etc.)
「Docker Compose初めて」って方は が参考になれば幸いです。
docker-compose.yml と Dockerfile.d/* コピーすれば割と動くはず。
- https://github.com/mazgi-showcase/202001.nextjs-typescript-jest/blob/bc32494ed41b3c46ff969bc8230e32be0f1399c8/docker-compose.yml
- https://github.com/mazgi-showcase/202001.express-typescript-build-with-webpack/blob/428f70743979a072e8ff107aa75e3bc7297c8209/docker-compose.yml
気をつけることとしては Docker for Macは劇重いのでLinuxを用意しましょう！
どうせ本番はLinuxかコンテナで動かすでしょうし。
開発言語: TypeScript
ブラウザがしゃべれるのはあくまでJavaScript(ECMAScript)なので、Web開発である以上JavaScriptから遠く離れるのは難しいのが実情です。
好みや慣れによりますが、個人的にはWebフロントエンドからWeb APIまでは同じ言語で書いてしまった方がコンテキストスイッチ少なくてやりやすいと感じます。
Web API、とくにBFFと呼ばれるやつは「Webフロントエンドに向けて機能を提供する」のが仕事だと思ってるのでWebフロントエンドと並行して開発する際の効率を重視したいです。
しかし型がほしい、型の有無は開発規模膨らんだり保守フェイズで効いてきます。
TypeScriptは型ありかつ変換(Transpiling)でJavaScriptになるので型を使った堅い開発とブラウザでの動作を両立することができます。
ただ、JavaScriptへの変換にまつわるトラブルに遭遇することはあります。。
フレームワーク/ライブラリ
React
シェアが大きく、当面廃れなさそう。
(Vueなども良いものだと思います)
TypeScriptフレンドリー。
ソフトウェアエンジニア視点ですが、特にMaterial UIなどのCSSフレームワークを導入するとHTMLやCSSをあまり書かずに開発できるので、「アプリケーション開発」の感覚でWebフロントエンドを書きたい場合やHTML/CSSにあまり慣れていない場合は便利だと思います。
一方で元のスキルセットがWebデザイン寄りな方はCSSフレームワークなどの組み合わせによっては「普通にHTML/CSS書きたい！」とフラストレーション溜まってしまうかもしれません。
Next.js
React単体でWebフロントエンドの開発はできる、しかし開発時や運用でもサーバー立てたいケースはままある、そんな時webpackやbabelを学んだりloaderなどの選定をしたくない。
初学者にとって「Webフロントエンドを本番向けにbuildする」ハードルはそれなりに高い(高かった)。
繰り返しますけどwebpack, babel, 各種loaderやpluginなどの選定や設定は本来リソースを割きたくないにも関わらずとても時間がかかります、数日ハマって成果がxxx.json or xxx.js数行変更なんてザラです(ハマりました)。
プロジェクトのディレクトリやコンポーネントの構成、開発用/本番用のビルドパイプライン設計なども煩わしく感じることがある。
Next.jsはこれらをwrapしてくれて構成もお仕着せてくれる。
(Nuxtなども良いものだと思います)
Next.jsのレールに乗ってプロジェクトをスタートするのは1つの良い始め方だと感じた。
GraphQL + TypeGraphQL + TypeORM
GraphQL自体はフレームワークでもライブラリでもないが、体験の良さはライブラリである TypeGraphQLとTypeORMに支えられている部分があるのでここに記載。
RESTも良いですが、開発初期によくある「RDBMSのエンティティをほぼそのままWeb APIで返す」ようなフェイズでGraphQLとこれらのライブラリは開発体験がよかったです。
こんな感じでアノテーション付けてエンティティを書けるのでエンティティ設計するだけでDBスキーマ生成とGraphQLスキーマ定義の両方が済んで楽、少なくとも初期は。
https://github.com/mazgi/console/blob/b86c5367366dbec658a6e8b6c467ec215ee379d1/bff/src/entities/User.ts
高負荷なシステムや長期運用はまだ未知です。
何使ってもスキーママイグレーションとキャッシュがつらそうですね。。