Frontendová API brána: GraphQL Federation a Schema Stitching

Ve světě moderního vývoje webových aplikací může být správa dat z více zdrojů významnou výzvou. Jak aplikace rostou na složitosti a přecházejí na architekturu mikroslužeb, stává se potřeba jednotného a efektivního způsobu přístupu k datům prvořadou. Frontendová API brána funguje jako centrální vstupní bod pro klientské aplikace, agreguje data z různých backendových služeb a poskytuje zjednodušené prostředí pro vývojáře i koncové uživatele. Tento blogový příspěvek se zabývá dvěma výkonnými technikami pro budování frontendové API brány: GraphQL Federation a Schema Stitching.

Co je to frontendová API brána?

Frontendová API brána je architektonický vzor, kde dedikovaný server funguje jako prostředník mezi frontendovými klienty (např. webovými prohlížeči, mobilními aplikacemi) a více backendovými službami. Zjednodušuje získávání dat tím, že:

• Agreguje data: Kombinuje data z více zdrojů do jedné odpovědi.
• Transformuje data: Přizpůsobuje formáty dat potřebám frontendu.
• Abstrahuje složitost: Skrývá složitost backendových služeb před klientem.
• Vynucuje bezpečnost: Implementuje politiky autentizace a autorizace.
• Optimalizuje výkon: Ukládá často používaná data do mezipaměti a snižuje počet síťových požadavků.

V podstatě implementuje vzor Backend for Frontend (BFF) ve velkém měřítku a dává frontendovým týmům větší kontrolu nad API, která konzumují. Ve větších organizacích může správa a kurátorství vlastních API frontendem vést k rychlejšímu dodávání a snížení závislosti na backendových týmech.

Proč použít GraphQL pro frontendovou API bránu?

GraphQL je dotazovací jazyk pro API a běhové prostředí pro plnění těchto dotazů vašimi stávajícími daty. Nabízí několik výhod oproti tradičním REST API, což jej činí vhodným pro budování frontendových API bran:

• Efektivní získávání dat: Klienti požadují pouze data, která potřebují, což snižuje nadbytečné načítání (over-fetching) a zlepšuje výkon.
• Silné typování: Schémata GraphQL definují strukturu dat, což umožňuje lepší nástroje a validaci.
• Introspekce: Klienti mohou objevovat dostupná data a operace prostřednictvím introspekce schématu.
• Schopnosti v reálném čase: GraphQL subscriptions umožňují aktualizace dat v reálném čase.

Využitím GraphQL může frontendová API brána poskytnout flexibilní, efektivní a pro vývojáře přívětivé rozhraní pro přístup k datům z více backendových služeb. To je v ostrém kontrastu s tradičními přístupy využívajícími více REST endpointů, z nichž každý musí být dotazován jednotlivě a často vrací více dat, než je požadováno.

GraphQL Federation: Distribuovaný přístup

Co je GraphQL Federation?

GraphQL Federation je výkonná technika pro budování distribuovaného GraphQL API skládáním více GraphQL služeb (nazývaných "subgrafy") do jednoho, sjednoceného schématu. Každý subgraf je zodpovědný za konkrétní doménu nebo zdroj dat a federační brána orchestruje dotazy napříč těmito subgrafy.

Základní koncept se točí kolem supergrafu, jediného, sjednoceného GraphQL schématu, které reprezentuje celé API. Tento supergraf je vytvořen skládáním menších GraphQL schémat, nazývaných subgrafy, z nichž každý reprezentuje konkrétní mikroslužbu nebo zdroj dat. Federační brána je zodpovědná za směrování příchozích GraphQL dotazů na příslušné subgrafy a kombinování výsledků do jedné odpovědi.

Jak GraphQL Federation funguje

1. Definice subgrafu: Každá mikroslužba vystavuje GraphQL API (subgraf), které definuje svá vlastní data a operace. Tato schémata obsahují direktivy, které říkají federační bráně, jak resolvovat typy a pole. Klíčové direktivy zahrnují `@key`, `@external` a `@requires`.
2. Složení supergrafu: Federační brána (např. Apollo Gateway) načte schémata z každého subgrafu a složí je do jednoho, sjednoceného schématu (supergrafu). Tento proces zahrnuje řešení konfliktů typů a polí a navazování vztahů mezi typy napříč různými subgrafy.
3. Plánování a provedení dotazu: Když klient pošle GraphQL dotaz na bránu, brána analyzuje dotaz a určí, které subgrafy je třeba dotazovat k naplnění požadavku. Poté distribuuje dotaz na příslušné subgrafy, shromáždí výsledky a zkombinuje je do jedné odpovědi, která je vrácena klientovi.

Příklad: E-commerce platforma s GraphQL Federation

Představte si e-commerce platformu s oddělenými mikroslužbami pro produkty, zákazníky a objednávky.

