M

MLOG

Eesti

Õppige skaleeruvaid GraphQL skeemi disainimustreid, et ehitada vastupidavaid ja hooldatavaid API-sid globaalsele publikule. Hallake skeemide ühendamist ja föderatsiooni.

GraphQL skeemi disain: skaleeruvad mustrid globaalsetele API-dele

GraphQL on kujunenud võimsaks alternatiiviks traditsioonilistele REST API-dele, pakkudes klientidele paindlikkust küsida täpselt neid andmeid, mida nad vajavad. Kuid kui teie GraphQL API kasvab keerukuselt ja ulatuselt – eriti teenindades globaalset publikut mitmekesiste andmenõuetega – muutub hoolikas skeemi disain hooldatavuse, skaleeruvuse ja jõudluse seisukohalt ülioluliseks. See artikkel uurib mitmeid skaleeruvaid GraphQL skeemi disaini mustreid, mis aitavad teil ehitada vastupidavaid API-sid, mis suudavad tulla toime globaalse rakenduse nõudmistega.

Skaleeruva skeemidisaini olulisus

Hästi disainitud GraphQL skeem on eduka API aluseks. See dikteerib, kuidas kliendid saavad teie andmete ja teenustega suhelda. Kehv skeemi disain võib põhjustada mitmeid probleeme, sealhulgas:

Globaalsete rakenduste puhul on need probleemid võimendatud. Erinevatel piirkondadel võivad olla erinevad andmenõuded, regulatiivsed piirangud ja jõudluse ootused. Skaleeruv skeemi disain võimaldab teil nende väljakutsetega tõhusalt toime tulla.

Skaleeruva skeemidisaini põhiprintsiibid

Enne konkreetsetesse mustritesse sukeldumist toome välja mõned põhiprintsiibid, mis peaksid teie skeemi disaini suunama:

Skaleeruvad skeemidisaini mustrid

Siin on mitu skaleeruvat skeemi disaini mustrit, mida saate kasutada vastupidavate GraphQL API-de ehitamiseks:

1. Skeemide ühendamine (Schema Stitching)

Skeemide ühendamine võimaldab teil kombineerida mitu GraphQL API-d üheks, ühtseks skeemiks. See on eriti kasulik, kui teil on erinevad meeskonnad või teenused, mis vastutavad teie andmete erinevate osade eest. See on nagu mitu mini-API-d, mis on lüüsi (gateway) API kaudu omavahel ühendatud.

Kuidas see töötab:

  1. Iga meeskond või teenus eksponeerib oma GraphQL API koos oma skeemiga.
  2. Keskne lüüsiteenus kasutab skeemide ühendamise tööriistu (nagu Apollo Federation või GraphQL Mesh), et liita need skeemid üheks, ühtseks skeemiks.
  3. Kliendid suhtlevad lüüsiteenusega, mis suunab päringud vastavatesse alus-API-desse.

Näide:

Kujutage ette e-kaubanduse platvormi, millel on eraldi API-d toodete, kasutajate ja tellimuste jaoks. Igal API-l on oma skeem:

  
    # Toodete API
    type Product {
      id: ID!
      name: String!
      price: Float!
    }

    type Query {
      product(id: ID!): Product
    }

    # Kasutajate API
    type User {
      id: ID!
      name: String!
      email: String!
    }

    type Query {
      user(id: ID!): User
    }

    # Tellimuste API
    type Order {
      id: ID!
      userId: ID!
      productId: ID!
      quantity: Int!
    }

    type Query {
      order(id: ID!): Order
    }

Lüüsiteenus saab need skeemid kokku ühendada, et luua ühtne skeem:

  
    type Product {
      id: ID!
      name: String!
      price: Float!
    }

    type User {
      id: ID!
      name: String!
      email: String!
    }

    type Order {
      id: ID!
      user: User! @relation(field: "userId")
      product: Product! @relation(field: "productId")
      quantity: Int!
    }

    type Query {
      product(id: ID!): Product
      user(id: ID!): User
      order(id: ID!): Order
    }

Pange tähele, kuidas Order tüüp sisaldab nüüd viiteid User ja Product tüüpidele, kuigi need tüübid on määratletud eraldi API-des. See saavutatakse skeemide ühendamise direktiivide abil (nagu @relation selles näites).

Eelised:

Kaalutlused:

2. Skeemide föderatsioon (Schema Federation)

Skeemide föderatsioon on skeemide ühendamise edasiarendus, mis on loodud mõnede selle piirangute lahendamiseks. See pakub deklaratiivsemat ja standardiseeritumat lähenemist GraphQL skeemide komponeerimiseks.

Kuidas see töötab:

  1. Iga teenus eksponeerib GraphQL API ja annoteerib oma skeemi föderatsiooni direktiividega (nt @key, @extends, @external).
  2. Keskne lüüsiteenus (kasutades Apollo Federationi) kasutab neid direktiive, et ehitada supergraaf – kogu födereeritud skeemi esitus.
  3. Lüüsiteenus kasutab supergraafi, et suunata päringud vastavatesse alusteenustesse ja lahendada sõltuvusi.

Näide:

Kasutades sama e-kaubanduse näidet, võivad födereeritud skeemid välja näha järgmiselt:

  
    # Toodete API
    type Product @key(fields: "id") {
      id: ID!
      name: String!
      price: Float!
    }

    type Query {
      product(id: ID!): Product
    }

    # Kasutajate API
    type User @key(fields: "id") {
      id: ID!
      name: String!
      email: String!
    }

    type Query {
      user(id: ID!): User
    }

    # Tellimuste API
    type Order {
      id: ID!
      userId: ID!
      productId: ID!
      quantity: Int!
      user: User! @requires(fields: "userId")
      product: Product! @requires(fields: "productId")
    }

    extend type Query {
      order(id: ID!): Order
    }

