Solid Apps

Portfolio projektowe / PHP Backend / Systemy B2B

Projektuję backendy PHP, które łączą czystą architekturę z gotowością produkcyjną.

Solid Apps pokazuje sposób myślenia o systemach: kontrakty API, warstwa aplikacyjna, idempotencja, testy, observability, DDD tam, gdzie pomaga, i pragmatyczny modularny monolit zanim ktokolwiek zacznie mnożyć mikroserwisy.

Zobacz case studies Zobacz decyzje techniczne
Model
JDG / B2B / zdalnie
Specjalizacja
PHP 8.3+, API, integracje, system design
Repo
github.com/matii-dev
Najkrótsza wersja portfolio

Solid Apps to portfolio backendowe budowane wokół realnych decyzji inżynieryjnych: status transitions, idempotencja, podpisy webhooków, test strategy, C4/NFR/ADR i runbook.

Co najlepiej obejrzeć najpierw

Zacznij od ShopFlow, Payment Adapter, Rentals Booking, CLI Data Importer i URL Shortener. To projekty, które pokazują nie tylko kod, ale też granice odpowiedzialności i trade-offy.

Pozycjonowanie

Nie lista technologii. Zestaw problemów, które backend musi dowieźć.

01

API i kontrakty

REST API, OpenAPI, DTO, Problem Details, paginacja, 401/403/422/429, wersjonowanie i czytelne granice odpowiedzialności.

02

Integracje i płatności

Webhooki HMAC, idempotency key, retry z backoff i jitter, audit log, refundy oraz projektowanie failure modes.

03

Ratowanie legacy

Audyt SQL, EXPLAIN, indeksy, plan refaktoryzacji, service layer, testy charakterystyki i stopniowe podnoszenie PHPStan.

04

System design

C4, NFR, ADR, capacity estimate, cache invalidation, health checks, runbook i decyzje o modularnym monolicie vs mikroserwisy.

Wybrane projekty

Projekty, które pokazują sposób projektowania backendu.

Każdy wpis łączy problem, decyzje techniczne, zakres demo i świadome następne kroki. To nie jest galeria screenów, tylko mapa dowodów kompetencji.

22 projekty widoczne

Brak projektu dla wybranych filtrów. Zmień zapytanie albo kategorie.

Stack i standardy

Technologie ułożone według odpowiedzialności, nie według popularności.

Runtime i framework

PHP 8.3 / 8.4 / 8.5, Symfony, Laravel, Composer, PSR-4, service container, Scheduler, Messenger.

Dane i przepływy

Doctrine, Eloquent, PDO, MySQL, PostgreSQL, Redis, RabbitMQ, outbox awareness, CSV/JSON imports.

API i auth

REST, OpenAPI, JWT, OAuth 2.0, OIDC, RBAC/ACL, HttpOnly cookies, webhook signature verification.

Jakość

PHPUnit, Pest, PHPStan, Psalm, php-cs-fixer, contract tests, smoke tests, test strategy matrix.

Produkcja

Docker, Docker Compose, Nginx, PHP-FPM, GitHub Actions, Sentry, OpenTelemetry, structured logs.

Architektura

Modular monolith, DDD tactical, Clean/Hexagonal, C4, NFR, ADR, runbook i failure mode analysis.

Decyzje techniczne

Miejsca, w których projekt backendowy zwykle wygrywa albo robi dług.

Kontrakt API

Jak zaprojektować endpoint, żeby nie ukryć kontraktu w kontrolerze?

Zacznij od OpenAPI, request/response DTO, jawnego error formatu i statusów 401/403/422/429. Dopiero potem kontroler jako cienka warstwa delegująca do application service.

  • Jak wygląda walidacja 422 i mapowanie błędów?
  • Gdzie trzymasz retry i idempotency key?
  • Jak zapewniasz zgodność frontend-backend bez zgadywania?

Sposób pracy

Wejście w projekt bez chaosu, dostarczenie bez zgadywania.

Pracuję tak, żeby po każdej iteracji został nie tylko kod, ale też decyzje, kontrakty, testy i kontekst potrzebny zespołowi do dalszego utrzymania systemu.

Zasada: najpierw ryzyko i granice odpowiedzialności, potem implementacja.
  1. 01

    Problem discovery

    Ustalam, co realnie boli: endpoint, integracja, SQL, checkout, kolejka, flow legacy albo brak właściciela obszaru.

    Output: mapa ryzyk, scope pierwszej iteracji, out of scope.
  2. 02

    Kontrakt i plan techniczny

    Opisuję granice modułów, DTO, statusy HTTP, idempotencję, retry policy i decyzje architektoniczne.

    Output: OpenAPI / ADR / mini C4 / test strategy.
  3. 03

    Implementacja z kryteriami jakości

    Małe zmiany, czytelne commity, testy, PHPStan/Psalm, php-cs-fixer i review miejsc o najwyższym ryzyku.

    Output: działający flow, testy, notatki trade-offów.
  4. 04

    Delivery i przekazanie kontekstu

    Domykam README, smoke testy, endpointy health, runbook, notatki wdrożeniowe i listę kolejnych ryzyk.

    Output: kod gotowy do review oraz dokumentacja dla zespołu.
Quality gate przed uznaniem pracy za zakończoną
  • czy flow ma test albo jasny scenariusz demo?
  • czy błąd ma przewidywalny status i komunikat?
  • czy retry, webhook albo job jest idempotentny?
  • czy następna osoba zrozumie decyzje z README/ADR?

Artefakty

To, co warto zobaczyć poza samym kodem.

Portfolio jest projektowane tak, żeby pokazać nie tylko składnię PHP, ale też dojrzałość decyzji: jak opisany jest system, gdzie są granice, co jest out of scope i jakie ryzyka zostały nazwane.

README cel, uruchomienie, demo flow, trade-offy
ADR dlaczego modularny monolit, gdzie cache, kiedy kolejka
C4 / NFR granice systemu, wymagania niefunkcjonalne, failure modes
Runbook endpointy health, smoke testy, notatki wdrożeniowe, świadomość rollbacku
Solid Apps

Porozmawiajmy technicznie.

Najlepszy format startu: wybierz jeden projekt albo problem w swoim systemie, a ja przejdę przez decyzje, trade-offy i pierwsze ryzyka, które warto domknąć.

GitHub matii-dev kontakt@solidapps.pl

NDA na życzenie · faktura VAT · praca zdalna · B2B · retainer lub projekt