Stack technologiczny cutty.dev — świadome wybory

Większość wpisów "mój tech stack" to dumna lista nowinek. Patrz, mam to, mam tamto, a tu jeszcze świeżutka biblioteka z zeszłego tygodnia. Ten będzie inny.

Bo prawda jest taka, że jak prowadzisz projekt sam, to nie szukasz najmodniejszego. Szukasz czegoś, co cię nie obudzi o trzeciej w nocy. I właśnie o tym jest cały ten stack technologiczny cutty.dev: nudny zamiast modnego, europejski zamiast amerykańskiego, prywatny od fundamentów, i na tyle prosty, żeby ogarnęła to jedna para rąk.

Lecę po kolei, tak jakbym ci to tłumaczył przy kawie.

Astro renderowane na serwerze (i czemu nie coś "fajniejszego")

cutty.dev to Astro z renderowaniem po stronie serwera. Każde żądanie idzie przez serwer, składa stronę i odsyła gotowy HTML. Nuda? No właśnie o to chodzi.

Chciałem trzy rzeczy: rendering na serwerze bez ciężkiej maszynerii, porządne wsparcie wielu języków od ręki, i szybkość bez narzutu. Astro daje to wszystko, a kod zostaje czytelny. Jak wracam do niego po dwóch miesiącach przerwy, to wiem, co tam się dzieje. Przy projekcie solo to jest warte więcej niż jakikolwiek modny dodatek, który po roku nikt już nie wspiera.

Jeden plik zamiast bazy z fajerwerkami

SQLite. Jedna baza, jeden plik na dysku. Do tego warstwa zapytań gadająca z TypeScriptem, więc jak zmienię strukturę danych, błąd wyskakuje mi w edytorze, a nie na produkcji o północy.

Dlaczego akurat to? cutty jest "read-heavy". Ktoś klika skrócony link, my robimy odczyt i podbijamy licznik. Tyle. SQLite ciągnie taki ruch spokojnie, do naprawdę dużych liczb dziennie. A backup? Kopiujesz plik. Koniec. Bez ceremonii replikacji, bez skryptów, których nikt nie pamięta jak działają.

Tu uważaj na jedno, bo to częsta pułapka: ludzie słyszą "SQLite" i myślą "zabawka do projektu na zaliczenie". Nieprawda. Mniej ruchomych części to mniej rzeczy, które mogą się rozsypać. To nie oszczędzanie na jakości, to świadoma decyzja.

Serwer stoi w Europie i to nie przypadek

Dedykowany serwer w UE. Własny TLS, reverse proxy z automatycznym HTTPS, aplikacja w kontenerach.

To jest fundament tego, jak cutty obchodzi się z danymi. Wiem dokładnie, gdzie one fizycznie leżą (przy klientach z UE i RODO to nie ciekawostka, tylko warunek), nie jestem przywiązany do jednego dostawcy, nic nie wycieka automatycznie za ocean, a rachunek jest przewidywalny zamiast skakać razem z ruchem.

Tak, wygodne platformy z Zachodu dałyby szybszy start. Klikasz, deploy, działa. Tylko że płacisz za to tym, gdzie lądują dane twoich użytkowników. Dla mnie to był zły deal.

Tłumaczenia robi własny model, u siebie

cutty mówi 25 językami. Tłumaczy to lokalny, otwarty model AI, który chodzi na mojej infrastrukturze. Nie wysyłam tekstu z interfejsu do żadnego zewnętrznego dostawcy.

Korzyści są praktyczne. Pojedyncze tłumaczenie kosztuje zero. Mam pełną kontrolę nad jakością i mogę je odświeżyć kiedy chcę. No i maszyna zawsze potrzebuje ludzkiego oka, więc każdy z tych 25 języków przeszedł przegląd. Ale fakt, że robię to u siebie, oznacza, że prywatność nie jest pozycją w cenniku. Jest właściwością tego, jak całość jest zbudowana.

Tailwind, kontenery i kilka mniejszych decyzji

Style? Utility-first, czyli Tailwind. Bez CSS-in-JS, bez osobnych plików ze stylami, wszystko prosto w szablonach. Nie tracę czasu na wymyślanie nazw klas, niewykorzystane style i tak nie trafiają na finalną stronę, a design trzyma się kupy bo sam system to wymusza. Dla jednej osoby liczy się każda minuta nie zmarnowana na pierdoły.

Wdrożenie to Docker. To samo środowisko lokalnie i na produkcji, koniec z "u mnie działało". I gdyby kiedyś trzeba było, przenoszę całość na inny serwer w jakieś pół godziny. Przenośność to po cichu forma niezależności.

Co z tego wyniosłem

Nudny stack wygrywa. Astro, SQLite, Tailwind, kontenery. Wszystko dojrzałe, ograne, opisane. Nic nie pęka w momencie, w którym najmniej tego potrzebujesz.

Hosting w UE jest gotowy na produkcję, naprawdę. Bajka, że "musisz iść na wielką amerykańską chmurę, żeby było na serio", to bajka. Lokalny AI też jest realny, nie trzeba oddawać danych zewnętrznemu API, żeby mieć przyzwoite tłumaczenia. I ostatnia rzecz: jedna osoba może wypuścić coś, co wygląda jak robota całego zespołu. Trzeba tylko pamiętać, że czas jest droższy od pieniędzy, i pod tym kątem dobierać każdy klocek.

Jak budujesz coś swojego, zadaj sobie jedno pytanie przy każdej technologii: czy za rok będę umiał to sam utrzymać? Jeśli nie, to chyba masz odpowiedź.

Działa to wszystko tu: cutty.dev. A jak chcesz pogadać o którejś z tych decyzji, pisz na [email protected], odpisuję tego samego dnia.