Jak zamockować usłguę na miesiąc

Hej

Robię sobie własny projekt - klona Allegro. Na razie mam mirkoserwis z userami, potrzebuję aby w tym serwisie mi strzelało po listę z produktami usera.
Nie mam jeszcze mikroserwisu z produktami, potrzebuję na jakiś miesiąc zrobić sobie mocka danych i zwracać dane z niego.

Jest jakiś wzorzec jak to robić? Jakaś biblioteka ułatwiająca to?
Że w sensie mam endpoint /users/{id}/products, jest serwis który będzie potem strzelał po te produkty, ale na razie ma czytać z jakieś listy np. z JSONa albo YAMLa.

To ważne chcę wystartować w nowym roku, a mnie to blokuje

Użyć mocka zewnętrznego, albo napisać samemu prosty serwer.

Co to znaczy użyć mocka zewnętrznego?

Zamockuj usługę na zawsze - a po miesiącu wyłącz. Simple as f... :)

Robisz np. porty i adaptery i zamiast realnej implementacji portu w której będzie docelowo klient http do komunikacji z innym serwisem robisz implementację in memory.

Btw pamiętaj, że monolith first ;)

Jak dam Wam link do projektu na GitHubie, to zrobicie pull requesta?

napisz sobie w implementacji jakiś proxy, który w zależności np od jakiegoś configu albo braku np bazy pod spodem czy coś zwraca ci proxy w miejsce prawidziwych danych i tyle

mi za pull requesty płacą :P A na poważnie to ports and adapters to niejako całą architektura więc musiałbym Ci pół aplikacji przepisać.

Jeżeli nie chcesz tak daleko idących zmian to idź na skróty: w aplikacji zamiast konfigurować bean springowy z realnym klientem http (masz do niego interfejs prawda?) zrób drugą implementację in memory bez żadnej komunikacji po sieci. Tylko tyle...

A czemu akurat na miesiąc?

Kolejny, który myśli że umie pisać mikroserwisy.

Możesz postawić jakiegoś gotowca jak wiremock, możesz napisać ad hoc serwis w jakimkolwiek języku przy użyciu prostego frameworka HTTP. Wybacz, ale to są proste sprawy i jak tego nie ogarniasz to i pewnie z mikroserwisami będzie problem. Jak chcesz szybkiego rozwiązania to napisz wszystko w jednym serwisie. Mikroserwisy przydają się, gdy:

• są jakieś przesłanki techniczne np. słaba wydajność jakiegoś kawałka kodu, który zabija wydajność czegoś zupełnie niezwiązanego albo możliwość pisania różnych części systemu w różnych technologiach
• organizacyjne: masz mnóstwo ludzi i chcesz, żeby każdy mógł rozwijać swoje poletko z dużą niezależnością

Klepiąc klona allegro w pojedynkę te problemy cię nie dotyczą

Podpowiem, że mikroserwis z userami to antypattern

Zrób sobie monolit a potem myśl o rozbijaniu na "microserwisy".
Jak będziesz w przyszłości widział trend, że pewna część funkcjonalności potencjalnie będzie zażynać bazę (bo to zazwyczaj brak skalowalności bazy będzie problemem) albo potrzebuje innego podejścia do danych, to to wtedy sobie zrobisz migrację interesującej Cię części danych do nowej bazy / mikroserwisu.

Hinty:

• jeśli rozwiązanie robisz na relacyjnej bazie danych, to nie rób PK/FK constraintów (bo rozumiem, że zakładasz, że projekt Ci tak urośnie, że data integrity nie będziesz w stanie utrzymać bo będziesz miał kiedyś wiele data source'ów)
• projektuj moduły/dane tak, żeby można je było w miarę łatwo wynieść do osobnego serwisu

W ten sposób będziesz miał projekt, który jest tani w utrzymaniu (zużywa mało zasobów, czasu developmentu, nie trzeba pilnować update dependencies pierdyliarda repo etc...)

Fakt, modularny monolit dobrze jest umieć robić i o ile w pracy bym się tym kierował o tyle sam prywatnie również mam aplikacje które celowo są wydzielane do mikroserwisów (działa sobie w obrębie sieci lokalnej) tylko po to by ćwiczyć/testować technologie dedykowane stricte mikroserwisom (np. resilience4j, współdzielony między instancjami cache itp).

W pracy oraz prywatnym projekcie korzystam z WireMock i sprawdza się bardzo fajnie. Klient jest oddzielnym beanem, przyjmuje kolejny bean, który jest Springowym ConfigurationProperties, który zawiera url serwisu. Na produkcji mamy poprawne adresy serwisów, a do testów profil testowy z propertiesami, które jako url podają wiremocka. No i później trzeba sobie zamockować response, albo w oddzielnym pliku albo bezpośrednio w kodzie. Wygodne i szybkie rozwiązanie.