Migracja z Airtable do Sanity: czyli jak moje portfolio dorobiło się trzech sposobów przechowywania danych

Migracja z Airtable do Sanity — czyli jak moje portfolio dorobiło się trzech sposobów przechowywania danych

Moje portfolio nie zaczęło się od przemyślanej architektury, dobrze dobranego CMS-a i pięknego diagramu pokazującego przepływ danych. Zaczęło się od… zahardkodowanych danych. I przez jakiś czas było całkiem dobrze. Potem projektów zaczęło przybywać, więc edytowanie wszystkiego bezpośrednio w kodzie zaczęło być trochę mniej zabawne. Pomyślałam więc: dobra, potrzebuję jakiejś bazy.

Dlaczego Airtable?

Dlaczego akurat Airtable? Na jednym z kursów prowadzący go używał, więc chciałam sama zobaczyć, o co w tym wszystkim chodzi. Do tego część jest darmowa, dokumentacja wyglądała całkiem przyjemnie, a jak się patrzy na te wszystkie requesty z curl, to człowiek od razu czuje się bardziej programistą. A przecież właśnie o to chodzi w portfolio, prawda? Żeby pokazać, że jest się dobrym programistą.

No właśnie.

Wtedy pojawiło się u mnie pytanie, które chyba jest trochę ważniejsze niż samo „czy umiem to zakodować?”. Co właściwie znaczy być dobrym programistą? Czy chodzi o to, żeby dobrze zaimplementować rozwiązanie, czy może również o to, żeby wcześniej zastanowić się, czy wybrane narzędzie rzeczywiście pasuje do problemu? Wtedy jeszcze nie miałam na to dobrej odpowiedzi.

Pierwszą wersję portfolio zrobiłam, wszystko działało, więc zostawiłam ją w spokoju. Minęło trochę czasu, wchodzę na stronę i co? Obrazki się nie renderują. Myślę sobie: co jest grane? Zaglądam do mojej „bazy”. Obrazki są. Naprawdę tam są. Więc dlaczego, do jasnej ciasnej, nie renderują się na produkcji?

Przez chwilę oczywiście pierwsza myśl brzmi: „Co ze mnie za frontendowiec, któremu obrazki się nie renderują?”. Trochę czasu zajęło mi dojście do tego, że problemem nie był React, Next.js ani jakaś magiczna klątwa nałożona na moje portfolio. Po prostu Airtable nie było dobrym miejscem do przechowywania tych obrazków w taki sposób, w jaki próbowałam to robić.

No dobrze. Co robi junior, kiedy coś nie działa? Oczywiście robi tak, żeby działało. Obrazki wróciły więc… do kodu.

Tak. Znowu zahardkodowane.

Czy było to idealne rozwiązanie? Nie. Czy działało? Tak. A skoro działało, to oczywiście można było uznać temat za zakończony.

Supabase Storage, czyli teraz już będzie dobrze

Po jakimś czasie stwierdziłam jednak, że wypadałoby zrobić to trochę porządniej. Padło na Supabase Storage. Przerzuciłam tam obrazki.

Śmiga?

Śmiga.

No to niech wisi.

I wisiało. Przez kilka lat.

Miałam więc w jednym projekcie dane projektów w Airtable, obrazki w Supabase Storage i część rzeczy zahardkodowanych w kodzie. Czyli może nie był to jeszcze technologiczny chaos, ale zdecydowanie zaczynał przypominać kolekcję decyzji podejmowanych w różnych momentach mojego życia.

Aż zachciało mi się bloga

Kilka lat później postanowiłam trochę odświeżyć portfolio. Pomyślałam, że fajnie byłoby nie tylko pokazywać projekty, ale też dzielić się tym, czego uczę się podczas pracy jako frontend developer. Czyli potrzebuję bloga.

Zajrzałam więc do swojego stacku.

A tam: Airtable + Supabase + zahardkodowane rzeczy.

Patrzę na to i myślę: No cóż. Chyba trzeba to jakoś lepiej zorganizować.

Zapytałam więc mojego przyjaciela Czarusia, czyli ChatGPT, co by mi polecił. Dostałam kilka możliwości i między innymi pojawiła się opcja, przy której moje oczy zrobiły coś takiego: 👀

Zahardkodowanie wszystkiego.

Znowu.

Nie.

Tym razem nie.

