Хостинг Next.js как яблоко раздора. или почему обсуждают адаптеры как решение проблемы.
Появился на гитхабе RFC: Deployment Adapters API — модульную систему, которая позволит разным хостингам (не только Vercel) проще и стабильнее запускать Next.js-приложения.
Что не так сейчас Netlify (и другие: AWS, Cloudflare, Firebase) сталкиваются с тем, что Next.js — хоть и open-source — сильно «заточен» под инфраструктуру Vercel. Это мешает платформам поддерживать фичи на 100%, особенно новые: приходится догонять, тратить ресурсы и держать кастомные хаки.
Как делают другие фреймворки Astro, Remix, SvelteKit, Nuxt и Qwik давно используют систему адаптеров: хочешь деплоить в Netlify — поставь нужный адаптер. Хочешь в Cloudflare — поменяй его. Ядро при этом не меняется. Это удобно, гибко и снижает зависимость от вендора. Сейчас таким ядром выступает Nitro.
Почему это важно Vercel и команду Next.js давно хейтят за привязку к платформе в исходном коде. Разработчикам с селф-хостед развертыванием сложно поддерживать такие фичи. Один только шаринг кэша чего стоит. Поэтому появляются решения по типу Coolify, OpenNext, с возможностями как у Vercel, но не все хотят в это погружаться.
Адаптеры это шаг к настоящей совместимости и открытому сотрудничеству между платформами. А для нас, как разработчиков, — к стабильности, прозрачности и свободе выбора хостинга без страха потерять фичи или поддержку.
