Vue, Laravel i Inertia w panelu B2B

Laravel z Vue i Inertią to dobry wybór dla panelu B2B, gdy panel obsługuje jeden zespół lub jeden portal, ma jeden frontend webowy i jest rozwijany przez ten sam zespół co backend. Osobne API i niezależna aplikacja SPA mają przewagę wtedy, gdy z tych samych danych korzysta kilka klientów – aplikacja mobilna, integracje partnerów, drugi frontend – albo gdy frontend i backend rozwijają różne zespoły w różnym tempie. Poniżej porównujemy obie architektury, pokazujemy ograniczenia Inertii i podpowiadamy, po czym poznać, że czas przejść na pełne API.

Jak działa Inertia – w skrócie

Inertia nie jest frameworkiem frontendowym ani biblioteką do API. To warstwa, która łączy klasyczną aplikację Laravel z komponentami Vue (lub React):

1. Routing, kontrolery, walidacja i autoryzacja zostają w Laravel.
2. Kontroler zamiast widoku Blade zwraca nazwę komponentu Vue i dane (propsy).
3. Pierwsze wejście na stronę zwraca pełny HTML z danymi strony. Kolejne nawigacje są wykonywane w tle – serwer odsyła tylko JSON z nazwą komponentu i propsami, a Vue podmienia widok bez przeładowania.
4. Uwierzytelnianie działa na zwykłej sesji Laravel, a błędy walidacji wracają do formularza automatycznie.

Wersja 2.0 dodała m.in. odroczone ładowanie części danych, prefetching przy najechaniu na link, odpytywanie (polling) i doładowywanie list przy przewijaniu. Oficjalne startery Laravel 12 dla Vue i React opierają się na Inertii i TypeScripcie, więc to dziś standardowa ścieżka w ekosystemie.

Architektura A: monolit z Inertią

```
Przeglądarka (Vue + Inertia)
↕ sesja, JSON stron
Laravel: trasy → kontrolery → usługi → modele
↕
Baza danych, kolejki, integracje
```

Mocne strony:

• jedna aplikacja, jedno wdrożenie, jedno repozytorium,
• brak osobnej warstwy API do projektowania, wersjonowania i dokumentowania,
• autoryzacja i walidacja w jednym miejscu – nie trzeba ich powielać po stronie frontu,
• szybki start i mniej kodu „klejącego” (klient HTTP, obsługa tokenów, stan globalny),
• łatwe przekazywanie uprawnień i komunikatów do widoków przez dane współdzielone.

Architektura B: osobne API i SPA

```
SPA (Vue/React) Aplikacja mobilna Partnerzy / integracje
↘ ↓ ↙
API (Laravel, tokeny lub sesja)
↕
Baza danych, kolejki, integracje
```

Mocne strony:

• jedno API obsługuje wielu klientów – web, mobile, integracje,
• frontend i backend mogą być rozwijane i wdrażane niezależnie,
• jasny kontrakt danych, który można testować i dokumentować (np. OpenAPI),
• łatwiej wymienić frontend na inną technologię bez ruszania backendu.

Koszty: trzeba zaprojektować i utrzymywać API, obsłużyć uwierzytelnianie (tokeny lub sesja z domeną i CORS), zarządzać stanem po stronie frontu i pilnować, żeby reguły uprawnień nie rozjechały się między warstwami.

Porównanie w pigułce

• Liczba klientów danych: Inertia – jeden frontend webowy; API + SPA – dowolna liczba.
• Zespół: Inertia – jeden zespół full-stack; API + SPA – możliwe osobne zespoły.
• Wdrożenia: Inertia – razem; API + SPA – niezależnie, ale z koniecznością zgodności wersji.
• Czas do pierwszej wersji: zwykle krótszy w Inertii.
• Integracje zewnętrzne: w Inertii wymagają dodatkowych tras API; w architekturze B są „za darmo”.
• SEO części publicznej: Inertia obsługuje renderowanie po stronie serwera (SSR) przez proces Node; SPA wymaga osobnego rozwiązania. Szerzej o frontendzie publicznym piszemy we wpisie frontend Vue.js dla systemu B2B.

Kiedy Inertia jest dobrym wyborem

