🚀 Flagship Project

StayMap Polska

Full-stackowa platforma rezerwacji noclegów w Polsce z podejściem map-first, AI search po polsku i komunikacją real-time.

modułów Django

widoków Next.js

plików testów

trybów podróży

Live Demo GitHub Swagger API

Django 5Django REST FrameworkPostGISGeoDjangoRedisCeleryChannelsDaphneNext.js 14TypeScriptWebSocketOpenAIGoogle OAuthpytestDockerGitHub Actions

DEMO

Produkt w praktyce

Najważniejsze widoki projektu, które pokazują map-first search, proces rezerwacji, panel hosta i komunikację real-time.

Co możesz sprawdzić w demo

wyszukiwanie noclegów na mapie

filtrowanie ofert

tryby podróży

panel hosta

proces rezerwacji

AI search po polsku

real-time chat

dokumentację Swagger/OpenAPI

GENEZA

Problem produktowy

StayMap powstał jako odpowiedź na problem wyszukiwania noclegów, w którym lokalizacja, cena, dostępność i potrzeby użytkownika często są rozproszone między różnymi ekranami i filtrami.

Mapa jako główny interfejs

W wielu serwisach mapa jest dodatkiem do listy wyników. W StayMap lokalizacja jest punktem wyjścia — użytkownik odkrywa oferty bezpośrednio na mapie.

Ceny bez kontekstu sezonowości

Cena noclegu zależy od terminu, długości pobytu, sezonu, świąt i liczby gości. Dynamic pricing engine uwzględnia te reguły w jednym procesie.

Rozproszona ścieżka użytkownika

Gość, host i administrator często działają w osobnych procesach. StayMap łączy wyszukiwanie, rezerwację, komunikację, panel hosta i moderację w jednym systemie.

ZAKRES

Moja rola w projekcie

Projekt indywidualny — zaprojektowałem i zbudowałem całość samodzielnie: backend, API, model danych, logikę biznesową, integracje, frontend oraz wdrożenie demo.

Architektura backendu

Zaprojektowałem strukturę 12 modułów Django, relacje między modelami, system uprawnień oraz lifecycle rezerwacji.

REST API + WebSocket

Zbudowałem 47 endpointów DRF z dokumentacją Swagger/OpenAPI oraz warstwę ASGI z Daphne obsługującą jednocześnie REST i WebSocket.

Dane i geolokalizacja

Zaprojektowałem schemat bazy PostgreSQL/PostGIS, zapytania przestrzenne, indeksy geograficzne oraz wyszukiwanie ofert po lokalizacji.

Async tasks i integracje

Dodałem zadania Celery, Redis w kilku rolach, integrację OpenAI, Google OAuth, mailing transakcyjny oraz zewnętrzne źródła danych lokalizacyjnych.

DESIGN

Architektura systemu

Architektura została podzielona na warstwy: frontend Next.js, backend Django/DRF, komunikację WebSocket przez Channels, bazę PostgreSQL/PostGIS oraz zadania asynchroniczne Celery.

Client

Przeglądarka i urządzenia mobilne użytkowników.

BrowserMobileGuestHost

Frontend

Interfejs użytkownika, routing, widoki i warstwa BFF proxy.

Next.js 14SSR/CSRBFF proxyTypeScript

API Layer

REST API, logika biznesowa, autoryzacja i dokumentacja kontraktu API.

Django 5DRFSwagger/OpenAPIJWT

Real-time

Komunikacja WebSocket dla czatu i statusów w czasie rzeczywistym.

Django ChannelsDaphne ASGIWebSocketEvents

Data & Geo

Model danych, rezerwacje, lokalizacja i zapytania przestrzenne.

PostgreSQLPostGISGeoDjangoSpatial indexes

Async & Integrations

Zadania w tle, cache, AI search i integracje zewnętrzne.

RedisCeleryOpenAIGoogle OAuthNominatimOverpass

Dlaczego taka architektura?

BFF proxy w Next.js

Frontend nie komunikuje się bezpośrednio z backendem. Warstwa proxy ułatwia kontrolę requestów, auth i strukturę API.

ASGI dla REST + WebSocket

Daphne pozwala obsłużyć standardowe requesty HTTP oraz real-time chat w jednej architekturze aplikacji.

PostGIS dla wyszukiwania po lokalizacji

Lokalizacja jest głównym elementem produktu, dlatego zapytania przestrzenne są częścią modelu danych, a nie dodatkiem.

Redis w kilku rolach

Redis obsługuje cache, brokera Celery i channel layer dla WebSocketów, ale logicznie rozdziela odpowiedzialności.

Pokaż techniczny diagram ASCII

┌─────────────────────────────────────────┐
│         Przeglądarka / Mobile           │
└──────────────┬──────────────────────────┘
               │ HTTPS
