noteでの大きくなりすぎたNuxt.jsのアプリケーションを分割する取り組みについて
![noteのフロントエンドApp分割](https://cdn-ak-scissors.b.st-hatena.com/image/square/1ddccf6cb465be47f090aa88c371857ca1cd0ddf/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F9d0bb3341d214a52b20b56bb9fd19ae9%2Fslide_0.jpg%3F18356863)
Mercari Advent Calendar 2018の24日目はメルカリBackendエンジニアの@sota1235がお届けします。 現在、私はWebのシステムをリプレースしMicroservicesアーキテクチャに移行するチームで働いています。 メルカリのMicroservicesアーキテクチャでは各Microserviceチームが責任を持ってSLI/SLOを定め、運用する必要があります。 このSLI/SLOを決める過程でいくつかの学びや難しさがあったのでそれをお話しようと思います。 SLI/SLOとは SLI(Service Level Indicator)とはサービスの品質を測るための指標です。 そしてSLO(Service Level Objective)とは各SLIに対しての目標数値です。 例えばSLIを全リクエストの50xエラー以外の割合として、SLOは99.99%とする、
Next.js + React Server Component のリファレンス実装が出たので、手元で動かしながら理解したメモ。 vercel/next-server-components: Experimental demo of React Server Components with Next.js. Deployed serverlessly on Vercel. これを書いてるモチベーションとして、Twitter を見る限り React Server Component のことを 「ただのサーバーサイドへの先祖返り」とか「SSR 結果を dangerouslySetInnerHtml してるだけでは?」みたいな反応があったので、そのへんの誤解を解きたい。 Introducing Zero-Bundle-Size React Server Components – React Bl
どうもReact大好きCX事業部の片岡です! 今回はReact界隈で話題になっている「React Server Components」についての内容を意訳してみました。 元ネタ 話題になっているこちらの記事が元ネタです。 https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html 概要 Fetch APIでデータをやり取りすると、バケツリレーが発生します。例えば、Spotifyのアーティストページにはアーティストの情報と人気の曲とアルバム一覧が並びます。この時、人気の曲とアルバム一覧を取得するには、アーティスト情報を取ってこないといけません。そうすると、アーティスト情報を取得している間と人気の曲・アルバム一覧を取得するまでにクライアントサイドとサーバーサイドで無駄な待機時間が出来てし
puppeteer をラップした api server みたいなもので内部は koa が使われています。これを起動し、/renderへ url を path として挿入するとそのページの html が返されます。 例えば、/render/https://google.comとアクセスすると、google.com の html が返ってきます。 また、スクリーンショットも取れたりします。(/screenshot) 返す html は配信元とは一致はせず最適化されたものが返されます。例えば、console.log('hello')やdocument.write('test')だけ書かれた js などは、html に挿入された後そのスクリプトタグは html 内からなくなったり、baseがついたりします。 ちなみに rendertron を GCP で動かすのはもっと簡単だったりします。 インフ
#dynamic-rendering Dynamic Rendering とは https://developers.google.com/search/docs/guides/dynamic-rendering?hl=ja UserAgent がクローラーな場合に html をレンダリングしてからレスポンスを返すことにより、JS を実行しないクローラーに対して正しいコンテンツを読み込ませる技術 SSR との比較 Dynamic Rendering はヘッドレスブラウザなどを用いてレンダリングすることが多い 最終的には SSR にするのが良いらしい https://www.suzukikenichi.com/blog/dynamic-rendering-is-a-temporary-workaround/ SSR 実装難しくない? 選択肢 prerender.io https://prer
最近Nuxtでいろいろ作っているけど、無料で使える環境をいろいろ試してる。 いろいろメリデメあるけど、SPAならNetlify/SSRならHerokuがよさそう。 いままで試したものをまとめてみた。 ほしかったもの 主に開発してるのがCGM系のWebサービスなので、 動的なOGP画像などが設定できる(OGP芸) カスタムドメインが使える 日次のランキング集計などの定期実行ができる が、無料でできて、なるべく実装が楽で、そこまで遅くないのがうれしい。 試した5つのパターン 試したのは以下の5パターン。試してみた順で記載。 Nuxt(SSR) + Cloud Function 起動がかなり遅かった。。実装も大変なのでNG Nuxt(SPA) + Firebase Hosting 構築はかなり楽。ただ、OGP芸が大変でFunctionsが必要 Nuxt(SPA) + Netlify プレレンダリ
去年の今頃にNode.jsとGoでサーバサイドレンダリングをしました。 2017年になって自分の中でこうやってサーバサイドレンダリングすればいいなという一つの答えが出たことを書きます。 サーバサイドレンダリングの必要性 サーバサイドレンダリングをやる理由に2つ理由があると思います。 1つはSEO、もう1つが表示の高速化です。 もしGoogleからのアクセスのみを考えているのであればあまりサーバサイドレンダリングするメリットは薄いかもしれません。 GoogleのクローラはJavaScriptも解釈してくれると言われています。 それとsitemapを設定してもindexをしてくれるので個人的にSEOのためにサーバサイドレンダリングすることはとくにないです。 次に表示の高速化のためですがこれはファーストペイントの高速化のためにサーバサイドレンダリングするべきかですが これはその通りでサイトアクセ
久しぶりのブログです。 よく Node.js の人と思われがちですが、普段は Node.js でのバックエンド開発はもちろんですが React や Vue を書いていますので、たまにはフロントエンドネタを投稿しようと思います。 GitHub - hiroppy/ssr-sample: A minimum sample of Server-Side-Rendering, Single-Page-Application and Progressive Web App A minimum sample of Server-Side-Rendering, Single-Page-Application and Progressive Web App - GitHub ... リポジトリにあるコード見たほうが早いと思いますので、ここでは注意点等を列挙していこうかなと思います。 主な技術スタック de
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く