done

[Cr3ativeCod3r]

Podejście do zadania i decyzje projektowe

1. Backend (Symfony)
   Backend zbudowałem w oparciu o prostą architekturę opartą na serwisach, żeby kod był czytelny i miał jasno podzielone odpowiedzialności.

• NbpClient – osobny serwis do komunikacji z API NBP. Dzięki temu łatwo to testować i w razie potrzeby wymienić źródło danych.
• ExchangeRateCalculator – tu trzymam całą logikę liczenia spreadów. Zmiana marż nie wymaga grzebania w innych miejscach.
• RateProvider – łączy wszystko w całość: pobiera dane, liczy kursy i korzysta z cache.
   

2. Wydajność (Caching)
   Wymagania mocno stawiały na wydajność, więc dodałem cache Symfony.
   Dane z NBP zapisuję na godzinę, dzięki czemu aplikacja działa szybko i nie obciąża API.
   Wybrałem zwykły cache plikowy, bo jest najprostszy, ale łatwo można go zastąpić np. Redisem.
    
3. Frontend (React)
   Na froncie zależało mi na czytelności i prostocie.

• Podzieliłem widoki na Dashboard (tabela kursów) i HistoryView (wykres).
• Do wykresu użyłem recharts, żeby od razu było widać trend.
• Nawigacja opiera się na react-router-dom, więc przejścia są płynne bez przeładowania strony.
   

4. Testy
   Przy kluczowej logice — czyli naliczaniu spreadów — zrobiłem testy jednostkowe, żeby mieć pewność, że wszystko liczy się poprawnie (np. inne marże dla EUR/USD, inne dla reszty).
   Feedback do zadania
   Zadanie było dobrze przygotowane — konkretne założenia biznesowe, ale technicznie dużo swobody.
   Plus za korzystanie z prawdziwego API NBP i wymóg pobierania historii z 14 dni, bo to zmusza do myślenia o wydajności.