• Subgraf produktů: Spravuje informace o produktech (název, popis, cena atd.).
• Subgraf zákazníků: Spravuje data o zákaznících (jméno, adresa, e-mail atd.).
• Subgraf objednávek: Spravuje informace o objednávkách (ID objednávky, ID zákazníka, ID produktů, celková částka atd.).

Každý subgraf vystavuje GraphQL API a federační brána tato API skládá do jednoho supergrafu. Klient pak může dotazovat supergraf, aby získal informace o produktech, zákaznících a objednávkách v jednom jediném požadavku.

Například dotaz na získání jména zákazníka a jeho historie objednávek by mohl vypadat takto:

query GetCustomerAndOrders($customerId: ID!) {
  customer(id: $customerId) {
    id
    name
    orders {
      id
      orderDate
      totalAmount
    }
  }
}

Federační brána by tento dotaz přesměrovala na subgrafy Zákazníci a Objednávky, získala potřebná data a zkombinovala je do jedné odpovědi.

Výhody GraphQL Federation

• Zjednodušený přístup k datům: Klienti interagují s jediným GraphQL endpointem, bez ohledu na podkladové zdroje dat.
• Zlepšený výkon: Získávání dat je optimalizováno načítáním pouze nezbytných dat z každého subgrafu.
• Zvýšená škálovatelnost: Každý subgraf může být škálován nezávisle, což umožňuje lepší využití zdrojů.
• Decentralizovaný vývoj: Týmy mohou vyvíjet a nasazovat subgrafy nezávisle, což podporuje agilitu a inovace.
• Správa schématu (governance): Federační brána vynucuje konzistenci a kompatibilitu schémat napříč subgrafy.

Nástroje pro GraphQL Federation

• Apollo Federation: Populární open-source implementace GraphQL Federation, která poskytuje bránu, registr schémat a nástroje pro budování a správu federovaných GraphQL API. Apollo Federation je známá svou škálovatelností a robustním zpracováním chyb.
• GraphQL Hive: Tento nástroj nabízí registr schémat a správu (governance) pro federované služby GraphQL, poskytuje funkce jako detekce změn, analýza využití a kontroly schématu. Zvyšuje viditelnost a kontrolu nad supergrafem.

Schema Stitching: Alternativní přístup

Co je Schema Stitching?

Schema Stitching je další technika pro kombinování více GraphQL schémat do jednoho, sjednoceného schématu. Na rozdíl od Federation, Schema Stitching obvykle zahrnuje manuálnější proces definování, jak jsou typy a pole z různých schémat propojeny. Zatímco Federation je považována za modernější a robustnější řešení, Schema Stitching může být životaschopnou volbou pro jednodušší případy použití nebo při migraci ze stávajících GraphQL API.

Jak Schema Stitching funguje

1. Definice schématu: Každá mikroslužba vystavuje GraphQL API s vlastním schématem.
2. Logika sešívání (stitching): Vrstva pro sešívání (často implementovaná pomocí knihoven jako GraphQL Tools) definuje, jak jsou typy a pole z různých schémat propojeny. To zahrnuje psaní resolver funkcí, které načítají data z podkladových služeb a mapují je na sjednocené schéma.
3. Sjednocené schéma: Vrstva pro sešívání kombinuje jednotlivá schémata do jednoho, sjednoceného schématu, které je vystaveno klientovi.

Příklad: Sešívání produktů a recenzí

Představte si dvě oddělené GraphQL služby: jednu pro produkty a druhou pro recenze.

• Služba produktů: Poskytuje informace o produktech (ID, název, popis, cena).
• Služba recenzí: Poskytuje recenze pro produkty (ID, ID produktu, hodnocení, komentář).

Pomocí Schema Stitching můžete vytvořit sjednocené schéma, které klientům umožní získat informace o produktech a recenzích v jednom dotazu.

Definovali byste resolver funkci ve vrstvě pro sešívání, která načte recenze pro dané ID produktu ze služby recenzí a přidá je k typu Produkt ve sjednoceném schématu.

// Example (Conceptual): Stitching logic using GraphQL Tools
const { stitchSchemas } = require('@graphql-tools/stitch');

const productsSchema = ... // Define your products schema
const reviewsSchema = ... // Define your reviews schema

const stitchedSchema = stitchSchemas({
  subschemas: [
    {
      schema: productsSchema,
    },
    {
      schema: reviewsSchema,
      transforms: [
        {
          transformSchema: (schema) => schema,
          transformRequest: (originalRequest) => {
            return originalRequest;
          },
          transformResult: (originalResult) => {
            return originalResult;
          }
        }
      ],
    },
  ],
  typeDefs: `
    extend type Product {
      reviews: [Review]
    }
  `,
  resolvers: {
    Product: {
      reviews: {
        resolve: (product, args, context, info) => {
          // Fetch reviews for the product from the Reviews Service
          return fetchReviewsForProduct(product.id);
        },
      },
    },
  },
});

