Next.js 16.2 Adapter API: Chạy ở đâu cũng được, không còn bị lock-in Vercel

Nếu bạn từng deploy Next.js lên AWS, Cloudflare hay bất kỳ đâu không phải Vercel, bạn biết cảm giác đó cái gì cũng "gần đúng" nhưng không bao giờ hoàn hảo. Streaming lỗi, ISR không revalidate đúng, middleware chạy sai. Mình đã từng mất cả tuần debug một cái cache invalidation trên ECS chỉ vì Next.js build output không có document nào mô tả rõ cách nó hoạt động.

Next.js 16.2 vừa thay đổi hoàn toàn câu chuyện này với Adapter API stable. Và lần này, nó không phải lời hứa suông.

Vấn đề thực sự nằm ở đâu?

Đa số Next.js app chạy đơn giản bằng next start trên một Node.js server. Hàng trăm nghìn team đang làm vậy, và nó hoạt động tốt. Nhưng khi bạn cần scale chạy nhiều instance, dùng CDN, serverless functions, edge compute mọi thứ bắt đầu phức tạp.

Những thứ tưởng chừng cơ bản trở thành nightmare:

Cache synchronization giữa các instance
On-demand revalidation phải propagate đúng
Streaming phải hoạt động ổn định
Server Components, PPR, middleware mỗi cái tương tác với nhau theo cách không ai document

Theo kinh nghiệm của mình, vấn đề lớn nhất không phải là Next.js không hỗ trợ các platform khác. Vấn đề là không có contract chính thức nào giữa Next.js build output và platform providers. Mỗi lần Next.js release version mới, các platform phải reverse-engineer lại build output để hiểu cái gì thay đổi. Đó là lý do Netlify, Cloudflare hay AWS luôn chậm hơn Vercel vài bước.

Philippe Serhal, engineer tại Netlify, nói thẳng: "90% vấn đề của chúng tôi đơn giản là thiếu một cơ chế stable, có document để đọc build output."

OpenNext — cầu nối trước khi có giải pháp chính thức

Trước khi Adapter API ra đời, cộng đồng đã tự giải quyết bằng OpenNext. Nó dịch Next.js build output thành thứ mà các provider có thể consume, map framework semantics lên primitives của từng platform.

Điều mình thấy hay là OpenNext không chỉ là workaround nó chứng minh rằng Next.js build output có thể trở thành một stable interface. Từ một compatibility layer, nó trở thành production-grade adapter, đặc biệt trên AWS.

Và chính insight này đã dẫn đến collaboration giữa Next.js team với OpenNext maintainers, cùng engineers từ Netlify, Cloudflare, AWS Amplify và Google Cloud. Họ publish Build Adapters RFC vào tháng 4/2025, lập working group, và làm việc cùng nhau từ đó đến giờ.

Adapter API hoạt động như thế nào?

Next.js 16.2 ship với một Adapter API stable, public, có type. Khi build, Next.js tạo ra một mô tả có version của application: routes, prerenders, static assets, runtime targets, dependencies, caching rules, và routing decisions.

Adapter consume output này và map lên infrastructure của provider.

Adapter implement hai hooks chính:

modifyConfig — chạy khi configuration load, cho phép adapter điều chỉnh config phù hợp với platform
onBuildComplete — chạy khi build xong, adapter nhận toàn bộ output và transform theo nhu cầu

Điểm quan trọng nhất: Vercel's adapter dùng chính contract public này. Không có private hooks, không có special integration path. Adapter của Vercel là open source, bạn có thể đọc source code.

Đây là cam kết lớn nhất mà mình thấy từ Vercel: họ tự đặt mình vào cùng sân chơi với tất cả provider khác.

Test suite chung — cùng một bar cho tất cả

Adapter API không chỉ là spec trên giấy. Next.js team cung cấp một test suite cho adapter authors, cover:

Streaming behavior
Caching interactions
Client navigation
Real-world edge cases

Khi feature mới ship, behavior của nó được encode vào test suite. Adapter authors chạy suite với adapter của mình và nhận pass/fail cho từng feature.

Đây chính là test suite mà Vercel dùng cho adapter của họ. Cùng một correctness bar, không có ngoại lệ.

Verified Adapters — không phải ai cũng như ai

Để trở thành verified adapter (hosted dưới Next.js GitHub org, listed trong docs), cần hai điều:

Open source — để community có thể report và triage issues
Pass full test suite — đảm bảo compatibility đo lường được

Mỗi verified adapter do team build nó sở hữu. Publishing rights, release cadence, implementation decisions tất cả thuộc về họ. Điều này hợp lý vì mỗi platform có architecture khác nhau.

Các adapter đã có ngay từ bây giờ:

Vercel adapter — open source, map output lên serverless + CDN
Bun adapter — reference adapter cho custom implementation
OpenNext adapters — đang trong quá trình verified cho AWS, Cloudflare, Netlify

Providers cũng có thể build closed-source adapter trên cùng public API. Không bắt buộc phải verified.

Ecosystem Working Group

Điều mình đánh giá cao nhất là việc thành lập Ecosystem Working Group một forum thường trực để coordinate changes giữa các providers. Khi Next.js team plan breaking changes, các provider được biết trước và có thời gian adapt.

Đây không phải kiểu "chúng tôi sẽ thông báo khi release". Đây là collaborative design từ đầu.

Điều này có ý nghĩa gì với bạn?

Nếu bạn đang deploy Next.js trên Vercel không thay đổi gì, mọi thứ vẫn hoạt động.

Nếu bạn đang deploy trên platform khác đây là tin cực tốt:

Không còn reverse-engineer build output khi upgrade Next.js
Breaking changes có contract rõ ràng — major version bump, không phải surprise
Test suite chung đảm bảo feature parity đo lường được
Documentation cải thiện — guides mới về rendering philosophy, revalidation, CDN caching

Nếu bạn đang build internal platform hoặc custom deployment pipeline bạn giờ có thể viết adapter riêng dựa trên public API có type safety.

Theo kinh nghiệm của mình, đây là bước chuyển lớn nhất của Next.js ecosystem kể từ khi App Router ra mắt. Nó giải quyết đúng pain point mà rất nhiều team Việt Nam gặp phải: muốn dùng Next.js nhưng không muốn bị lock-in vào Vercel, đặc biệt khi infrastructure đã có sẵn trên AWS hoặc GCP.

Cuối cùng, mình nghĩ điều đáng ghi nhận nhất không phải là technical solution mà là cách nó được thực hiện. Vercel không tự làm rồi announce. Họ ngồi lại với OpenNext, Netlify, Cloudflare, AWS, Google Cloud, cùng design API, cùng viết test, cùng validate. Và adapter của Vercel dùng chính public contract đó, không có backdoor.

Đó là cách một framework nên phát triển. Bạn có thể bắt đầu explore Adapter API từ docs chính thức và thử viết adapter cho infrastructure của team mình.