Rozwój full-stack
W Atomic Concept rozwijamy backend, frontend i integracje jako części jednego systemu. Zakres współpracy może obejmować nowy moduł, rozbudowę istniejącej aplikacji lub utrzymanie produktu. Poniżej opisujemy technologie i praktyki inżynierskie, które wykorzystujemy w tej pracy.
Zakres prac i technologie
Backend, frontend i integracje w jednym projekcie.
Prace obejmują logikę serwerową, modele danych, interfejsy użytkownika oraz połączenia z usługami zewnętrznymi. Możemy rozwijać wybrany obszar produktu albo przeprowadzić zmianę przez wszystkie warstwy aplikacji. W istniejącym projekcie najpierw sprawdzamy jego architekturę, kontrakty i sposób publikowania wersji.
| Obszar | Technologie i praktyki |
|---|---|
| Backend | Node.js, TypeScript, REST API, Zod, zadania asynchroniczne i webhooki. |
| Dane | PostgreSQL, SQL, Prisma, transakcje i migracje schematu. |
| Frontend | React, Next.js, TanStack Query, MUI, responsywność i Core Web Vitals. |
| Integracje | Stripe, Shopify, OAuth 2.0, uwierzytelnianie, autoryzacja i klucze API. |
| AI | Integracje modeli, odpowiedzi według schematu, MCP, obsługa błędów dostawców i kontrola kosztów. |
| Testy i wdrożenia | Vitest, Playwright, GitHub Actions, Docker, Vercel, Cloudflare, logi i monitoring. |
Architektura i niezawodność
Jawne kontrakty danych i kontrola skutków operacji.
Moduły aplikacji dzielimy według odpowiedzialności i procesów biznesowych. W większych systemach wykorzystujemy DDD oraz rozdzielenie operacji zapisu i odczytu, czyli CQRS. Nie każdy projekt wymaga takiego podziału. Istotne jest, aby granice modułów były zrozumiałe, a zmiana jednego obszaru nie wymuszała przypadkowych zmian w pozostałych.
Wspólne kontrakty TypeScript i schematy Zod opisują wejścia i odpowiedzi API. Typy danych przekazywanych między warstwami (DTO) możemy generować ze schematu Prisma, a zgodność walidacji i odpowiedzi sprawdzać podczas kompilacji i w CI. Walidacja danych przychodzących pozostaje potrzebna także wtedy, gdy frontend i backend używają tych samych typów.
Integracje uwzględniają ponowienia, duplikaty i częściowe awarie. Webhook płatności nie powinien ponownie naliczyć tej samej operacji. Zmiany powiązanych danych obejmujemy transakcją, a wysyłkę wiadomości i inne skutki zewnętrzne planujemy po jej zatwierdzeniu. Zadania działające w tle wymagają kontroli wykonania, historii błędów i sposobu wznowienia.
Od zmiany w kodzie do wdrożenia
Przegląd, testy i sprawdzenie działającej wersji.
Przed realizacją ustalamy zachowanie funkcji i sposób weryfikacji. Zmiany przechodzą kontrolę typów, code review i testy dobrane do ryzyka: jednostkowe, integracyjne lub e2e. Sprawdzamy również uprawnienia, niepoprawne dane, zachowanie formularzy i skutki nieudanego żądania.
Proces publikacji obejmuje konfigurację środowiska, sprawdzenie migracji, wdrożenie i weryfikację działającej wersji. Uzgadniamy sposób wycofania zmiany oraz obserwacji błędów po publikacji. Logi powinny pozwalać powiązać problem z operacją, środowiskiem i wersją aplikacji.
W pracy z agentami kodującymi zadania, kontekst i granice zmian są określone z góry. Wygenerowany kod podlega takim samym przeglądom i testom jak pozostałe zmiany. Współpraca B2B może dotyczyć samodzielnego zadania, rozwoju modułu lub stałego wsparcia technicznego produktu. Aby ustalić zakres, opisz obecny system, potrzebną zmianę i istotne ograniczenia techniczne.