Skoro już zabieram się za porządkowanie projektu, to powrót do ręcznego wpisywania wszystkiego w kodzie byłby raczej regresem niż progresem. Do wyboru miałam między innymi pozostanie przy Airtable, przeniesienie danych do Supabase, użycie headless CMS-a czy właśnie Sanity. Była też oczywiście opcja „nic nie zmieniaj, przecież działa”, ale jakoś nie czułam się na tyle odważna.

Wybrałam Sanity.

I wtedy zaczęła się właściwa migracja.

Dobra, ale gdzie właściwie są te dane?

Podzieliłam sobie całą migrację na mniejsze kroki. Najpierw instalacja paczek, potem konfiguracja, potem studio. I w pewnym momencie pojawiło się bardzo podstawowe pytanie: „Dobra, ale jak ja teraz coś wpiszę w tym Studio, to gdzie właściwie to się zapisuje?”

Przy Airtable było to dość intuicyjne. Miałam tabelę, rekordy, pola i mogłam sobie kliknąć. W Sanity dochodzi trochę inny model myślenia. Studio jest interfejsem do zarządzania treścią, a sama treść jest przechowywana w Sanity. W projekcie definiujemy schematy dokumentów, a później możemy tworzyć i edytować dane za pomocą Studio.

Czyli zamiast trzymać dane projektów bezpośrednio w kodzie, mogę mieć dokument projektu z polami takimi jak tytuł, opis, technologie, link do strony, GitHub, obrazek czy wersja językowa, a aplikacja po prostu pobiera te dane.

I to już zaczęło wyglądać jak rozwiązanie, które faktycznie ma sens dla portfolio, które chcę dalej rozwijać.

No dobrze. To teraz error.

Oczywiście, że pojawił się error. Bo dlaczego miałoby go nie być?

Okazało się, że mam starszą wersję Reacta i Next.js 14, a zainstalowałam najnowszą wersję Sanity. I teraz miałam do wyboru dwie drogi. Pierwsza: „A dobra, to upgraduje Reacta i Next.js. Jakoś to będzie”. Druga: „Może jednak nie róbmy teraz nieplanowanej migracji połowy aplikacji tylko dlatego, że chcemy zmienić CMS-a”.

Wybrałam drugą.

Zamiast aktualizować cały projekt na hurra, dobrałam wersję Sanity kompatybilną z tym, co już miałam. I nagle… działa. Bez przebudowy całej aplikacji, bez dokładania sobie kolejnych problemów i bez robienia przy okazji wielkiej migracji Reacta, Next.js i połowy projektu.

I chyba właśnie tego nauczyła mnie ta migracja

Patrząc na moje portfolio z perspektywy czasu, widzę tam trochę historii mojego rozwoju. Najpierw wszystko było zahardkodowane, bo tak było najprościej. Potem Airtable, bo chciałam mieć bazę. Potem Supabase Storage, bo obrazki zaczęły robić problemy. Potem przez kilka lat niczego nie ruszałam, bo… działało. A kiedy portfolio zaczęło się rozrastać, okazało się, że wszystkie te małe decyzje podjęte w różnych momentach zaczęły się ze sobą trochę gryźć.

I chyba właśnie wtedy wróciło do mnie pytanie z początku: czy dobry programista to ten, który potrafi dobrze napisać kod, czy ten, który potrafi też odpowiednio dobrać narzędzie?

Coraz bardziej skłaniam się ku temu, że jedno bez drugiego jest trochę niepełne. Można napisać bardzo dobry kod wykorzystujący kompletnie niepasujące narzędzie. Można też użyć modnego rozwiązania tylko dlatego, że jest modne. Można wreszcie zrobić wielką migrację „bo teraz będzie profesjonalnie”, a po dwóch dniach zastanawiać się, dlaczego właściwie to wszystko zrobiliśmy.

Dlatego tym razem nie chciałam po prostu wymienić jednego narzędzia na inne. Chciałam uporządkować sposób, w jaki moje portfolio przechowuje i pobiera treści. I na ten moment Sanity dobrze się w tym sprawdza.

Czy to oznacza, że moje portfolio jest już idealnie zaprojektowanym systemem?

Oczywiście, że nie.

Nadal mam Next.js 14 i starszego Reacta.

Ale to już temat na inną historię.

Na razie działa.

I tym razem mam nadzieję, że trochę bardziej wiem dlaczego.