Tento příklad demonstruje základní koncept sešívání schémat. Všimněte si potřeby vlastních resolverů pro načtení pole `reviews`. Tato dodatečná režie spojená s kódováním resolverů pro každý vztah může zpomalit vývojový proces ve srovnání s použitím Federation.

Výhody Schema Stitching

• Sjednocené API: Klienti přistupují k jedinému GraphQL endpointu, což zjednodušuje přístup k datům.
• Inkrementální přijetí: Schema Stitching lze implementovat postupně, což vám umožní pozvolna migrovat na sjednocené API.
• Flexibilita: Schema Stitching poskytuje větší kontrolu nad tím, jak jsou schémata kombinována, což vám umožňuje přizpůsobit logiku sešívání specifickým potřebám.

Nevýhody Schema Stitching

• Manuální konfigurace: Schema Stitching vyžaduje manuální konfiguraci logiky sešívání, což může být složité a časově náročné.
• Výkonnostní režie: Resolver funkce mohou přinést výkonnostní režii, zejména pokud zahrnují složité transformace dat.
• Omezená škálovatelnost: Schema Stitching může být obtížnější škálovat než Federation, protože logika sešívání je obvykle centralizovaná.
• Vlastnictví schématu: Může vést k nejasnostem ohledně vlastnictví schématu, zejména pokud různé týmy spravují sešité služby.

Nástroje pro Schema Stitching

• GraphQL Tools: Populární knihovna pro budování a manipulaci s GraphQL schématy, včetně podpory pro Schema Stitching.
• GraphQL Mesh: GraphQL Mesh vám umožňuje používat dotazovací jazyk GraphQL pro přístup k datům z různých zdrojů, jako jsou REST API, databáze a gRPC. Může tato API sešít do sjednoceného GraphQL schématu.

GraphQL Federation vs. Schema Stitching: Srovnání

Jak GraphQL Federation, tak Schema Stitching nabízejí způsoby, jak kombinovat více GraphQL schémat do jednoho API, ale liší se svým přístupem a schopnostmi.

Vlastnost	GraphQL Federation	Schema Stitching
Přístup	Distribuované, automatizované skládání	Centralizovaná, manuální konfigurace
Složitost	Nižší složitost pro údržbu a škálování	Vyšší složitost kvůli manuální logice resolverů
Škálovatelnost	Navrženo pro rozsáhlé, distribuované systémy	Méně škálovatelné, obvykle používané pro menší aplikace
Správa schématu (governance)	Vestavěná správa a validace schématu	Vyžaduje manuální správu a koordinaci schématu
Nástroje	Silný ekosystém nástrojů a knihoven (např. Apollo Federation)	Vyžaduje více vlastních nástrojů a konfigurace
Případy použití	Architektury mikroslužeb, rozsáhlá API, decentralizovaný vývoj	Menší aplikace, inkrementální migrace, specifické požadavky na přizpůsobení

Kdy použít GraphQL Federation: Zvolte Federation, pokud máte složitou architekturu mikroslužeb, potřebujete škálovat své API a chcete umožnit nezávislým týmům spravovat své vlastní subgrafy. Také zjednodušuje správu a řízení schématu.

Kdy použít Schema Stitching: Zvažte Schema Stitching, pokud máte jednodušší API, potřebujete větší kontrolu nad logikou sešívání nebo migrujete ze stávajících GraphQL API. Buďte si však vědomi potenciálních složitostí a omezení škálovatelnosti.

Implementace autentizace a autorizace

Bez ohledu na to, zda si vyberete GraphQL Federation nebo Schema Stitching, implementace autentizace a autorizace je klíčová pro zabezpečení vaší frontendové API brány. Existuje několik přístupů, které můžete zvolit:

• Autentizace na úrovni brány: API brána zpracovává autentizaci a autorizaci před směrováním požadavků na backendové služby. Tento přístup centralizuje bezpečnostní logiku a zjednodušuje backendové služby. Běžné metody zahrnují validaci JWT (JSON Web Token) a OAuth 2.0.
• Autentizace na úrovni služby: Každá backendová služba si zpracovává vlastní autentizaci a autorizaci. Tento přístup poskytuje detailnější kontrolu nad bezpečností, ale může být složitější na správu.
• Hybridní přístup: Kombinace autentizace na úrovni brány a služby. Brána zpracovává počáteční autentizaci a backendové služby provádějí detailnější autorizační kontroly.

Příklad: JWT autentizace s Apollo Federation

S Apollo Federation můžete nakonfigurovat bránu tak, aby validovala JWT tokeny zahrnuté v hlavičkách požadavku. Brána pak může předat informace o uživateli extrahované z tokenu subgrafům, které mohou tyto informace použít pro autorizaci.

