TL;DR 😉
Podobno programista uczy się najlepiej jak wrzuca się go na głęboką wodę i sprawdza czy wypłynie. Tak byłem uczony w swojej pierwszej firmie – masz i rób!
I w ten sposób bardzo, bardzo dawno temu postawiłem pierwszego WordPressa dla firmy. Bez znajomości php, mysqla, wiedzy serwerowej. I przy pomocy internetów
Teraz, po tylu latach nie jestem fanem tej metody – wrzucania na głęboką wodę – ponieważ w ten sposób, ktoś uczy się jak coś wykonać, ale często kosztem standardów lub jakości
Dlatego nauczony doświadczeniem stworzyłem Zbiory zadań Gladiatorów Javascriptu, aby każdy kto chce się w miarę szybko rozwijać, mógł tam znaleźć problemy na swoim poziomie, z którymi może się zmierzyć i będą one dla niego ambitne oraz rozwojowe
Tutaj znajdziesz link, aby poczytać więcej:
https://gladiators-landing.page.localhost-group.com/
A teraz opowiem o tym jaki cel ja sobie postawiłem ostatnio jako programista 😀
Jak fixować Gatsbiego na produkcji?
Niby się nie da, bo produkt Gatsbiego to statyczna strona, więc można niby fixować htmle i cssy, ale przy przebudowaniu jest problem, bo fixy znikają 🙂
Z uwagi na to, że pracuję z WordPressem uznałem, że fajnie byłoby mieć w adminie edytor Gatsbiego i kodu React 🙂 ale nie taki drewniany, tylko coś jak VSCode. wydaje się trudne do zrobienia ? otóż nie 😀
Zacząłem tworzyć „wtyczkę do WordPressa”, którą roboczo nazwałem Edytor Gatsbiego Live. Założyłem sobie, że chciałbym mieć IDE oraz podgląd live zmian
Problem numer 1 – znaleźć dobre, webowe IDE
Po krótkim researchu i odnalezieniu obrazu dockera theia IDE, miałem iframe z IDE z połączeniem do admina 
finalnie zrobiłem tak, aby IDE odpalało się w innym okienku. Co zaskakujące dla mnie theia IDE to po prostu VSCode w łebie 🙂
Drugim problemem, który musiałem rozwiązać to jak zrobić Live Reloading Gatsbiego
Czyli kiedy zmienię cokolwiek i zapiszę w webowym IDE. To okazało się też mało skomplikowane, bo wystarczyło zbudować prosty obraz dockera z Gatsbym w docker-compose
Po odpaleniu instancji Linuxa na AWS i przypisaniu do niej Elastic IP, w 5 min miałem odpalonego develop Gatsbiego na porcie 8000
Trzecim problemem, z którym musiałem się zmierzyć było:
Jak dostarczyć kod projektu Gatsbiego do IDE, tak aby zmiana i zapisanie w IDE powodowało reload strony?
To akurat było bardzo proste, bo docker-compose ma volumes, więc wystarczyło spiąć wolumen app z apką Gatsbiego do IDE, w miejsce /home/project:
Dzięki czemu w IDE znalazły pliki, które były podpięte do serwera developerskiego Gatsbiego serwowane z kontenera app
I problem „Jak fixować Gatsbiego na produkcji?” prawie został rozwiązany!
Z poziomu IDE możemy zrobić pusha z fixem do repo i jedyne co zostało do zrobienia to przebudowanie strony produkcyjnej – czyli w tym wypadku:
https://gladiators-landing.page.localhost-group.com/
Do tego mamy już specjalną wtyczkę, którą kiedyś sobie zrobiliśmy – nazwaliśmy ją Rebuilder i z tyłu niej jest mały mikroserwis, który odpowiada za budowanie apki na podstawie ostatniego commita:
Po kliknięciu w „Przebuduj stronę główną” z repo są zaciągane ostatnie pliki, Gatsby jest budowany i przerzucany na odpowiednią część FTP w sposób niezauważalny dla użytkownika
I voila – problem rozwiązany!
Mam nadzieję, że miło się czytało i zainteresowałem Cię technologią Gatsbiego, AWS, dockerem oraz myśleniem jak rozwiązać problem 🙂
Do następnego commita!
