# 1. Podział aplikacji
Proces developmentu aplikacji headless został podzielony na kilka warstw, z czego dwie to warstwy frontendowe:
- UI - część odpowiedzialna za dostarczenie osobnego repozytorium/paczki z komponentami frontendowymi. Komponenty te nazywane są w świecie frontendu jako "dumb components" - tzn, że wyświetlają pewne dane i wyglądaja jak na projekcie graficznym, ale nie wiedzą skąd mają te dane pobrać. Dane do tych komponentów dostarczane są z zęwnatrz w formie atrybutów (props). Komponenty te nie wiedzą również nic o logice biznesowej, jedyna logika jaką zawierają to logika UI.
- Front - częśc odpowiedzialna za aplikację headless ta część jest odpowiedzialna za server side, routing, pobieranie danych z API oraz przekazywanie tych danych do komponentów UI. Repozytorium UI jest zainstalowane jako paczka
npm - Backend - część backendowa odpowiedzialna za API - stąd pobieramy informacje o stronach i ich elementach.
Taki podział pozwala nam na łatwiejsze wdrożenie nowego członka zespołu w projekt tzn, że:
- Nie musi instalować całego środowiska backendowgo aby zaczać pracę
- Nie potrzebuje znać specyficznych założeń platformy CMS ani jej systemu templatowania - wystarczy znajomość nowoczesnego frontendu - koncepcji komponentów, bibliotek UI - Vue.js/React itp.
- Czasami nie musi nawet znać projektu, aby poprawić np. wizualne aspekty komponentów UI.
# 1.1 Flow pracy
Poniższy schemat wizualizuje powyżej opisane podejście jako trzy różne ścieżki w których prace developerskie mogą być prowadzone niezależnie.
- Pierwsza ścieżka opisuje proces powstawania warstwy UI - od fazy projektowania po development oraz dokumentację (storybook)
- Druga ścieżka to aplikacja frontendowa, która wykorzystuje komponenty UI oraz zewnętrzne integracje oraz połączenie z backendową aplikacją headless w formie API.
- Trzecia ścieżka to aplikacja backendowa - w naszym przypadku TYPO3 która jest odpowiedzialna za logikę biznesową aplikacji oraz dostarczenie przejrzystego API.