Това е моето мнение за това защо Next.js 13 се чувства незавършен и му липсват много основни начини, за да бъде използван в сериозно производствено приложение. Не ме разбирайте погрешно, не съм хейтър, next-13 предлага някои наистина мощни нови функции и съм сигурен, че бъдещите версии ще покрият тези аспекти.
1. Липса на конкретно решение за междинен софтуер
Въпреки че следващите 13 представиха файла middleware.js, не забравяйте, че той не е верижен като експресен междинен софтуер, който може да бъде свързан един върху друг. Поставянето на всичките ви нужди от междинен софтуер в един файл ми се струва твърде тромаво.
Заобиколни решения и алтернативи:
Тези библиотеки на трети страни могат да предоставят някои възможности за експресно маршрутизиране в междинен софтуер за маршрут. Но в сериозно приложение, използващо JWT удостоверяване и базирано на роли удостоверяване, ще имам нужда всеки манипулатор на маршрути да импортира и използва стек от мидълуер, което е твърде много неудобство. Също така, нещо толкова основно като това може да бъде свързано във верига, както са свързани файловете layout.js. Всяко ниво на влагане на директория може да има свой собствен междинен софтуер, който предава състояние чрез свойство на заявка като express.
Не ми е удобно да разчитам на библиотеки на трети страни за нещо толкова основно като това, това определено трябваше да е част от рамката.
Алтернатива №2
Използването на персонализиран сървър като express и използването на следващия модул за обслужване само на уеб трафик с изключение на API е алтернатива.
https://nextjs.org/docs/advanced-features/custom-server
Но проблемът с това е да кажем, че сте дефинирали getUsers API в експреса и също така се нуждаете от списъка с потребители за SSR, можете или да използвате предварително изградения API, в който случай не дублирате код, а отхвърляте трафик от localhost без основателна причина или директно извличане на потребителски записи от SSR компонент, в който случай дублирате код.
2. Файлът page.ts няма необработен контекст на заявка и поддръжка на междинен софтуер.
Next13 въвежда компоненти от страна на сървъра, които могат да извличат данни директно от базата данни. Това е наистина мощна функция, но в сериозно производствено приложение повечето маршрути ще бъдат зад удостоверяване и маршрутизирането ще бъде строго охранявано. Какви данни могат да се показват на дадена страница ще зависят от състоянието на влезлия потребител.
Въпреки че можем да използваме заглавки и бисквитки в компоненти от страна на сървъра чрез
https://beta.nextjs.org/docs/api-reference/cookies
https://beta.nextjs.org /docs/api-reference/headers
Аз лично смятам, че това е силно ограничаващо. Бих очаквал рамката да осигури общо място, където мога да декодирам състоянието на влизане и да предам потребителския контекст надолу по веригата към рендиране от страна на сървъра.
Настоящият подход ще изисква от мен да декодирам токени на всеки компонент или да разчитам на подпори, предадени от компоненти от страна на клиента. Проблемът с това е, че не може да се разчита на реквизитите от страна на клиента, когато се обмисля сигурността на вашето приложение. Състоянието от страна на клиента винаги може да се редактира от локален js и добавки.
Заобиколни решения и алтернативи:
Можете да запазите по-голямата част от приложението като компоненти от страна на клиента и да използвате всяка библиотека за управление на състоянието, за да активирате API със защитени токени всеки път.
Но това просто убива цялата идея за ускоряване с помощта на SSR. Next наистина иска да запазите по-голямата част от приложението като SSR и да имате само листови възли от страната на клиента. Обвиването на големи части от вашето приложение в доставчици на контекст прави цялото това дърво рендирано от страна на клиента. Въпреки че можете да спорите, че компонентите от страна на клиента могат да имат SSR компоненти като деца, тогава управлението на състоянието на влезли потребители отново е проблем, защото, както споменах по-рано, SSR компонентите получават само необработени заглавки и бисквитки и не могат да разчитат на клиентски странични подпори за сигурност.
3. Споделянето на контекст между сървърни и клиентски компоненти изглежда изключено
Както се казва в документите, сървърните компоненти могат да имат клиентски компоненти, но клиентските компоненти могат да имат само сървърни компоненти като деца или реквизити. Въпреки че това е напълно логично, сложната потребителска интерактивност е най-вероятно да се случи само на клиентски компоненти. Сега тази интерактивност ще трябва да задейства изобразяване от страна на сървъра за SSR компоненти. В състояние, в което не е влязъл потребител, това е лесно за постигане, но когато добавим удостоверяване към микса, става ненужно трудно. Най-вероятно ще обмислите използването на компоненти от страна на клиента само защото управлението на потребителското състояние в SSR componets е толкова трудно. Което също означава, че ще загубите всички предимства да започнете от следващия.
4. Edge не е за всеки
Next е направено от Versel и versel иска да купите тяхното предложение, което е с невероятно бързи крайни функции. Въпреки че edge е бърз, но е забранен за всяко приложение, използващо традиционна база данни като MySql, Postgres или MongoDB. Може да работи в DB стекове без сървър, но тези бази данни са тук, за да останат и не всичко трябва да се моделира без сървър.
Ако използвате някоя от тези функции, edge вероятно не е за вас:
- Бази данни и групиране на връзки чрез популярни ORMs като Sequelize
- Родни двоични файлове като puppeteer за генериране на PDF файлове
- Сокет връзки с вашия бекенд, който се свързва с redis клъстер за синхронизиране между сървъри с балансирано натоварване.
Следващият блясък:
Всички добри характеристики на next са силно фокусирани върху изживяването на разработчиците на интерфейса. Оптимизациите на етикета ‹Link› ‹Image› са похвални.
Следващото място, което активно бих препоръчал:
- Сайтът, който създавате, е сравнително малък
- Сайтът няма много сложно взаимодействие с потребителя
- Сайтът не зависи от собствените двоични файлове на бекенда
- Сайтът не се нуждае от сокети
- Сайтът няма много управление на състоянието или сложно управление на потребителите
- SEO е важно за сайта, който изграждате
