Programowanie to przygoda. Naprawdę. Siadając do komputera i chcąc coś zaprogramować igracie z losem. Jesteście jak bohater antycznej tragedii, który jakby się nie szarpał, jak nie manewrował i tak przeżyje przygody jakich się nie spodziewał. Może nawet polegnie.
Dziś poległem ja.
Nie jest to nic nowego. Dzień jak co dzień w życiu programisty. Pomyślałem jednak, że warto to zanotować nie dla koderów, ale dla – tak zwanego – biznesu, dla osób bez koderskiej praktyki, które dziwią się, że programiści nie lubią wyceniać zadań, że spóźniają się z wykonaniem projektów i że wykonanie prostej czynności zajmuje im kilka dni. Muszą się lenić ci arystokraci IT najpewniej! Czyżby?
Historia zaczyna się niewinnie: chcę wizualnie odświeżyć bloga. Nie lubię jednak – jak większość frontendowców – PHP, więc nikły jest mój entuzjazm w kwestii tworzenia nowego szablonu WordPress. Niewielki research i szybko pojawił się w główce głupi pomysł. Zrobię w Gatsby. Nowy, seksowny framework, oparty na React, musi być przyjemnie i ciekawie!
Zaczynam więc. Szybka instalacja, nieco dokumentacji i jedziemy z dewelopmentem. Już na wstępie nadzieja, że będzie łatwo pada ofiarą rzeczywistości. Gatsby niby to ma coś wygenerować z endpointa GraphQLowego, ale w gruncie rzeczy nie generuje nic. Trudno, napiszę „z palca”.
Do WordPressa dodaję pluginy WP GraphQL i WP Gatsby, jak kontrybutor w dokumentacji przykazał. I nawet udaje się coś pobrać. Tyle, że jakby nie wszystko. GraphQL zwraca jedynie posty po angielsku. No tak – bloga prowadzę w dwóch językach. Trzeba więc wymyślić, jak pobrać te drugie. Łatwo to jednak tylko brzmi. Okazuje się bowiem, że plugin Polylang do obsługi wielu języków rozkłada na łopatki plugin WP Gatsby. Trzeba użyć innego – WP GraphQL Polylang, który jednak odbiera nam możliwość korzystania z wbudowanego w Gatsby klienta GraphQL.
Zainstalowałem zatem klilenta Apollo. Wydawał się działać. Ucieszony napisałem prosty komponent wyświetlający listę postów. Nagłówki, pięknie, wyświetlały się. Tyle, że już nie treść. Treść przychodziła z backendu pusta. Co ciekawe plugin to samo zapytanie inaczej rozwiązywał po stronie klienta i w oknie pluginu WordPress. Ciekawy przypadek. Ciekawy…
Tak był ciekawy, że godzinę co najmniej spędziłem na analizowaniu różnic, nie dopatrzywszy się żadnych istotnych. Kolejne pół godziny zaś na przeszukiwaniu Google w próbie rozwiązania tej zagadki. Tak jednak niestety się okazało, że jest to dość świeża sprawa i w zasadzie nikt o tym nie pisze. Wreszcie znalazłem kanał Slack pluginu i udało mi się w jego historii odnaleźć wzmiankę o autentykacji. Potencjalnie więc brak treści postów wynika z braku uwierzytelnienia. No to już pewnie jesteśmy w domu…
Niefortunnie droga do tego domu okazuje się prosta jak u Barei. Żeby dokonać autentykacji należy zainstalować – i to ręcznie, ściągając samemu z repozytorium Githuba – plugin WPGraphQL JWT Authentication, a następnie wygenerować gdzieś sekret, wkleic go do pliku konfiguracyjnego wp-config, a także upewnić się, że serwer wspiera nagłówek HTTP_AUTHORIZATION. A żeby wspierał trzeba w apache skonfigurować .htaccess i…
I zrobiła się pierwsza w nocy.
Nad tak banalnym zadaniem jak wyświetlenie listy postów pobranych z backendu oraz jego konfiguracja spędziłem dobre 8 godzin i udało mi się jedynie wyświetlić ich nagłówki. To, co miało być najprostsze (konfiguracja backendu) okazało się piramidalnie trudne, a tego, nad czym planowałem spędzić większość pracy (layout frontu, routing, struktura stron) nie udało mi się nawet zacząć.
Owszem – są to w większości technologie mi nieznane, ani z Gatsbym, ani z pluginem WPGraphQL wcześniej nie pracowałem – ale jednak nie są to tak zupełnie obce mi kwestie. Mimo wszystko kompletnie ugrzęzłem w bagnie ustawień, nieprzewidzianych zależności, specjalnych przypadków i niedoróbek opensource’owym oprogramowaniu.
I tak się proszę państwa uprawia tę deweloperską rolę, co łamie pług i plecy łamie.
Co pcha front end developerów do ciągłego próbowania innych rozwiązań zamiast trzymania się sprawdzonych? Czy ten task był do zrobienia w sensownym czasie bez używania nowych rzeczy?
Ten post zdecydowanie zadziałał odwrotnie od zamierzeń, bo mnie przekonał, że dev nie robi tego, co mu przypisano, tylko niepotrzebnie się bawi 😉
Zacząłbym od tego, że nie tylko front-end developerów. Wszystkich programistów. Co nas pcha do próbowania innych rozwiązań? Wiele rzeczy, które można streścić pod pojęciem – charakterystyka branży. Nie da się być w IT tradycjonalistą. Konserwatyści odchodzą tu do lamusa, na wcześniejszą emeryturę zwaną bezrobociem. Informatyka to nieustanne poszukiwanie lepszego, szybszego, tańszego rozwiązania. Nie zawsze się udaje, ale samo dążenie nie ustaje. Oczywiście trudno się nie zgodzić ze stwierdzeniem, że nie robiłem tego co byłoby najkrótszą drogą do celu. Tylko, że celem nie jest jedynie najszybciej coś zrobić – to jest cel biznesu. Celem programisty, najważniejszym, o ile nie chce zostać managerem, jest utrzymać się na rynku. By to zrobić trzeba wpatrywać się w jego trendy i uczyć się nowo wyłaniających się technologii. Programista to nie chirurg, który musi robić solidnie i kroić tak samo, ale raczej doradca podatkowy, który powinien nadążać za nowinkami.