Cześć!

Jest to pierwszy artykuł i nie ostatni o rozwiązaniach Headless dla sklepów i stron internetowych.

Czym jest framework Medusa.js?

W skrócie Medusa.js to framework do budowy sklepów internetowych o strukturze Headless gdzie Back-end jest oparty o Node.js oraz TypeScript. Natomiast Front-end może być zbudowany z czegokolwiek - bazowo Medusa.js wspiera Next.js ale bez problemu można wybrać Astro albo Nuxt.js.

Dlaczego wybraliśmy Medusa.js?

Wybraliśmy ten framework z kilku powodów. Pierwszym z nich jest to, że jest i pozostanie Open Source, mając już na starcie gotowe moduły.
Zespół Medusa.js wykonuje świetną robotę!

Drugim powodem jest to, że jest to rozwiązanie Headless, czyli back-end i front-end współpracują ze sobą, w niezależny sposób opierając się o REST-API.

Trzecim powodem to framework oparty o Node.js, w pełni otypowany i stworzony z myślą o modularności i elastyczności. Dla naszego zespołu było to ważne gdyż na co dzień pracujemy w technologiach opartych o Node.js, React.js, Next.js.

Jaki był powód?

Potrzebą było zbudowanie sklepu internetowego w którym można zrobić zakupy online jednocześnie łącząc zakupy w świecie offline.

Do obsługi Vendingów potrzebowaliśmy elastycznego i wydajnego rozwiązania. Istotna jest także modułowość która pozwoliło na:

• zarządzanie wieloma kanałami sprzedaży (jeden kanał sprzedaży odpowiada dokładnie jednej lokalizacji),

• podpięciem wybranej formy płatności,

• przedstawienia produktów które są dostępne, w sklepie przed zakupem,

• możliwością wyświetlenie użytkownikowi wcześniej zakupionych produktów w jego panelu po zalogowaniu (czy to w kanale online czy offline).

Architektura:

Vending posiada trzy tryby: zakupowy, zwrotowy i serwisowy.

1. Zakupowy - klient może kupić produkt znajdujący się w lodówce, biorąc go z konkretnej wagi.

2. Zwrotowy - klient może zwrócić pusty pojemnik po produkcie odkładając z powrotem na wagę.

3. Serwisowy - administrator może otworzyć urządzenie i np. uzupełnić magazyn, przypisać odpowiednie produkty do danej wagi czy też zrobić synchronizację produktów.

Dodatkowe rozwiązania technologiczne:

Dodatkowe rozwiązania które wdrożyliśmy:

• Firestore - między użytkownikiem, a back-endem do szybkiej wymiany danych,

• MQTT - między maszyną, a back-endem zastosowaliśmy lekki protokół komunikacyjny często używany w systemach IoT,

• Stripe - system do obsługi płatności

Jakie wdrożyliśmy funkcjonalności?

W naszym rozwiązaniu znalazło się kilka ciekawych funkcjonalności:

1. Sesje - potrzebowaliśmy jedno źródło prawdy dla sesji.
   W momencie gdy otwieramy urządzenie to musimy komunikować się z nim w trybie asynchronicznym. W bazie danych zapisujemy dane tj.

   1. ID sesji,

   2. ID urządzenia,

   3. ID hab’u,

   4. ID locker,

   5. Typ sesji,

   6. Aktualny kod,

   7. Tryb w jakim zostało otwarte urządzenie,

   8. ID użytkownika,

2. Podgląd sesji - administrator jest wstanie podejrzeć wszystkie obecne utworzone sesje. Jeśli wydarzyła się jakaś sytuacja i urządzenie nie wysłało do nas informacji o zamknięciu to możemy w tym miejscu to sprawdzić i zrobić analizę.

3. Włączanie i wyłączanie trybu serwisowego - administrator jest wstanie otworzyć urządzenie i zrobić w nim porządek czy też wymienić produkty.

4. Konfiguracja maszyn - dodaliśmy możliwość dodawania nowych urządzeń i przypisywania ich do danej lokalizacji. Dzięki temu, jeden back-end może odpowiadać za obsługę wielu Vendingów z jednego miejsca.

5. Przypisywanie produktów - produkty są przypisywane do konkretnej wagi których może być wiele. Każdy produkt oprócz danych podstawowych zawiera jeszcze np. minimalną i maksymalną wagę produktu.

6. Synchronizacja z urządzeniem - źródłem prawdy dla produktów jest moduł do zarządzania produktami w Medusa.js. Po przypisaniu produktów do wag, za pomocą jednego przycisku możemy zrobić synchronizację z urządzeniem.

7. Powiadomienia - za pomocą naszego pluginu do Automatyzacji i Notyfikacji wdrożyliśmy customowe notyfikacje informujące o stanie urządzenia. Na przykład gdy urządzenie wejdzie w tryb Offline, to administrator dostaje powiadomienie do komunikatora Slack, że coś się z nim dzieje. Dzięki temu bardzo szybko można zareagować.

Czego się nauczyliśmy?

Najważniejsza lekcja jest taka, że.. trzeba robić testy, i jeszcze raz testy. Maszyny są zawodne i nigdy nie wiesz co Cię może spotkać. Razem z zespołem odpowiedzialnym za software po stronie hardware’u, mieliśmy niezliczoną serię różnych edge-case’ów. Musieliśmy przewidzieć różne zachowania użytkownika, software’u i hardware’u.

Nie raz było tak, że drzwi powinny się otworzyć, a tu.. klops - sygnał został wysłany, jednak software po stronie hardware’u go nie wykrył.. albo wykrył ale aktualizacja się nie powiodła.

Innym przykładem jest to, że urządzenie wysyłało do nas informacje o zamkniętych drzwiach ale pojawił się trywialny błąd po stronie back-endu, i sesja się nie zamykała poprawnie. Tak samo było w drugą stronę, drzwi z jakiegoś powodu się nie zamknęły i sesja mogła nie zostać zamknięta.

Kolejną zagwozdką było pytanie - co jeśli maszyną ktoś szturchnie, sygnał zostanie wysłany czy nie zostanie?

To ile prób robiliśmy w przypadku kalibracji i nadawaniu wag, uWagom, aż ciężko policzyć.

Podsumowując

Było to dla nas bardzo ciekawe wyzwanie gdyż wcześniej nie mieliśmy okazji pracować w projektach w których potrzebą było komunikacja z systemami IoT, a to jest totalnie inne podejście gdyż tutaj nie moglibyśmy polegać na synchronicznych odpowiedziach tak, jak w przypadku standardowych rozwiązaniach webowych.

Medusa.js to bardzo elastyczne i modułowe rozwiązanie oparte na nowoczesnej technologii pozwalające na bardzo wiele zachowując przy tym jakość i szybkość działania.

Mam nadzieję, że artykuł się spodobał i dowiedziałeś się czegoś nowego o możliwościach jakie oferuje ten framework, a także jak podeszliśmy do rozwiązania problemów.