👷🏽♂️ Budowanie Gato GraphQL w sposób otwarty #1 (marzec 2021)
Witajcie w pierwszym wydaniu newslettera „Building in the Open"!
To kanał do dzielenia się nowościami dotyczącymi rozwoju Gato GraphQL ze społecznością, wysyłany w pierwszym tygodniu każdego miesiąca.
Za pośrednictwem tej przestrzeni będziemy poznawać wszystko, co wydarzyło się w poprzednim miesiącu, w tym:
✅ Nad czym pracowaliśmy i jakie nowe funkcje wydaliśmy
✅ Nad czym będziemy pracować w nadchodzącym miesiącu
✅ Ile ruchu mieliśmy na stronie
✅ Jak radziła sobie wtyczka: liczba pobrań, subskrypcji newslettera, gwiazdek na GitHubie
✅ Postęp w osiąganiu stabilności finansowej
✅ Nowo opublikowane przewodniki
✅ Podsumowanie naszych ostatnio opublikowanych wpisów na blogu
✅ Zasięg / Wzmianki o wtyczce
✅ Ogólne nowości
Jeśli podoba Ci się ten newsletter, zaproś znajomych, aby subskrybowali.
Zaczynamy!
Uwaga: Ten newsletter jest dwukierunkowym kanałem komunikacji. Jeśli chcesz coś powiedzieć, zapraszamy do dodania komentarza (na dole wpisu na blogu).

Nad czym pracowaliśmy w kodzie
Jeśli zauważysz Przewodniki, sekcja „Extending Gato GraphQL" jest nadal dość pusta:

