Ranking najlepszych kont firmowych: konta-dla-firm.pl
Opis projektu na GitHub: Konta-dla-Firm.pl: Architecture Blueprint
W świecie webu łatwo zauważyć pewien schemat: nawet proste projekty z czasem obrastają warstwami. Framework na frameworku, kilka systemów analitycznych, rozbudowane buildy, zależności, które żyją własnym życiem. W pewnym momencie więcej energii idzie w utrzymanie infrastruktury niż w sam produkt.
Chciałem sprawdzić, jak daleko da się dojść, idąc w dokładnie przeciwną stronę — bez owijania wszystkiego w struktury, które niewiele wnoszą.
Tak powstał serwis konta-dla-firm.pl. Projekt hobbystyczny, techniczny eksperyment i jednocześnie bardzo praktyczny przykład tego, że lekkość, automatyzacja i prostota naprawdę mogą iść w parze.
Skąd wziął się pomysł
Przeglądając istniejące porównywarki kont firmowych, szybko zauważyłem powtarzalny zestaw problemów: ciężkie skrypty, wolne ładowanie, agresywne reklamy i popupy z długą listą „partnerów” do zgód cookie.
Znając rynek finansowy oraz techniczne aspekty porównywarek wiedziałem, że logika takiej strony jest znacznie prostsza, niż sugeruje cała otoczka.
Pomyślałem więc: a co, gdyby zrobić to jak statyczny serwis — ale z danymi zawsze aktualnymi? Bez paneli, bez analityki i bez infrastruktury, którą trzeba potem utrzymywać.
Prosta architektura i pełna automatyzacja
Cały projekt od początku był projektowany z myślą o prostocie i przewidywalności. Backend jest tak lekki, jak się da — jego główną rolą jest pobranie danych z zewnętrznego API, ich normalizacja i zapis do pliku cache w postaci JSON oraz wyciągnięcie ważnych zmiennych i ich sortowanie. Bez ORM-ów, bez warstw pośrednich i bez "magii". Czysty PHP, który robi kilka rzeczy funkcjonalnych.
Strona działa wyłącznie na pliku cache JSON. Jeśli API ma chwilową przerwę lub zwraca błędy, użytkownik nadal widzi ostatnią poprawną wersję danych, a serwer nie wykonuje żadnych zbędnych operacji. To podejście upraszcza całą ścieżkę danych i eliminuje wiele potencjalnych punktów awarii.
Kluczowym elementem automatyzacji są Cloudflare Workers. To one uruchamiają cykliczne aktualizacje danych (cron wykonujący miniaplikację co 24h) pingując odpowiednio stworzony endpoint w pliku PHP, generują sitemapę, serwują wybrane zasoby z edge i zdejmują z backendu wszystko, co nie musi się na nim dziać. Dzięki temu system jest w pełni bezobsługowy i reaguje szybko nawet przy większym ruchu.
Frontend pozostaje maksymalnie przewidywalny: statyczny HTML, CSS osadzony w <head>, zero zewnętrznych zależności i brak pipeline’u do budowania. Wgrywasz pliki na serwer — i to wszystko.
Cache i wydajność w praktyce
Częścią tej samej filozofii jest sposób obsługi zasobów statycznych, w szczególności logotypów banków. To element, który w wielu serwisach bywa bagatelizowany, a potrafi generować niepotrzebne opóźnienia i zależności od zewnętrznych serwerów. Firmy są bardzo wrażliwe na punkcie wizerunkowym, wszystko musi być aktualne.
Logotypy są serwowane przez dedykowany mechanizm działający na brzegu sieci Cloudflare (edge) — czyli możliwie najbliżej użytkownika, a nie na głównym serwerze aplikacji. Oryginalne pliki są pobierane tylko raz na dobę, a następnie cachowane i dostarczane z lokalizacji geograficznie najbliższej przeglądarce. Dzięki temu obrazy ładują się praktycznie natychmiast, a całość pozostaje pod pełną kontrolą — zarówno pod względem wydajności, jak i zgodności z aktualnymi wytycznymi instytucji finansowych.
Ten sam minimalizm przekłada się na ogólną wydajność serwisu. Brak trackingu, brak ciężkich bibliotek, jeden request do danych, statyczny HTML i agresywne cachowanie sprawiają, że przeglądarka ma naprawdę niewiele pracy. Wysokie wyniki wydajnościowe (100/100 w PageSpeed Insights) są tu naturalnym efektem architektury, a nie celem samym w sobie.
Prywatność bez kompromisów
Na stronie nie ma cookies marketingowych, analityki, fingerprintingu ani żadnych skryptów śledzących. Wdrożone są sensowne nagłówki bezpieczeństwa: HSTS, X‑Frame‑Options i restrykcyjna polityka referrerów.
Użytkownik dostaje tylko treść — i nic poza tym.
SEO i przewidywalność
Chociaż serwis działa jak strona statyczna, od początku był projektowany tak, aby był w pełni czytelny dla wyszukiwarek. Dane strukturalne, metadane i sitemapa aktualizują się automatycznie wraz z cache’em, bez ręcznego nadzoru i bez dodatkowych narzędzi.
Układ HTML jest prosty i logiczny, więc roboty indeksujące nie muszą zgadywać, co jest czym. To nie jest "sprytne SEO" ani walka o algorytmy — po prostu poprawna techniczna implementacja, która nie wymaga ciągłej uwagi.
Gotowość na rozbudowę
Projekt powstał hobbystycznie, ale z myślą o tym, żeby mógł ewoluować. Logika filtrowania jest na tyle odseparowana, że rozszerzenie porównywarki o inne produkty finansowe dostępne w API (konta osobiste, lokaty itp.), sprowadzałoby się głównie do zmiany parametrów danych i etykiet na froncie.
Sprawdź działającą porównywarkę kont firmowych
konta-dla-firm.pl →Kilka obserwacji z produkcji
Jak to zwykle bywa, nawet lekka i niewinna strona szybko zaczyna przyciągać automatyczny ruch. W logach pojawiały się próby wejścia na typowe ścieżki CMS‑ów i frameworków (/wp-login.php, /.env, /xmlrpc.php).
Postanowiłem przetestować reguły "Security rules". Powstały reguły blokujące m.in na user-agent, kraj pochodzenia ruchu, typy plików i ścieżki (path). Filtrowanie ruchu i JS Challenge sprawiły, że backend praktycznie nie widział tego „szumu sieciowego”.
Dodatkowo e‑mail w domenie obsługiwany jest przez Cloudflare Email Routing, co ogranicza ekspozycję infrastruktury do minimum.
Dygresja o luce bezpieczeństwa w React
Od 4 grudnia z zainteresowaniem obserwowałem rozwój sytuacji wokół luki RCE w React (CVE‑2025‑55182), która postawiła na nogi administratorów i zespoły techniczne dużych serwisów.
Mój projekt sam w sobie nie miał powierzchni ataku, której dotyczył problem — brak Reacta, brak runtime’u po stronie użytkownika i brak zewnętrznych zależności zrobiły swoje. Rykoszet jednak i tak mnie dosięgnął.
W trakcie reagowania na CVE Cloudflare aktualizował reguły swojego WAF‑a, aby chronić użytkowników korzystających z podatnych stacków. W praktyce oznaczało to, że przez moment ubita została część zupełnie legalnego ruchu. Nie złośliwie — raczej w ramach szerokiego, defensywnego cięcia.
Sytuacja szybko się uspokoiła, reguły zostały doprecyzowane, a ruch wrócił do normy. Dla mnie była to bardziej ciekawa obserwacja niż realny problem, ale też kolejne przypomnienie, że im bardziej złożony ekosystem wokół, tym większa szansa na skutki uboczne — nawet w prostych projektach.
Podsumowanie
Powstała strona, która robi dokładnie to, czego potrzebowałem: wyświetla aktualne oferty, działa szybko, nie śledzi użytkownika i praktycznie nie wymaga obsługi.
To projekt, który okazał się świetnym poligonem do pracy z edge i automatyzacją, a przy okazji dowodem, że w wielu przypadkach prosta architektura wygrywa z rozbudowaną. Jest lekki jak statyczny serwis, elastyczny jak aplikacja i gotowy na dalszą rozbudowę — dokładnie tak, jak chciałem.