• panel administracyjny lub back-office dla zespołu firmy,
• portal klienta, z którego korzysta się wyłącznie przez przeglądarkę,
• CRM lub system operacyjny rozwijany przez jeden zespół,
• MVP, które ma szybko trafić do użytkowników,
• projekty, w których większość złożoności leży w logice biznesowej, a nie w interfejsie.

Jak zaprojektować sam interfejs panelu z dużą ilością danych – tabele, filtry, formularze – opisujemy w artykule Vue.js frontend dla panelu administracyjnego B2B.

Ograniczenia Inertii, o których warto wiedzieć

1. Propsy są publiczne. Wszystko, co kontroler przekaże do komponentu, trafia do przeglądarki. Przekazanie całego modelu z polami wewnętrznymi to częsty błąd bezpieczeństwa. Dane trzeba świadomie wybierać i filtrować według uprawnień.
2. Brak API „przy okazji”. Trasy Inertii zwracają dane w formacie stron, a nie stabilny kontrakt dla integracji. Aplikacja mobilna czy partner potrzebują osobnych endpointów.
3. Ścisłe powiązanie wersji. Frontend i backend wdraża się razem. Inertia wykrywa zmianę wersji zasobów i przeładowuje stronę, ale nie da się utrzymywać kilku wersji frontu obok siebie.
4. Duże propsy spowalniają nawigację. Przekazywanie tysięcy rekordów przy każdym wejściu na stronę zamiast paginacji lub odroczonego ładowania szybko daje o sobie znać.
5. Bardzo interaktywne moduły – edytory, tablice planowania, praca w czasie rzeczywistym – i tak wymagają dodatkowych wywołań w tle lub websocketów.

Dobre praktyki w projekcie z Inertią

• buduj propsy przez klasy zasobów lub obiekty danych, a nie przez przekazywanie całych modeli,
• trzymaj logikę biznesową w klasach usług, a kontrolery ogranicz do przyjęcia żądania i zwrócenia strony,
• dane współdzielone (użytkownik, uprawnienia, komunikaty) ogranicz do minimum potrzebnego w każdym widoku,
• duże listy paginuj po stronie serwera, a ciężkie sekcje ładuj jako odroczone,
• typuj propsy w TypeScripcie, żeby zmiana po stronie backendu była widoczna w komponentach.

Architektura hybrydowa: Inertia plus API

W wielu systemach B2B najlepiej sprawdza się połączenie obu podejść: panel i portal działają przez Inertię, a obok istnieje wydzielone API z uwierzytelnianiem tokenem – dla integracji ERP, partnerów lub aplikacji mobilnej. Warunek: logika biznesowa (ceny, uprawnienia, statusy) jest w klasach usług, z których korzystają zarówno kontrolery Inertii, jak i kontrolery API. Wtedy nie ma dwóch wersji tych samych reguł. Architekturę backendu portalu z kontami firmowymi i uprawnieniami opisujemy w tekście Laravel jako backend dla portalu klienta.

Sygnały, że czas przejść na pełne API

• planujesz aplikację mobilną lub drugi frontend korzystający z tych samych danych,
• partnerzy potrzebują dostępu do większości funkcji panelu, a nie tylko kilku endpointów,
• frontend rozwija osobny zespół i wspólne wdrożenia zaczynają blokować pracę,
• chcesz wymienić lub przebudować interfejs bez ingerencji w backend.

Przejście nie musi oznaczać przepisania całości. Komponenty Vue w dużej mierze zostają, a zmienia się sposób pobierania danych. Im wcześniej propsy są budowane przez klasy zasobów zamiast ręcznie w kontrolerach, tym łatwiej wykorzystać je później w API.

Następny krok

Wypisz wszystkich obecnych i planowanych „konsumentów” danych Twojego systemu: panel dla zespołu, portal klienta, aplikację mobilną, integracje. Jeśli na liście jest tylko przeglądarka, Inertia prawdopodobnie wystarczy. Jeśli pozycji jest więcej, zaplanuj architekturę hybrydową. Chętnie pomożemy ją zaprojektować w ramach usługi tworzenie frontendu Vue.js – napisz do nas.