pomysł
TenArchive zaczęło się od prostego celu: zbudować jedno małe miejsce na fotografię, notatki z IT i homelabu, CAD i druk 3D, a od czasu do czasu także wpisy z garażu, terenu lub różnych eksperymentów. Nie chciałem kolejnego wypolerowanego szablonu portfolio. Strona miała bardziej przypominać prywatny katalog na starym komputerze: najpierw użyteczna, dopiero potem trochę nietypowa.
Nazwa TenArchive pochodzi od mojego pseudonimu Ten. Archiwum jest publiczne, ale tożsamość osoby za nim celowo pozostaje oddzielona. Ta decyzja wpłynęła na cały projekt: publikować pracę i zainteresowania, a nie spis informacji o osobie czy serwerze.
ograniczenia stały się architekturą
Strona działa na celowo bardzo małym VPS-ie, więc każda niepotrzebna zależność ma swój koszt. To skierowało projekt w stronę zwykłego HTML-a, jednego niewielkiego arkusza CSS i czystego JavaScriptu. W rdzeniu strony nie ma frameworka, bazy danych, analityki ani zewnętrznego CDN-u z fontami.
Platformą hostingową jest Mikrus FROG — darmowy, bardzo mały VPS przeznaczony między innymi do nauki administracji i hostowania małych aplikacji oraz stron. Systemem jest Alpine Linux, a statyczne pliki serwuje Nginx. Te wybory pasują do tej samej idei co cała strona: małe elementy wykonujące jedno zadanie dobrze.
od portfolio do terminalowego archiwum
Pierwsze wersje za bardzo przypominały nowoczesne portfolio developera: wielkie nagłówki, układ z kartami i zbyt dużo wizualnego dopracowania. Działało, ale nie było moje. Interfejs był stopniowo spłaszczany do tekstowego archiwum z katalogami, promptami, zwartymi indeksami i rytmem przypominającym terminal.
W pewnym momencie eksperyment poszedł za daleko. Mocno ozdobiony interfejs shella stał się trudny do skanowania, szczególnie na mniejszych ekranach. Obecny wygląd jest kompromisem: inspirowany terminalem, ale nie próbujący go dosłownie symulować. Nawigacja i hierarchia treści pozostają czytelne, a charakter budują prompty, monospace i język systemu plików.
sekwencja startowa
Ekran ładowania wyrósł z kilku prostych komunikatów w krótką sekwencję przypominającą start Linuksa: linie podobne do logów kernela, uruchamianie usług i animację logowania na TTY. Wizualnie inspiruje się logami startowymi Arch Linuksa, ale jest wyłącznie dekoracją. Prawdziwy serwer korzysta z Alpine Linux i OpenRC, a nie z Archa i systemd.
Animacja uruchamia się raz na sesję przeglądarki, można ją pominąć, respektuje ustawienie ograniczonego ruchu i płynnie przechodzi do właściwej strony zamiast blokować każdą nawigację. Na telefonach log dopasowuje się do mniejszego ekranu i podąża za najnowszymi liniami.
fotografia bez robienia z VPS-a magazynu
Sekcja fotograficzna korzysta z lekkich kopii WebP i układu masonry. Pełne oryginały zdjęć nie są przechowywane na publicznym serwerze. Dzięki temu strona pozostaje lekka, a bardzo mały VPS nie staje się magazynem zdjęć. Interfejs galerii celowo schodzi na dalszy plan, żeby najważniejsze pozostały fotografie.
optymalizacje, które naprawdę miały znaczenie
Najbardziej użyteczne optymalizacje były proste: statyczne pliki, skompresowany CSS i JavaScript, rozsądny cache przeglądarki, lekkie obrazy WebP, brak zewnętrznych fontów i brak trackerów. Strona dostała też osobną optymalizację mobilną: większe pola dotykowe, prostsze siatki, bezpieczne zawijanie tekstu i układ jednokolumnowy tam, gdzie wymaga tego mały ekran.
Strojenie po stronie serwera trzymało się tej samej zasady: ograniczać koszty procesów działających w tle zamiast komplikować stos webowy. Sam Nginx pozostał bardzo lekki; celem było zostawienie jak największej części ograniczonych zasobów maszyny wolnej wtedy, gdy nikt nią aktywnie nie administruje.
test obciążeniowy
Po optymalizacjach wykonałem kontrolowany, pięciominutowy test narastającego obciążenia obejmujący strony HTML, CSS, JavaScript i obrazy. Generator obciążenia działał na tym samym małym VPS-ie co Nginx, dlatego traktuję wynik jako test odporności, a nie dokładny benchmark rzeczywistej pojemności serwera.
Publiczne zapytania HTTPS przez cały test zwracały HTTP 200. Gdy sztuczne obciążenie zostało celowo podniesione do przesadnego poziomu, przepustowość przestała rosnąć, a opóźnienia zwiększały się zamiast doprowadzić do awarii strony. Właśnie takie łagodne pogorszenie wydajności było najważniejszym wynikiem.
Powyższe wykresy są publicznymi, oczyszczonymi wersjami wygenerowanymi z oryginalnej telemetrii. Surowe logi, dokładne cele obciążenia, liczby połączeń, szczegóły zarządzania pamięcią, identyfikatory hosta i progi operacyjne pozostają prywatne.
prywatność jest częścią projektu
Publiczny blog techniczny może przypadkiem stać się spisem powierzchni ataku. TenArchive celowo nie publikuje adresów serwera ponad to, co jest potrzebne do wejścia na stronę, wewnętrznych nazw hostów, prywatnej topologii sieci, paneli administracyjnych, danych logowania, dokładnych reguł ekspozycji ani procedur odzyskiwania. Publiczne wpisy opisują decyzje i architekturę na użytecznym poziomie bez dokumentowania sposobu ataku na host.
Ta sama zasada dotyczy danych osobowych. Strona jest o projektach i zainteresowaniach, a nie o publikowaniu realnej tożsamości.
czego się nauczyłem
Mała maszyna wymusiła lepsze decyzje: mniej zależności, mniejsze zasoby, mniej JavaScriptu i wyraźniejszy podział między treścią a interfejsem. Design poprawił się również wtedy, gdy przestałem traktować „styl terminalowy” jako zestaw efektów wizualnych, a zacząłem traktować go jako język pisania i nawigacji.
TenArchive nadal jest celowo niedokończone. Archiwum może rosnąć po jednej stronie naraz bez systemu buildów, migracji bazy danych czy uruchamiania kolejnej usługi.
odnośniki / przydatne materiały
Ten wpis celowo pomija szczegóły operacyjne, które mogłyby zamienić publiczną stronę w użyteczną mapę jej własnej infrastruktury.