Побудувала фронтенд на Next.js 16 зі свідомими стратегіями SSR, SSG і CSR та багаторазовою фабрикою prefetched‑server‑page, що усуває каскад N+1 на кожній автентифікованій сторінці, перенесеній на неї.

Ситуація. Автентифікований дашборд мав відчуватися швидким і водночас залишатися по‑справжньому інтерактивним, а ці дві мети тягнуть у різні боки, якщо підійти до них наївно. Якщо забирати все на клієнті, перше завантаження затягується, а гірше — виникає патерн N+1, коли кожен компонент прокидається і робить власний запит, тож одна сторінка перетворюється на каскад мережевих звернень.

Завдання. Кожну частину застосунку потрібно було рендерити саме так, як їй насправді підходило, не жертвуючи клієнтською інтерактивністю там, де вона мала значення.

Дія. Фронтенд на Next.js 16 використовує для кожної поверхні застосунку той режим, який їй підходить, замість одного рішення на всі випадки. Маркетингові й публічні сторінки генеруються статично — вони не змінюються залежно від користувача, тож рендерити їх на кожен запит немає сенсу. Справді інтерактивні частини лишаються клієнтськими. А там, де каскад N+1 справді дошкуляє, — автентифікований дашборд і великі сторінки‑каталоги — рішення винесли у фабрику, а не робили вручну: createPrefetchedServerPage отримує дані сторінки на сервері й передає їх клієнту вже заповненими, тож компоненти одразу з’являються зі своїми даними, а не йдуть по них кожен окремо. Стратегія інвалідації кешу задокументована для кожного запиту, тож дані лишаються актуальними без повторного завантаження того, що застосунок уже має.

Результат. Сторінки, перенесені на цю фабрику, піднімаються за одне звернення замість шторму звернень, а оскільки це фабрика, а не патерн, який копіюють вручну, наступна перенесена сторінка успадковує цю поведінку безкоштовно. Решта автентифікованого застосунку досі рендериться на клієнті й стоїть у черзі за нею — це міграція з робочим механізмом і очевидною наступною сторінкою, а не завершений перехід.