┌──────────────▼──────────────────────────┐
│     Next.js 14  (SSR + CSR + BFF)       │
│     /api/v1/[...path] → proxy           │
└──────────┬───────────────┬──────────────┘
           │ HTTP REST      │ WebSocket
┌──────────▼───────────────▼──────────────┐
│         Daphne ASGI Server              │
│   Django REST Framework  │  Channels    │
└──────────┬───────────────┬──────────────┘
           │               │
┌──────────▼───────┐  ┌────▼─────────────┐
│  PostgreSQL 16   │  │    Redis 7        │
│  + PostGIS 3.4   │  │  cache/broker/   │
│                  │  │  channel layer   │
└──────────────────┘  └────┬─────────────┘
                           │
                    ┌──────▼──────────────┐
                    │   Celery Worker     │
                    │   + Beat (cron)     │
                    └─────────────────────┘

FUNKCJE

Kluczowe funkcje techniczne

Map-first UX + PostGIS

Geowyszukiwanie noclegów przez GeoDjango i PostGIS 3.4. Zapytania przestrzenne, filtrowanie po odległości, ranking ofert według lokalizacji oraz integracja z Nominatim i Overpass API.

Dynamic Pricing Engine

Wielowarstwowy silnik cenowy: sezony, polskie święta, weekendy, dopłaty za gości i rabaty long-stay. Cena jest zapisywana jako snapshot w momencie rezerwacji.

AI Search po polsku

OpenAI API interpretuje zapytania użytkownika w języku polskim i mapuje intencję na filtry wyszukiwarki. Sesje AI mają TTL oraz limity kosztowe.

Real-time Chat

Django Channels + Daphne ASGI. WebSocket eventy: message.new, typing.start, typing.stop, message.read. Autoryzacja połączenia oparta o JWT.

Blind Reviews

Recenzje są publikowane dopiero wtedy, gdy obie strony — gość i host — dodadzą swoją opinię. Ogranicza to wpływ jednej recenzji na drugą i zwiększa uczciwość procesu.

Auth + Security

JWT z rotacją tokenów i HTTP-only cookies, Google OAuth, walidacja uploadów oraz rate limiting dla AI, auth i uploadów.

WYZWANIA

Najtrudniejsze problemy do rozwiązania

Miejsca, w których projekt wymagał prawdziwych decyzji technicznych.

Redis w 3 rolach

Redis musi działać jako cache aplikacji, broker wiadomości Celery i channel layer dla Django Channels — wszystko jednocześnie, z odpowiednią konfiguracją baz danych Redis żeby nie mieszać danych.

Osobne bazy Redis: db=0 dla cache, db=1 dla Celery, db=2 dla Channels. Docker Compose z health checks zapewnia, że Redis startuje przed aplikacją.

ASGI + WSGI

Przejście z WSGI (Gunicorn) na ASGI (Daphne) wymagało zrozumienia jak routing żądań HTTP i WebSocket działa jednocześnie w jednym procesie.

Konfiguracja asgi.py z URLRouter dla Channels i Django WSGI wrapper dla standardowych requestów. Daphne jako główny serwer aplikacji.

Dynamic pricing

Wiele reguł cenowych może nakładać się na ten sam termin (sezon + święto + weekend + long-stay). Kolejność aplikowania reguł wpływa na finalną cenę.

System priorytetów reguł z jawnie zdefiniowaną kolejnością: base → season → holiday → extra guests → long-stay discount. Snapshot ceny zapisywany atomowo przy tworzeniu rezerwacji.

WNIOSKI

Czego się nauczyłem

Architektura ASGI vs WSGI i kiedy używać każdej z nich

Zapytania geospatial z PostGIS — od teorii do indeksów przestrzennych

Wzorzec BFF w Next.js jako proxy layer między frontendem a API

Zarządzanie złożonym stanem rezerwacji, deadline’ami i lifecycle

Redis jako wielofunkcyjne narzędzie — cache, broker i channel layer

Monitoring błędów, structured logging i myślenie o obserwowalności aplikacji

ROADMAP

Planowane rozszerzenia produktu

Funkcje, które naturalnie rozwijają StayMap w stronę bardziej kompletnego produktu turystycznego.

AI 'Kiedy jechać?' — rekomendacja terminuIzochrony — wyszukiwanie po czasie dojazduStripe — płatności onlinePamiętnik podróży — zdjęcia po pobycie

Zaciekawił Cię ten projekt?

Chętnie opowiem więcej o decyzjach technicznych, architekturze i problemach, które rozwiązałem podczas budowy.

Napisz do mnie Zobacz drugi projekt →

Następny projekt

PRO-KOM Serwis System