Pange tähele föderatsiooni direktiivide kasutamist:

Eelised:

Kaalutlused:

3. Modulaarne skeemi disain

Modulaarne skeemi disain hõlmab suure, monoliitse skeemi jaotamist väiksemateks, paremini hallatavateks mooduliteks. See muudab API üksikute osade mõistmise, muutmise ja taaskasutamise lihtsamaks, isegi ilma födereeritud skeemidele tuginemata.

Kuidas see töötab:

  1. Tuvastage oma skeemis loogilised piirid (nt kasutajad, tooted, tellimused).
  2. Looge iga piiri jaoks eraldi moodulid, määratledes selle piiriga seotud tüübid, päringud ja mutatsioonid.
  3. Kasutage import/eksport mehhanisme (sõltuvalt teie GraphQL serveri implementatsioonist), et kombineerida moodulid üheks, ühtseks skeemiks.

Näide (kasutades JavaScripti/Node.js-i):

Looge iga mooduli jaoks eraldi failid:

  
    // users.graphql
    type User {
      id: ID!
      name: String!
      email: String!
    }

    type Query {
      user(id: ID!): User
    }

    // products.graphql
    type Product {
      id: ID!
      name: String!
      price: Float!
    }

    type Query {
      product(id: ID!): Product
    }

Seejärel kombineerige need oma peamises skeemifailis:

  
    // schema.js
    const { makeExecutableSchema } = require('graphql-tools');
    const { typeDefs: userTypeDefs, resolvers: userResolvers } = require('./users');
    const { typeDefs: productTypeDefs, resolvers: productResolvers } = require('./products');

    const typeDefs = [
      userTypeDefs,
      productTypeDefs,
      ""
    ];

    const resolvers = {
      Query: {
        ...userResolvers.Query,
        ...productResolvers.Query,
      }
    };

    const schema = makeExecutableSchema({
      typeDefs,
      resolvers,
    });

    module.exports = schema;

Eelised:

Kaalutlused:

4. Liidese- ja ühendtüübid (Interface and Union Types)

Liidese- ja ühendtüübid võimaldavad teil määratleda abstraktseid tüüpe, mida saab implementeerida mitme konkreetse tüübiga. See on kasulik polümorfsete andmete esitamiseks – andmete, mis võivad kontekstist sõltuvalt võtta erinevaid vorme.

Kuidas see töötab:

Näide:

  
    interface Node {
      id: ID!
    }

    type User implements Node {
      id: ID!
      name: String!
      email: String!
    }

    type Product implements Node {
      id: ID!
      name: String!
      price: Float!
    }

    union SearchResult = User | Product

    type Query {
      node(id: ID!): Node
      search(query: String!): [SearchResult!]!
    }

Selles näites implementeerivad nii User kui ka Product liidest Node, mis määratleb ühise välja id. Ühendtüüp SearchResult esindab otsingutulemust, mis võib olla kas User või Product. Kliendid saavad pärida välja `search` ja seejärel kasutada välja `__typename`, et määrata, millist tüüpi tulemuse nad said.

Eelised:

Kaalutlused:

5. Ühenduse muster (Connection Pattern)

Ühenduse muster on standardne viis pagineerimise (lehekülgedeks jaotamise) implementeerimiseks GraphQL API-des. See pakub järjepidevat ja tõhusat viisi suurte andmeloendite hankimiseks osade kaupa.

Kuidas see töötab:

Näide:

  
    type User {
      id: ID!
      name: String!
      email: String!
    }

    type UserEdge {
      node: User!
      cursor: String!
    }

    type UserConnection {
      edges: [UserEdge!]!
      pageInfo: PageInfo!
    }

    type PageInfo {
      hasNextPage: Boolean!
      hasPreviousPage: Boolean!
      startCursor: String
      endCursor: String
    }

    type Query {
      users(first: Int, after: String, last: Int, before: String): UserConnection!
    }

Eelised:

Kaalutlused:

Globaalsed kaalutlused

GraphQL skeemi disainimisel globaalsele publikule arvestage nende täiendavate teguritega:

Näiteks kaaluge tootekirjelduse välja:


type Product {
 id: ID!
 name: String!
 description(language: String = "en"): String!
}

See võimaldab klientidel küsida kirjeldust kindlas keeles. Kui keelt pole määratud, kasutatakse vaikimisi inglise keelt (`en`).

Kokkuvõte

Skaleeruv skeemi disain on hädavajalik vastupidavate ja hooldatavate GraphQL API-de ehitamiseks, mis suudavad tulla toime globaalse rakenduse nõudmistega. Järgides selles artiklis kirjeldatud põhimõtteid ja kasutades sobivaid disainimustreid, saate luua API-sid, mida on lihtne mõista, muuta ja laiendada, pakkudes samal ajal suurepärast jõudlust ja skaleeruvust. Pidage meeles oma skeemi modulariseerida, komponeerida ja abstraheerida ning arvestada oma globaalse publiku spetsiifiliste vajadustega.

Neid mustreid omaks võttes saate avada GraphQL-i täieliku potentsiaali ja ehitada API-sid, mis suudavad teie rakendusi toetada aastaid.

GraphQL skeemi disain: skaleeruvad mustrid globaalsetele API-dele | MLOG