Moim priorytetem jest uzupełnienie tych przewodników. Ale zanim to zrobię, chcę, aby kod wtyczki był jak najprostszy. Im prostszy, tym mniej dokumentacji jest potrzebne, i tym więcej osób jest w stanie go zrozumieć.
Mając to na uwadze, zdecydowałem się zrefaktoryzować kod, aby był w pełni oparty na komponencie DependencyInjection Symfony.
Idea jest taka, że każde rozszerzenie wtyczki (takie jak niestandardowy TypeResolver, FieldResolver lub DirectiveResolver) jest po prostu definiowane jako usługa w kontenerze, a usługa jest automatycznie konfigurowana przez Compiler passes.
Pełne poleganie na wstrzykiwaniu zależności Symfony ma kilka zalet:
✅ Istnieje jeden, spójny sposób tworzenia rozszerzeń
✅ Wystarczy stworzyć klasę PHP implementującą jakiś interfejs, aby wykonać całą pracę, a programista nie musi znać technicznych szczegółów
✅ Dokumentacja Symfony jest bardzo obszerna. Kierując deweloperów do niej, jest to dokumentacja, której ja nie muszę pisać
Zainteresowany kodem? Sprawdź moje ostatnie scalone PR-y (#453, #452, #449 i kilka innych).
Będę kontynuował pracę nad tym kodem przez nadchodzące tygodnie, dopóki migracja nie będzie w 100% zakończona i dopóki nie napiszę brakujących przewodników.
Ruch na gatographql.com
Pozwólcie, że będę jasny w jednej kwestii: zależy mi na tym, ile osób odwiedza stronę internetową wtyczki, jako wskaźnik tego, ile osób o niej wie.
Nie mam głębokich kieszeni, aby reklamować moją wtyczkę. A nawet gdybym miał, nie wydawałbym pieniędzy na jej promowanie, ponieważ jest to sprzeczne z duchem open source. (Byłoby inaczej, gdyby open source był tylko kanałem do sprzedaży jakiegoś produktu lub usługi, ale to nie jest mój przypadek.)
Oznacza to, że w pełni polegam na przekazie szeptanym, aby go promować. W tym celu poświęciłem wiele wysiłku na pisanie wysokiej jakości treści na blogu wtyczki, mając nadzieję, że te treści zostaną udostępnione, docierając do osób, które w przeciwnym razie nie wiedziałyby o wtyczce.
I jak dotąd jestem dość zadowolony z wyników.
W ciągu ostatniego miesiąca miałem 4,5 tys. odwiedzających, z 6 tys. odsłon strony:

Przeanalizujmy te statystyki.
Większość moich odwiedzających pochodzi z Hacker News, gdzie udało mi się pojawić na kilku stronach głównych z „Show HN", oraz z Reddita, głównie z /r/PHP i /r/graphql (gdzie zawsze udostępniam moje artykuły).
Udało mi się zająć #1 na Google szukając „wordpress core graphql", co przyniosło mnóstwo ruchu. Niestety był to jednorazowy sukces: po 24h zniknął tak nagle, jak się pojawił. W typowy dzień dostaję między 3 a 10 odwiedzających z Google.
Twitter i Facebook przynoszą sporą ilość ruchu, ale nie wiem od kogo (nie ode mnie, ponieważ jestem wyjątkowo słaby w mediach społecznościowych). Udostępniam moje artykuły na Twitterze, ale rzadko są retweetowane. Nie używam 👎🏾 Facebooka.
(Przy okazji, dla tych, którzy udostępniają moje artykuły w mediach społecznościowych, dziękuję ❤️)
Otrzymuję skromny, ale konsekwentny ruch z listy serwerów GraphQL w PHP na graphql.org, oraz z artykułu, który opublikowałem na dev.to, który pojawia się na #1 przy googolowaniu „graphql execute multiple queries".
Wreszcie, moje artykuły konsekwentnie pojawiają się w głównych newsletterach WordPress (w tym WP Owls, wpMail.me, Post Status, WP Builds i The WP Weekly). Nie wiem dokładnie, ile ruchu każdy z nich przynosi, ponieważ referrer będzie wyglądał jak Gmail i inne podobne. Jednak łącznie te newslettery generują sporą liczbę odwiedzających.
Moje wpisy na blogu są zdecydowanie moją najpopularniejszą treścią, a ostatnie trzy (ten, ten i ten) przyniosły ponad 1 tys. odwiedzających każdy.
Te liczby wyglądają całkiem dobrze, tym bardziej że zaledwie uruchomiłem stronę mniej niż 2 miesiące temu. Jednak nie wszystko wygląda dobrze: przy 88% współczynnik odrzuceń jest dość wysoki. Muszę nad tym popracować.
Metryki
Ruch na stronie jest jedynie dekoracyjną metryką, służącą do szacowania świadomości istnienia wtyczki. Ale znacznie ważniejsze jest pytanie: ile osób zaczęło używać wtyczki w ciągu ostatniego miesiąca?

W ciągu ostatniego miesiąca wtyczka radziła sobie następująco:
🎯 Liczba pobrań wtyczki: 170
⭐️ Gwiazdki na GitHubie: 27
Liczbę pobrań można pobrać z API GitHuba, przekazując parametr per_page=3, aby uwzględnić tylko 3 wydania utworzone w ciągu ostatniego miesiąca:
curl -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/GatoGraphQL/GatoGraphQL/releases?per_page=3 | grep "download_count"Nie jestem ani zadowolony, ani niezadowolony z tych liczb. Nie są świetne (i chciałbym, żeby były lepsze), ale to dobry początek.
Jeśli chodzi o pobrania, mówi się, że zdobycie pierwszego użytkownika jest najtrudniejszym zadaniem. Dopiero gdy kilka osób zacznie używać wtyczki i zacznie o niej mówić, jej użycie stanie się bardziej powszechne. Nadal jestem na tym początkowym etapie znajdowania pierwszej grupy zaangażowanych użytkowników.
Jeśli chodzi o gwiazdki na GitHubie, muszę powiedzieć, że wygląda to dość płasko: średnio około 1 gwiazdka dziennie. To z pewnością nie jest nic wielkiego. Jeśli podoba Ci się to, co buduję z Gato GraphQL, i nie masz nic przeciwko okazaniu trochę ❤️ miłości, to proszę rozważ przyznanie ⭐️ gwiazdki na GitHubie.
Stabilność finansowa
To jest trudna kwestia: projekt musi być finansowo stabilny. Albo generuje trochę pieniędzy, albo nie przetrwa długo.

Jeśli uda mi się zapewnić sobie dochód, mogę kontynuować pracę nad nim tak długo, jak to konieczne. To wszystko, czego potrzebuję: dochód. Nie inwestorzy pukający do moich drzwi w poszukiwaniu milionów. Tylko kilka tysięcy miesięcznie, żeby opłacić dach nad moją głową.
Moim celem jest utrzymanie wtyczki w pełni open source. W tym celu aktualnie kontaktuję się z kilkoma potencjalnymi sponsorami, pytając, czy chcieliby pomóc w finansowaniu rozwoju wtyczki. Będzie to sytuacja win-win.
Dlaczego sięgam po kilku „grubszych" sponsorów, zamiast polegać na zwykłym sponsoringu od kogokolwiek ze społeczności?
Tak, próbowałem tego również: jestem na GitHub Sponsors. Jednak to tak naprawdę nie działa, chyba że masz już tysiące użytkowników, obserwujących lub osób zapisanych na listę mailingową, do których możesz się zwrócić, oczekując, że wielu z nich Cię dofinansuje.
Na przykład, prosząc o standardowe 5 lub 10 dolarów miesięcznie, potrzebowałbym kilkuset finansujących, żeby to podejście pokryło moją pracę. A daleko mi do tego etapu.
Ale jeszcze bardziej, kto naprawdę może odnieść sukces dzięki temu podejściu? Wiem, że Caleb Porzio (twórca Livewire) osiągnął to i teraz ma ponad 1350 sponsorów! Ale to raczej wyjątek niż reguła.
Weźmy na przykład Composer. Composer fundamentalnie zmienił sposób, w jaki tworzymy aplikacje PHP, a jednak ledwo ma 90 sponsorów. Jak mogłbym kiedykolwiek oczekiwać, że zdobędę więcej sponsorów niż Composer?
Dlatego moje obecne podejście polega na tworzeniu sytuacji win-win dla mojego projektu i kilku firm gotowych go sponsorować. Mam nadzieję, że to zadziała, Gato GraphQL będzie darmowy dla wszystkich, ze wszystkimi funkcjami, i nie będę musiał zamykać dobrych rzeczy za paywallem.
(Jeśli chcesz dowiedzieć się, jak to jest sytuacja win-win, wyślij mi e-mail lub DM. Może Twoja firma też byłaby zainteresowana?)
Dam temu podejściu kilka miesięcy, mając nadzieję, że mi się uda. Jeśli nie odniosę sukcesu, dopiero wtedy będę musiał rozważyć stworzenie wersji PRO wtyczki i ograniczenie niektórych funkcji do wersji płatnej. (Tak, to byłoby do niczego, więc mam nadzieję, że uda mi się uniknąć tego etapu.)
W nadchodzących newsletterach będę informować Was, czy udało mi się zdobyć sponsorów, czy nie.
Wpisy na blogu
Wpisy na blogu były moją absolutną dumą i radością.
Uwaga: Czy wiesz, że na stronie jest kanał RSS? Możesz zasubskrybować, aby otrzymywać wszystkie moje wpisy na blogu i czytać je w swoim ulubionym czytniku.
W ciągu ostatniego miesiąca udało mi się opublikować wysokiej jakości wpis na blogu każdego tygodnia:
🛠 Czy WordPress powinien mieć API GraphQL w core? argumentuje, że WordPress mógłby skorzystać na GraphQL, ponieważ WP REST API otrzymało nową funkcjonalność w WordPress 5.6 (operacje wsadowe), którą API GraphQL może dostarczyć natywnie.
🥊 Gato GraphQL vs WPGraphQL: pojedynek! porównuje moją wtyczkę z WPGraphQL, w starciu, które będzie pamiętane przez pokolenia i które sprawi, że kibice będą prosić o więcej.
👶🏻 Odmładzanie WordPress przez GraphQL demonstruje, jak headless WordPress może być oddzielony od kodu bazowego WordPress, dając możliwość naprawienia (lub przynajmniej ominięcia) nagromadzonego długu technicznego.
🍾 Gato GraphQL jest teraz scoped, dzięki PHP-Scoper! opisuje strategię scopowania wtyczki WordPress przy użyciu PHP-Scoper, aby uniknąć konfliktów z innymi wtyczkami.
Zasięg / Wzmianki o wtyczce
Cieszę się, że wtyczka została wyróżniona w kilku miejscach.
✅ Wygłosiłem prelekcję „Intro to Gato GraphQL" na WordCamp India 2021, robiąc demo wtyczki, i (co zaskakujące przy demo) wszystko wyszło idealnie! Sprawdź film na YouTube.
✅ Joe Howard przeprowadził ze mną wywiad dla podcastu WPMRR. Nagranie pojawi się wkrótce.
✅ Chris Coyier wyróżnił moją wtyczkę w newsletterze CSS-Tricks #239!

Trochę z każdego
Kilka ogólnych nowości o wszystkim, co wydarzyło się w ostatnim miesiącu.
Jason Bahl dołącza do WP Engine
Gratulacje dla Jasona za dołączenie do WP Engine! Mam nadzieję, że będzie nadal zaskakiwał, jak robił to do tej pory dla WPGraphQL.
Przy okazji, fakt, że jesteśmy konkurentami (no cóż, to ja z nim konkuruję, on jest o wiele dalej) nie oznacza, że nie możemy być przyjaciółmi ani współpracować, aby poprawić nawzajem swoje projekty. Właściwie obaj mamy ten sam cel: wprowadzić GraphQL do WordPress (nawet jeśli mamy różne pomysły na to, jak to powinno się stać).
Ale wierzę, że konkurencja jest dobra i przyniesie korzyści wszystkim.

WP Engine uruchamia Atlas i twierdzi, że wie wszystko o headless (czy naprawdę?)
Gratuluję również WP Engine uruchomienia Atlas, ich nowego rozwiązania headless WordPress.
Niestety podają pewne niedokładne informacje:
Firmy korzystające z w pełni headless rozwiązania zazwyczaj hostują osobną aplikację JavaScript dla front-endu, która pobiera konkretne dane WordPress za pośrednictwem API — WordPress REST API lub wtyczkę WPGraphQL.
No tak, Gato GraphQL nie istnieje, prawda?

Normalnie nie przejmowałbym się tym, ponieważ nie oczekuję, że wszyscy znają moją wtyczkę. Ale wierzę, że znają mój projekt i wydaje się, że celowo go ignorują.
Po tym, jak uruchomili developers.wpengine.com (czyli „kompleksowe centrum najlepszych praktyk, samouczków, blogów i dokumentacji dla headless WordPress"), skontaktowałem się z nimi:
- Matt Landers, Developer Relations w WP Engine dla headless WordPress, na Twitterze
- Ich zespół deweloperski, na repozytorium GitHub ich headless framework
- Ktoś z Torque (magazynu należącego do WP Engine), przez DM-y z @TheTorqueMag.
Myślę, że nie potraktowali mojego projektu poważnie. Albo po prostu nie zależało im na nim, ponieważ są w pełni zainwestowani w WPGraphQL.
Cóż, rozumiem, jeśli nie chcą wspominać mojej wtyczki. Jednak stwierdzanie, że WP REST API i WPGraphQL to jedyne dwie opcje, jest bardzo mylące. W konsekwencji moja wtyczka jest szkodzona, a społeczność deweloperów jest dezorientowana.
I tak tak, muszę przyznać, że jestem poirytowany. To w ogóle nie jest w porządku. Mam nadzieję, że poprawią swoje niedokładne informacje (wysłałem im już e-mail).
Podsumowanie
To był koniec pierwszego w historii „Budowania Gato GraphQL w sposób otwarty".
Co o tym sądzisz? Zapraszamy do podzielenia się swoimi przemyśleniami w komentarzach.
Jeśli Ci się podobało, będę wdzięczny, jeśli możesz podzielić się newsletterem ze swoimi znajomymi (lub, co jeszcze lepsze, zaprosić ich do subskrypcji).
Do zobaczenia w przyszłym miesiącu!