Next.jsの考え方Next.js App Routerにおける設計やベストプラクティスを、筆者なりにまとめました。
PPR - pre-rendering新時代の到来とSSR/SSG論争の終焉
本稿はNext.js v15.0.0-rc.0時点の情報を元に執筆しており、PPRはさらにexperimentalな機能です。v15.0.0のリリース時や、PPRがstableな機能として提供される際には機能の一部が変更されてる可能性がありますので、ご注意下さい。 Partial Pre-Rendering(以降PPR)はNext.js v14.0で発表された、SSRやSSGにならぶ新たなレンダリングモデルです。 PPRは前述の通り開発中の機能で、v15のRC版にてexperimentalフラグを有効にすることで利用することができます。ppr: trueとすれば全部のページが対象となり、ppr: "incremental"とすればexport const experimental_ppr = trueを設定したRouteのみがPPRの対象となります。 // next.config.mjs
API開発の最高のDXを求めて - NestJS+Prisma+AWS Copilot
最近、何度目かになる個人プロダクト開発をしようという思いつきからAPI開発をしてて、その際できるだけ低コストでDX（開発者体験）を追求してみようとやってみたら、結構いい感じにできて個人的にはまぁまぁ満足できました。 数年前から考えるとDX関連の進化はめざましく、ユニットテストやLint、フォーマッターなどがあるのはほぼ当たり前になってきました。ここからさらに数年後に見たときにまた大きく変化してるような気もするので、見比べるためにも備忘録がてら技術選定やツールの使い勝手について記録したいと思います。 技術選定 言語選定 DXってところを重視するとやはり静的型付は欲しい＋多少なりとも使い慣れてる言語が良いなと思い、RustとTypescriptの2択にしました。 Rustは言語思想がめちゃくちゃ面白くて好きなので、今回もRustにしようかなぁとも思ったのですが、主流のORMのDiesleの型エ
Railsをやめても解決しない問題
序文 昨年末くらいからRailsとフルスタックJavascriptの論争の記事がよくバズってましたね。主にORMとパフォーマンスやSPAが論点として多かった気がします。 Rails側のSPA作りづらい問題に対し、hotwireが一つの解として今後どういう受け入れ方をされて行くのか、どう発展していくのかは気になるところです。 未来のフルスタックフレームワークの代表争い さてこの論争、僕は「未来のフルスタックフレームワークの代表争い」だと思っているのですが、結構難しくって視点次第でどうとでもなっちゃうような気がしてます。 というのもこの手の技術選定の問題ってアプリケーション規模やチームの思考、求められるサイト特性などによって合う合わないがあるので、一概に正解がわからないんですよね。 例えば今勉強がてらブログを作ってみたい、という人には迷わず僕はblitz やNext/Gatsby＋外部サービス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
