NestJS(+ TypeORM) について調査中

NestJS とは

A progressive Node.js framework for building efficient, reliable and scalable server-side applications.

https://nest.js

上記の通り、サーバサイドの MVC フレームワーク。

Model は TypeORM を利用している。View や Conroller は Angular っぽい書き方で書ける。シンプルに TypeScript で MVC 開発したい場合にはいい感じかもしれない。

StackShare での比較 (vs Next.js)

最近になって Next.js より人気が出てきた感じ。

Meteor との比較をしようとおもったけど、Meteor の人気が高すぎて Next.js, Nest.js はまったく比較にならんかった。

参考情報

このスライドがよくまとまっていて大変助かります。ありがとうございます(∩´∀`)∩ Swagger UI との連携もできるなんて素敵。

一方 TypeORM ではこんな話題もある。Java の Hibernete ORM っぽい動きが混ざってるから混乱を生むのかもしれないなぁ、と感想を抱いた。sync を無効にすれば、ある程度開発手法も統一できるかもしれない。

普通に migration で次々と Model を変えていく方式に変更してもいいんじゃないかな、と思う。Sequelize でも migration を書いたことはあるけど、JS を使った migration は何というか書きづらいことこの上ないので、TypeORM 試してみて快適だったらいいなぁ、と願うばかり。

自分が Ruby on Rails 脳にだいぶ毒されているのは自覚しているけど、良い代替案があったらいいんだけどなぁ、とも考えている。Go とかでも「これ」といったものがまだ見つかっていないので、継続して Go、JS あたりで調査を続けていくつもり。


無理に SPA にしなくてもいいんじゃない?(最近のフロントエンドについて)

最近色々気づきがあったので memo

書いている人の前提

  • Ruby on Rails エンジニア (webpacker 利用経験あり)
  • webpack もわかる
  • react, Angular, Vue.js 触ったことある
  • css 周り(scss がメイン)

思ったこと

上記の通りなんだけど、結論から書くと「新規で作るプロジェクトを無理して SPA にしなくてもいいんじゃないか。」という意見。

HTML への binding をしやすいという意味で jQuery は流行ったわけだし、react, Vue.js は jQuery の次のステップという意味でわかりやすい

Angular は SPA に特化しているイメージがあって、DI、Service 層など独自の概念が構築されていて、初期学習コストは高いかもしれないけど、恐らく SPA でエイヤと作るにはとても作りやすい (react とかで API 叩く層を作るとなると、redux-saga とかライブラリ選定から始まってしまう)

と考えると、採用技術は用途によって異なるわけだけど、恐らくまだまだ MPA(Multi Page Application: SPA の逆で従来の MVC フレームワーク(Rails とか)で実現している)が活躍しそうだと思っている。

せっかく Model を定義して、テンプレートエンジンに食わせて、 HTML を吐き出せるようにしているのに、わざわざ API を生やして、フロントエンド用にまたモデルを定義する意義、というのは有ることは理解できる、が、恐らく小さく始めるプロジェクトだと仰々しすぎる節がある。

じゃぁ、フロントエンド、バックエンドを分けるメリットを考えてみると、圧倒的にスケーラビリティという点で軍配が上がるし、責任分界点という意味でもチーム開発しやすい、という点もある。

逆にフロントエンドを SPA にするデメリットもあると思っていて、SSR 対応するときにめっちゃ辛い。Google さんから正しくレンダリングしてもらうためには、結局地道にページビューを確認していく作業が漏れなくついてくる(SSR 対応やった身からすると)

逆にフロント/バックエンドを分けないメリットを言えば、手元に一つの環境(MVC フレームワークが動作する環境)があれば、手軽に試すことができるという点。SSR を考えなくてもいい(かもしれない)という点。

分けないデメリットは、JS コードがスパゲッティになりがちになる。従来の jQuery を使った方法を取ると、あっという間に「どの JS がどの DOM をいじっているかわからん(´・ω・`)」となり得る。

けど、そういう場合って SPA でも同様のことが起きる可能性があると思っていて、結局は SPA/MPA での土俵で語ることではないと考えている

個人的にはプロジェクトは軽いところから、段々とスケールさせる方向に持っていく方が好みなんだけど、「最初からフロント、バックエンドが分離されていてよかったー!」という成功例も見てみたい。


ニュース:郷ひろみや稲葉浩志が若く見える秘訣は 高須克弥院長に聞いてみた


x86の機械語をざっと見渡す

x86の機械語をざっと見渡すには、このpdfが世界で一番整理されてると思う

最近気になった Qiita 記事 & サイト 記事

https://speakerdeck.com/fadis/zuo-tuteli-jie-suruwireguard