Wersja pokazowa: dental.arturmrowicki.pl · Kod źródłowy: GitHub
Łatwy kalendarz, trudne sytuacje graniczne
Rezerwacja wizyty wygląda prosto: pacjent wybiera lekarza, godzinę i płaci. Trudność pojawia się wtedy, gdy dwie osoby klikają ostatni wolny termin niemal jednocześnie albo gdy potwierdzenie płatności dociera z opóźnieniem.
Zbudowałem ten projekt jako wersję pokazową dla kilku niezależnych gabinetów. Każda placówka ma własny kalendarz i widzi wyłącznie swoich pacjentów. Płatności działają w trybie testowym, więc demonstracja nie pobiera prawdziwych pieniędzy.
Cztery rzeczy, których nie można zostawić przypadkowi
- Ten sam termin. Dwie osoby nie mogą dostać potwierdzenia tej samej wizyty.
- Dane placówek. Gabinet A nie może zobaczyć pacjentów gabinetu B.
- Kolejność płatności. Pacjent nie powinien płacić za godzinę, której system nie zabezpieczył.
- Aktualny kalendarz. Zajęta godzina powinna zniknąć także u osoby, która ma już otwartą stronę.
Jak system tego pilnuje
Ostatnie słowo ma baza danych
To nie ekran decyduje, czy godzina jest wolna. Baza danych pozwala utworzyć tylko jedną aktywną rezerwację dla danego lekarza i czasu. Jeśli dwa zgłoszenia przyjdą równocześnie, pierwsze zajmuje termin, a drugie dostaje czytelną informację, że ktoś właśnie je uprzedził.
Każdy gabinet pozostaje w swoim obszarze
Ograniczenie dostępu jest zapisane przy samych danych, a nie tylko w widoku strony. Nawet błędne zapytanie aplikacji nie powinno zwrócić pracownikowi rekordów innej placówki. Pacjent może umówić wizytę bez zakładania konta, ale nie otrzymuje bezpośredniego dostępu do bazy.
Najpierw termin, potem przejście do płatności
System na 15 minut blokuje wybraną godzinę, a dopiero później otwiera stronę płatności. Powtórzone potwierdzenie od operatora płatności nie tworzy drugiej wizyty ani nie zmienia jej ponownie. Jeżeli wiadomość dotrze po wygaśnięciu blokady, zdarzenie zostaje zapisane do obsługi zwrotu.
Kalendarz zmienia się bez przeładowania
Gdy ktoś zajmie termin, znika on z ekranów innych osób oglądających kalendarz tego samego lekarza. Nie trzeba ręcznie odświeżać strony.
Jak sprawdziłem pełną ścieżkę
Automatyczna próba tworzy rezerwację w działającej wersji pokazowej, odrzuca drugą próbę na tę samą godzinę, rozpoczyna płatność, przyjmuje podpisane potwierdzenie i wysyła je ponownie, aby upewnić się, że nic nie zostanie naliczone dwa razy. Wszystkie 9 sprawdzanych kroków zakończyło się poprawnie.
Sprawdź sam
Wersja działa w trybie testowym i nie pobiera prawdziwych opłat:
- wybierz klinikę i wolny termin na stronie demonstracyjnej,
- użyj testowej karty Stripe
4242 4242 4242 4242, dowolnej przyszłej daty i dowolnego kodu CVC, - otwórz ten sam kalendarz w dwóch oknach i zobacz, jak zajęta godzina znika w drugim.
Co jest gotowe, a co wymagałoby dalszej pracy
Gotowy jest rdzeń rezerwacji, oddzielenie placówek, testowa płatność i aktualizowanie kalendarza. Przed użyciem w konkretnej sieci trzeba byłoby dopasować grafiki lekarzy, zasady anulowania, automatyczne zwroty, treść zgód oraz sposób przetwarzania danych medycznych. Wersja pokazowa nie udaje gotowego produktu dla każdej kliniki.
Dla zainteresowanych technicznie
Projekt korzysta z Next.js, bazy PostgreSQL udostępnionej przez Supabase oraz płatności testowych Stripe. Ograniczenie jednej rezerwacji i podział danych między placówki są wymuszane w bazie, dzięki czemu nie zależą wyłącznie od poprawności kodu ekranu.