はてなブックマーク

こんにちは。sumirenです。 イントロダクション 先日、Next.js 15 RCが出ました。App RouterでPartial Prerenderingが広く使われ始める日も近いのではないでしょうか。 Partial Prerenderingは、特にStreamingと一緒に利用し、Vercelにデプロイした場合、強力に最適化が行われます。最適化は非常に高度で、部分的な静的レンダリングといったアプリレイヤから、エッジとオリジンの使い分けといったインフラの構成まで絡む複雑な設計です。最終的にVercelにデプロイされた後の全体の動作イメージが頭に入っている方は少ないのではないでしょうか。 この記事ではPartial PrerenderingとStreamingについて、Vercelデプロイ後の動作イメージがついている状態を目指します。静的ルートやサーバーサイドフェッチなど単純な例から

こんにちは。sumirenです。 イントロダクション 先日、Twitterで以下のポストが話題になっていました。 一部曖昧なところもありますが、推測と動作検証結果も交えて要約すると、以下のことを言っています。 VercelがホスティングしているWebサイトは、エッジでのサーバーサイド処理を行うことをやめた Next.jsに関して、VercelでPPR(Partial Prerendering)を利用した場合、サーバーサイド処理はNodeランタイムで行われる この記事では、このポストに絡めて、PPRとエッジに関する筆者なりの所感や解説を述べていきます。この記事の大部分はポエムですが、一部、技術的な事実についても述べるつもりです。そうした部分について誤りがあればご教示ください。 Vercelがエッジでのサーバーサイド処理を行うことをやめた件について エッジの効能 そもそもエッジに期待していたこ

sumirenです。 技術顧問やSREをしています。 背景 2024年現在、OpenTelemetryが盛り上がっており、ベンダへの依存度を下げてテレメトリを収集・送信することがトレンドになってきているように思います。多くの企業様で、OpenTelemetry対応のオブザーバビリティバックエンドを選定されているのではないでしょうか。 一方で、E2E自動テストツールなどもそうですが、デベロッパーツールは画面やUXの情報がパブリックな情報として出回ることが少ないように思います。オブザーバビリティバックエンドの場合、シグナル3種に関してOpenTelemetryベースでもフルに機能が活用できるのかという疑問もあります。 そうしたこともあり、オブザーバビリティバックエンドは実際にトライアルしてみないと選定しづらいです。監視など狭義のオブザーバビリティ外の機能や、OpenTelemetryの範囲外の

sumirenです。 SREやSDETや技術顧問やフルスタックエンジニアをしています。 この記事は OpenTelemetry Advent Calendar 2023 3日目の記事です。 2日目の記事は @k6s4i53rx さんの OpenTelemetryとOpenObserveを使ってKubernetes監視をかじる でした。 背景 OpenTelemetryを使うと、分散システムの各サブシステムでどのように処理が進んだのか可視化することができます。 経験を積んだエンジニアの方であれば、各サブシステムとオブザーバビリティバックエンドが一体どのようなコラボレーションをしているのか気になることかと思います。実際、SDKやOpenTelemetry Collectorを使って手軽に分散トレーシングを実現できても、仕組みを理解できていないと、いざトラブルが発生したときに問題解決が難しいでし

テックリードとして2つのプロジェクトのテスト自動化を推進しています（本業）。 この記事では、プロジェクトでの経験を踏まえ、APIテストの位置づけ、システム上のスコープ、2つの方式について説明します。 この記事の目的 これから新規/既存WebシステムのAPIテストを自動化する人に向けて、APIテストの位置づけ・システム上のスコープ・2つの方式を紹介し、よりよいアーキテクチャを選択してもらうこと 想定読者 この記事は、テストピラミッドの考え方を採用し、以下のような方針でテスト自動化を進めることが前提です。 ユニットテスト、UIテスト、APIテストのように、粒度・観点の違うテストをバランスよく用いて、品質を効率的に担保する ユニットテストなどのより小さい粒度のテストで品質の大部分をカバーし、APIテスト、E2Eテストなどのより大きい粒度のテストをできる限り削減する 上記の前提を読んでも理解できな

