Interakcja z API GraphQL
Interakcja z API GraphQLMigracja aplikacji z WordPress do innego frameworka lub CMS PHP

Migracja aplikacji z WordPress do innego frameworka lub CMS PHP

Schema GraphQL dostarczana przez Gato GraphQL zawiera pola do pobierania danych WordPress: posty, użytkownicy, komentarze, tagi, kategorie itp.

Kod w resolverach PHP pobierających dane WordPress zależy od WordPress; ten kod nie może działać w aplikacji innej niż WordPress.

Jednak Gato GraphQL implementuje każdy z tych resolverów za pomocą 2 pakietów:

  1. Pakiet PHP "vanilla", zawierający cały kod ogólny
  2. Pakiet specyficzny dla WordPress, zawierający rzeczywiste wywołania metod WordPress, które obsługują dany resolver

Na przykład w tej query GraphQL:

{
  posts {
    id
    title
  }
}

...logika pobierania postów składa się z:

  1. Pola Root.posts: rezyduje w ogólnym pakiecie posts
  2. Jego rozwiązania dla WordPress za pomocą metody get_posts: rezyduje w pakiecie specyficznym dla WordPress posts-wp.

Podział kodu między pakietami nie-WordPress/WordPress wynosi około 80/20%, co oznacza, że 80% kodu jest wielokrotnego użytku z innym frameworkiem/CMS, a tylko 20% kodu wymagałoby reimplementacji.

Ponadto cała funkcjonalność Gato GraphQL jest dostarczana za pomocą modułów, a moduły można włączać/wyłączać według potrzeb.

Moduły schematu
Moduły schematu

Moduły to funkcja zaimplementowana ze względów bezpieczeństwa: jeśli nie musisz udostępniać danych użytkowników w swoim publicznym API, możesz wyłączyć moduł Users, a odpowiednie pola (takie jak Root.users) nigdy nie zostaną dodane do schematu.

Moduły są bezpośrednio mapowane na bazowe pakiety PHP. W związku z tym, uruchamiając Gato GraphQL jako samodzielną aplikację, możemy selektywnie ładować te moduły/pakiety, których potrzebujemy, i żadnych innych.

Na przykład, jeśli Twoja aplikacja wyświetla tylko dane postów, kategorii i tagów, to tylko pakiety posts-wp, categories-wp i tags-wp (wraz z ich zależnościami) muszą zostać załadowane.

Następnie, migrując z WordPress (np. do Laravel lub Symfony), tylko te 3 pakiety specyficzne dla WordPress wymagałyby reimplementacji dla nowego frameworka/CMS i nic więcej.