Does not provide fallback content when JavaScript is not available. このサイトを視聴するにはJavaScriptを有効にしてください。サーバーレスとNuxtで特設サイトを作った話(Roppongi.vue #4) | blog.potproject.net
potpro (ぽとぷろ)

potpro (ぽとぷろ)

Full-stuck engineer(Not Full-stack)

JS/PHP/Go/Docker/Nginxなど。技術または趣味よりの発信ブログです。このブログ自体も自分がnetlify/gatsbyJS/Reactで書いてます。一部の記事はgithubアカウントでコメントできます。

サーバーレスアーキテクチャとNuxtで特設サイトを作った話(Roppongi.vue #4)

もう年を越していまいましたが、去年12月に行ったRoppongi.vue #4でLTした時の話を残しておきます。

サーバーレスとNuxtで特設サイトを作った話(LT)

おおむね以前の記事に書いたnuxt-serverlessを使いサーバーレスで安定した環境を作るTipsの部分と同じですが、Vueの外部イベントということなのでVue成分を少し増やしています。

この記事はLTで語れなかった部分を詳しく書いていく感じです。

Nuxtについて

今回は速度重視だったのでVuexも使わず、Scoped CSSとかそういうのもなく・・・。ただhtmlをVueコンポーネントに書き換える作業をひたすらやった感じ。

htmlをNuxtとVueのコンポーネントに書き換えたという感じだったので実際のところhtml + Vueでもよかったんじゃね?と思わなくもない。

ただ、Nuxtは某所では「NuxtはフロントエンドのRails」 とか言われているように、SPAの設計に関してほぼ全部最初から用意されており、設計もシンプルでわかりやすいのが良いところ。

まだ要件がふわふわした中で、設計と開発環境の構築自体は最初から整えることも出来て、かなりスムーズにこなせたので、アドバンテージは大きいと思います。

サーバーレスについて

特設サイトは性質上、短期間で実施するので工数も決まっており、しかも短期間での多くの変更が発生する可能性もある。なおかつ言ってしまえば設計にあまり時間を割けないパターンが多いです。

さらに大量のスパイクアクセスが見込まれます。今回語ったように開始直後アクセス数が20倍になりました。

普通に考えれば当然大量のアクセスを捌くにはしっかりとした設計が必要ということで、完全に前者後者の話は意に反するものです。

ということでのサーバーレスアーキテクチャだったわけですが、ユーザーに必要な情報を提供でき、サーバのダウンを起こさず、より高速に開発が出来たという点では非常に成功していたと思います。

いつもと違って保守性を考えなくていいということもあり、かなり攻めた構成になっている、というのもありますけどね。

当然ながら100%うまくいっているわけではないです。これを長く保守しようとすると辛い所はいくらでも出てくるはず。

でも結論としては、Nuxtとサーバーレスはいいぞ という感じです。

問題点

当然、完璧な設計というものはないもので・・・今回の開発で軽く考え付いた問題点はこんな感じでした。

Nuxt

まず、SPAでの設計の特異性。今までサーバサイドで処理したデータなどはほぼWeb APIから返すことが前提となるので、サーバサイドでいろいろするは通じません。

そこに関してはちゃんと設計を知っていれば問題ないですが、一番厳しかったのはクローズドかつサードパーティのJSライブラリ。

サードパーティのJSはDOMを直接へ変更して描画するようなコードだったり、サーバサイドレンダリングを前提とした作りになっていたりするので、SPAでの設計では無茶が生じることも多いです。

当然、仮想DOMでないということはレンダリングをブロッキングするのでパフォーマンスの影響度が高かったりもします。

一番はそんなの使わないべきですが、要件上致し方なく。ここに依存しまくっているものに関してはSPAの採用を考えたほうが良いと思われます。

後は・・・SSRする部分の切り分けですね。

<client-only>というタグを使えばSSRしなくなるので、SSRしてはいけないところに関しては注意が必要です。例えばブラウザにしかないwindow傘下のオブジェクトを使うときなど。サーバサイドエンジニアがNuxtをやろうとするとこの部分の知識が厳しいかもしれません。

サーバレス

一番はやはり、完全にクラウドのサービスに依存してしまうところ。サービスの知識が無いと操作をミスってサーバダウンを引き起こすこととなります。

サーバでのベストプラクティスが使えないという点も結構痛いと思います。問題のあるサーバにsshで入って検証、なんてことは基本出来ないです。

当然ながらサービス自体もバージョンアップしていくので、このあたりはサービスの成熟度によると思います。

とりあえずAWS LambdaはRDSにそのまま繋げてもOK、になってほしいですね・・・。 (AWS LambdaでRDSに繋げることがバットプラクティス、という話については前回の記事にて)

最後に

外部でLTするのはほぼ学生以来な気がしましたが、非常に楽しかったです。

ブログほど好き勝手出来ないという制約はありますが、リアルタイムで反応が来るのはやはりモチベ上がりますね。

また機会があれば・・・。