これはConventional Commitsに従ったものです。 結論 多くのOSSや開発現場は、（明確に宣言していないものの）Conventional Commitsに影響を受け、PRタイトルやコミットメッセージを設定しています。 シンプルな仕様ですので、チームで開発する上で知っておくと良いと思います。 仕様/用途編 本家仕様 Conventional Commitsは、Gitのコミットメッセージの形式に関する仕様。 シンプルでドキュメントも分かりやすく、こちらのサマリと例から大体つかめる。 コミットメッセージに含める情報 commit type：コミットの種別を表現する fix：バグ修正 feat：機能追加 上記以外の種別もチームで決めて使ってOK（※標準的な仕様は後述） optional scope：commit typeに付け加えて、コミットが対象とするコードベース内の領域を補足す

sumirenです。 背景 フロントエンド界隈はベンダやコミュニティ主導で新しいアーキテクチャや技術的手法がどんどん出ていて素晴らしいです。 一方、そうして量産されてきた用語が、界隈の変化に置いていかれている側面もあるように思います。例えば、SSRという用語を取り上げると、コンポーネントからHTMLへの変換を指すこともあれば、サーバー側でデータを取得することを指すこともあります。 実際、業界のパイオニアであるVercel/Next.jsも、そうした現状に対する懸念を持っているように思われます。実際、Next.js App Routerでは、以下のような変化が見られます。 getXXXPropsが廃止され、fetchに対する引数で表現されるようになった SSRやISRという「レンダリング」という言葉を、フェッチの文脈で使わなくなっている しかし、そっとドキュメントを書き換えた程度では、人々に

sumirenです。 2023年5月5日、ついにNext.js App Routerがstableになりましたね！ おめでとうございます！！ありがとうございます！！！ 今から本番で使うのが楽しみで待ちきれません。 13.4のリリースではstableの宣言とともに、目玉機能としてServer Actionsが来ています。Data Fetch（というか、もはやData Handling的なもの）の機能の一部として、とても興味深いです。 さて、Server Actions自体の解説は他の方に任せるとして、リリースノートには以下のような一文があります。 Server Actions in Next.js have been designed for deep integration with the rest of the data lifecycle, including the Next.js

注1. ソースはsrc配下にある前提になっていますので、適宜変えてください。 注2. 導入後、設定の微調整は適宜行ってください。 結論 1. パッケージインストール 5つインストールする。 パッケージマネージャに応じてコマンドは変えること。 npm install --save-dev eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin eslint-config-prettier prettier { "env": { "es2021": true // 環境に応じてenvは変えてください // "node": true, // "browser": true }, "extends": [ "eslint:recommended", "plugin:@typescript-eslint/recommende

2022年12月下旬、Next.js 13.1がリリースされました。 良いタイミングということで、この記事では、appDirやturbopackの機能がもうすぐGAになるのか、筆者の予想をシェアしたいと思います。 ※本当はv13.1のアップデート内容を事実ベースで紹介するというコンセプトだったのですが、大きな変更や難しい変更がなく、解説することがなくなってしまったため、上記コンセプトにしました。 この記事のゴール turbopackやappDirについて、筆者視点の近況理解や見方を伝えることで、読者の方に何かしら学びがあったり、考える機会になること 結論：まだ来ない 結論として、turbopackもappDirもまだまだ実用は難しいという印象を持っていますので、なぜそう思っているかを説明していきます。 Next.js 13.1時点のturbopack 改善はしているが、進化はしていない t

導入 Next.js 13では、目玉機能としてServer Componentsが導入されています。 多くの方が、React 18のRFCや解説を読み、「なんだこれは...」となったのではないでしょうか。（筆者はなりました） 筆者は20時間以上かけて、Next.js 13のドキュメントをほぼ全て読み、片っ端から動作を確認しました。 その結果、Next.js 13において、Server Componentsは難しいものではないという結論に至りました。 この記事では、筆者の調査結果を踏まえ、Server Componentsが全く難しい技術ではないことを説明したいと思います。 この記事のゴール Next.js 12 → Next.js 13においてServer Compoentnsに不安を感じている方が、「なんだ、Server Components楽勝じゃん」と思えること 結論 Next.js

前置き 背景 オブジェクト指向プログラミングのインターフェースについて、以下のような例で学んだ方は多いのではないでしょうか。 public interface Animal { void bark(); } public class Dog implements Animal { void bark() { System.out.println("ワン"); } } public static void main(String[] args){ Animal animal = new Dog(); // Animal型の変数にDogインスタンスを代入できる animal.bark(); } 上記は極端な例ですが、 「 Dog dog = new Dog(); と比べて何がいいの？」 という疑問に答えてくれる情報をなかなか見つけることができず、言語仕様と割り切って覚えてきた方は、実際に多いの