Wpis z mikrobloga

@Garg84: w miejscu komunikacji z API zamiast do niego strzelać zwracasz dane fakeowe. Jeśli ci zależy na jakimś automatycznym przełączaniu to możesz zrobić mechanizm fallbacka w przypadku braku możliwości wywołania API zwracasz dane wymyślone.
@Garg84: mokuj sobie api poprzez json-sever, jak będziesz miał dokładne kontrakty to tylko sobie swoje to sobie pozmieniasz. Dzięki temu bedziesz mógł od razu na gotowo robić. Zresztą dobrze mieć zamokowane api i być niezależnym od tego backendowego.
@kochmap: jak to w testach? mokowanie api np poprzez json-server nie ma nic wspólnego z mokowaniem w testach. Napisał, że cześć funkcjonalności nie ma API.
@kochmap: zamokowanie poprzez json-server wystawia ci prawidzwe endpointy restowe np pod localhost:3000/api, dzięki temu symulujesz pracę z prawdziwym api i konsumujesz dane JSON a na jakieś plain objects w JS.
Dzięki temu również:
- jesteś uniezależniony od prawdziwego BE (niech no padną serwery)
- łatwiejsze sprawdzenie przypadków brzegowych
- szybsze odswieżanie zmian, bo nie łączysz się z prawdziwym serwerem tylko z localhostem, wszystko szybko śmiga
- możliwość robienia tiketów na gotowo
@kochmap: jak to w testach? mokowanie api np poprzez json-server nie ma nic wspólnego z mokowaniem w testach.


@mcsQ: tak masz rację, chodziło mi o to ale napisałem co innego. W skrócie uruchomiona aplikacja z mockowanym backendem.

@kochmap: zamokowanie poprzez json-server wystawia ci prawidzwe endpointy restowe np pod localhost:3000/api, dzięki temu symulujesz pracę z prawdziwym api i konsumujesz dane JSON a na jakieś plain objects w JS.

Dzięki temu