2. Agenda:
● Coś o mnie…
● Podejście standardowe -
czyli jak to robiliśmy kiedyś
● Podejście zrównoleglone -
czyli jak to robimy teraz
● Narzędzia które nam w tym pomagają
● Case study
● Podsumowanie
3. Coś o mnie...
● Od ponad dekady twórca aplikacji
webowych
● Uzależniony od czystego kodu
● Lider techniczny w Codesushi
● CodeReviewer z zamiłowania
● Filozof i Developer w jednym…
i co gorsza jest to udokumentowane dwoma dyplomami
4. Podejście standardowe:
1. User stories
2. Rozpisanie Endpointów
3. Implementacja Endpointów
4. Przekazanie udokumentowanych
Endpointów do FrontEndu
5. Prace Frontowe
6. …
7. Profit
5. Podejście zrównoleglone:
1. User stories
2. FrontEnd i BackEnd wspólnie ustalają
Endpointy - powstaje kontrakt
3. Tworzymy Mock Api
4. FrontEnd i BackEnd zaczynają pracę
równocześnie
5. W miarę postępu w Api, FrontEnd
przepinia Endpointy z Mock Api na “żywe” Api
6. …
7. Profit
6. Narzędzia których używamy: Apiary
● Używamy gdy FrontEnd i BackEnd mogą wystartować
równocześnie, lub BackEnd ma opóźniony start
● Zalety
○ Bogate możliwości dokumentowania
○ Dokumentacja i Mock Api w jednym
○ Mock Api nie wymaga dodatkowego setupu
● Wady
○ Konieczność nauczenia się nowego narzędzia
○ Konieczność przepinania frontu
7.
8. Narzędzia których używamy: Symfony + bundle
● Symfony + FOSRestBundle + NelmioAPIDocBundle
○ Używamy gdy FrontEnd startuje z opóźnieniem
○ Backend zwraca na sztywno dane [czasem przydaje się: Faker]
● Zalety
○ Dokumentacja i kod w jednym miejscu
○ Autogeneracja Swaggera + Webowy klient to testowania Api
○ Brak konieczności podmiany Endpointa
● Wady
○ Konieczne jest zaangażowanie developera
○ Dłuższy start projektu
○ Zmiana w Mock Api wymaga zaangażowania BackEndowca
9. Narzędzia których używamy: Json-server
● Json-server (https://github.com/typicode/json-server)
○ Używamy w momencie gdy FrontEnd rozpoczyna pracę jako pierwszy
○ Prosty server który zwraca pliki json
● Zalety
○ Prostota
○ Mock Api może być wersjonowane wraz z projektem
○ Każdy developer może dokonać poprawek
● Wady
○ Wymaga zaangażowania developera do zmiany Mock Api
○ Oferuje tylko Mock Api, o dokumentację trzeba zadbać osobno
○ Zmiany w kontrakcie mogą pozostać niezauważone
10. Case study:
● Projekt dotyczył zbudowania od nowa mechanizmu zamawiania obozów sportowych
● Zespół
○ 1x BackEnd od klienta
○ 1.5x BackEnd Codesushi
○ 1x FrontEnd Codesushi
● Poprzednia wersja z mniejszą ilością funkcjonalności powstała w 12 miesięcy, a
wersja przy której pracowaliśmy powstała w 3 miesiące
● FrontEnd: Angular 1.5.11
● BackEnd: Symfony 2.8
● Apiary zostało wykorzystane w pierwszym etapie projektu
● W późniejszym etapie wykorzystaliśmy: Symfony + bundle
11. Równoległy rozwój Aplikacji
Webowych - Podsumowanie:
● Umożliwia atak na wielu frontach
● Developerzy działają w oparciu o kontrakt - co daje większą
swobodę w planowaniu
● FrontEnd nie jest blokowany przez BackEnd
● Zastosowanie jedynie wtedy gdy możemy całkowicie odseparować
FrontEnd od BackEndu (Angular, Ember, Backbone, React)
● Doskonale nadaje się do tworzenia Minimum Viable Product [MVP]
12. Dziękuję za uwagę :)
e-mail: hello@codesushi.co
www: codesushi.coKrzysztof Ożóg
Codesushi CTO