// Example (Conceptual): Apollo Gateway configuration with JWT validation
const { ApolloGateway } = require('@apollo/gateway');

const gateway = new ApolloGateway({
  serviceList: [
    // ... your subgraph configurations
  ],
  buildService: ({ name, url }) => {
    return new MyCustomService({
      name,  // Name of the subgraph
      url,   // URL of the subgraph
    });
  },
});

class MyCustomService extends RemoteGraphQLDataSource {
  willSendRequest({ request, context }) {
    // Get the user from the context
    const user = context.user;

    // Add the user's ID to the request headers
    if (user) {
      request.http.headers.set('user-id', user.id);
    }
  }
}

V tomto příkladu je vytvořena vlastní služba pro modifikaci odchozích požadavků tak, aby zahrnovaly ID uživatele odvozené z JWT. Následné služby pak mohou toto ID použít pro autorizační kontroly.

Strategie cachování pro optimalizaci výkonu

Cachování je nezbytné pro zlepšení výkonu frontendové API brány. Ukládáním často používaných dat do mezipaměti můžete snížit zátěž na backendové služby a zlepšit dobu odezvy pro klienty. Zde jsou některé strategie cachování:

• HTTP cachování: Využijte mechanismy HTTP cachování (např. hlavičky `Cache-Control`) pro cachování odpovědí v prohlížeči a na mezilehlých proxy serverech.
• Cachování v paměti: Použijte mezipaměti v paměti (např. Redis, Memcached) pro cachování často používaných dat na bráně.
• CDN cachování: Využijte sítě pro doručování obsahu (CDN) k cachování statických aktiv a API odpovědí blíže ke klientovi.
• Cachování GraphQL dotazů: Cacheujte výsledky GraphQL dotazů na základě jejich dotazovacího řetězce a proměnných. To může být obzvláště efektivní pro často prováděné dotazy. Apollo Server nabízí vestavěnou podporu pro cachování dotazů.

Při implementaci cachování zvažte strategie invalidace mezipaměti, abyste zajistili, že klienti obdrží aktuální data. Běžné strategie zahrnují:

• Expirace na základě času: Nastavte pevně stanovenou dobu expirace pro cachovaná data.
• Invalidace na základě událostí: Invalidujte mezipaměť, když se data změní v backendových službách. Toho lze dosáhnout pomocí webhooků nebo front zpráv.

Monitoring a pozorovatelnost

Monitoring a pozorovatelnost jsou klíčové pro zajištění zdraví a výkonu vaší frontendové API brány. Implementujte komplexní monitoring pro sledování klíčových metrik, jako jsou:

• Latence požadavku: Doba potřebná ke zpracování požadavku.
• Chybovost: Procento požadavků, které vedou k chybám.
• Propustnost: Počet zpracovaných požadavků za jednotku času.
• Využití zdrojů: Využití CPU, paměti a sítě brány a backendových služeb.

Použijte trasování (tracing) ke sledování požadavků, jak procházejí systémem, a identifikujte úzká hrdla a problémy s výkonem. Logování poskytuje cenné informace o chování brány a backendových služeb.

Nástroje pro monitoring a pozorovatelnost zahrnují:

• Prometheus: Open-source systém pro monitoring a upozorňování.
• Grafana: Nástroj pro vizualizaci a monitoring dat.
• Jaeger: Open-source systém pro distribuované trasování.
• Datadog: Platforma pro monitoring a bezpečnost cloudových aplikací.
• New Relic: Platforma pro digitální inteligenci pro monitorování a zlepšování výkonu softwaru.

Implementací robustního monitoringu a pozorovatelnosti můžete proaktivně identifikovat a řešit problémy, čímž zajistíte spolehlivost a výkon vaší frontendové API brány.

Závěr

Frontendová API brána postavená na GraphQL Federation nebo Schema Stitching může výrazně zjednodušit přístup k datům, zlepšit výkon a vylepšit vývojářskou zkušenost v moderních webových aplikacích. GraphQL Federation poskytuje výkonné a škálovatelné řešení pro skládání distribuovaných GraphQL API, zatímco Schema Stitching nabízí flexibilnější přístup pro kombinování existujících schémat. Pečlivým zvážením specifických požadavků vaší aplikace a kompromisů mezi těmito technikami si můžete vybrat nejlepší přístup pro budování robustní a efektivní frontendové API brány.

Nezapomeňte implementovat správnou autentizaci a autorizaci, strategie cachování a monitoring a pozorovatelnost, abyste zajistili bezpečnost, výkon a spolehlivost vaší brány. Přijetím těchto osvědčených postupů můžete odemknout plný potenciál GraphQL a budovat moderní webové aplikace, které poskytují výjimečné uživatelské zážitky.