M

MLOG

Latviešu

Apgūstiet mērogojamus GraphQL shēmas dizaina modeļus, lai veidotu stabilas un uzturamas API, kas apkalpo daudzveidīgu globālo auditoriju. Pārvaldiet shēmu savienošanu, federāciju un modularizāciju.

GraphQL shēmas dizains: mērogojami modeļi globālām API

GraphQL ir kļuvis par spēcīgu alternatīvu tradicionālajām REST API, piedāvājot klientiem elastību pieprasīt tieši tos datus, kas viņiem nepieciešami. Tomēr, kad jūsu GraphQL API pieaug sarežģītībā un apjomā – īpaši, apkalpojot globālu auditoriju ar dažādām datu prasībām – rūpīgs shēmas dizains kļūst izšķirošs uzturēšanai, mērogojamībai un veiktspējai. Šis raksts pēta vairākus mērogojamus GraphQL shēmas dizaina modeļus, lai palīdzētu jums veidot stabilas API, kas spēj tikt galā ar globālas lietojumprogrammas prasībām.

Mērogojama shēmas dizaina nozīme

Labi izstrādāta GraphQL shēma ir veiksmīgas API pamats. Tā nosaka, kā klienti var mijiedarboties ar jūsu datiem un pakalpojumiem. Slikts shēmas dizains var radīt vairākas problēmas, tostarp:

Globālām lietojumprogrammām šīs problēmas tiek pastiprinātas. Dažādiem reģioniem var būt atšķirīgas datu prasības, normatīvie ierobežojumi un veiktspējas gaidas. Mērogojams shēmas dizains ļauj jums efektīvi risināt šīs problēmas.

Mērogojama shēmas dizaina galvenie principi

Pirms iedziļināties konkrētos modeļos, ieskicēsim dažus galvenos principus, kas būtu jāievēro jūsu shēmas dizainā:

Mērogojami shēmas dizaina modeļi

Šeit ir vairāki mērogojami shēmas dizaina modeļi, kurus varat izmantot, lai veidotu stabilas GraphQL API:

1. Shēmu savienošana (Schema Stitching)

Shēmu savienošana ļauj apvienot vairākas GraphQL API vienā, vienotā shēmā. Tas ir īpaši noderīgi, ja dažādas komandas vai pakalpojumi ir atbildīgi par dažādām jūsu datu daļām. Tas ir kā vairākas mini-API, kas savienotas kopā caur 'vārtejas' API.

Kā tas darbojas:

  1. Katra komanda vai pakalpojums nodrošina savu GraphQL API ar savu shēmu.
  2. Centrālais vārtejas pakalpojums izmanto shēmu savienošanas rīkus (piemēram, Apollo Federation vai GraphQL Mesh), lai apvienotu šīs shēmas vienā, vienotā shēmā.
  3. Klienti mijiedarbojas ar vārtejas pakalpojumu, kas novirza pieprasījumus uz atbilstošajām pamatā esošajām API.

Piemērs:

Iedomājieties e-komercijas platformu ar atsevišķām API produktiem, lietotājiem un pasūtījumiem. Katrai API ir sava shēma:

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

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

    # Lietotāju API
    type User {
      id: ID!
      name: String!
      email: String!
    }

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

    # Pasūtījumu API
    type Order {
      id: ID!
      userId: ID!
      productId: ID!
      quantity: Int!
    }

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

Vārtejas pakalpojums var savienot šīs shēmas kopā, lai izveidotu vienotu shēmu:

  
    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
    }

Ievērojiet, kā Order tips tagad ietver atsauces uz User un Product, lai gan šie tipi ir definēti atsevišķās API. Tas tiek panākts ar shēmu savienošanas direktīvām (kā @relation šajā piemērā).

Ieguvumi:

Apsvērumi:

2. Shēmu federācija (Schema Federation)

Shēmu federācija ir shēmu savienošanas evolūcija, kas izstrādāta, lai risinātu dažus tās ierobežojumus. Tā nodrošina deklaratīvāku un standartizētāku pieeju GraphQL shēmu kompozīcijai.

Kā tas darbojas:

  1. Katrs pakalpojums nodrošina GraphQL API un anotē savu shēmu ar federācijas direktīvām (piem., @key, @extends, @external).
  2. Centrālais vārtejas pakalpojums (izmantojot Apollo Federation) izmanto šīs direktīvas, lai izveidotu supergrafu – visas federētās shēmas attēlojumu.
  3. Vārtejas pakalpojums izmanto supergrafu, lai maršrutētu pieprasījumus uz atbilstošajiem pamatā esošajiem pakalpojumiem un atrisinātu atkarības.

Piemērs:

Izmantojot to pašu e-komercijas piemēru, federētās shēmas varētu izskatīties šādi:

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

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

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

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

    # Pasūtījumu 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
    }

Ievērojiet federācijas direktīvu izmantošanu:

Ieguvumi:

Apsvērumi:

3. Modulārs shēmas dizains

Modulārs shēmas dizains ietver lielas, monolītas shēmas sadalīšanu mazākos, vieglāk pārvaldāmos moduļos. Tas atvieglo API atsevišķu daļu saprašanu, modificēšanu un atkārtotu izmantošanu, pat neizmantojot federētās shēmas.

Kā tas darbojas:

  1. Identificējiet loģiskās robežas savā shēmā (piem., lietotāji, produkti, pasūtījumi).
  2. Izveidojiet atsevišķus moduļus katrai robežai, definējot tipus, vaicājumus un mutācijas, kas saistītas ar šo robežu.
  3. Izmantojiet importēšanas/eksportēšanas mehānismus (atkarībā no jūsu GraphQL servera implementācijas), lai apvienotu moduļus vienā, vienotā shēmā.

Piemērs (izmantojot JavaScript/Node.js):

Izveidojiet atsevišķus failus katram modulim:

  
    // 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
    }

Pēc tam apvienojiet tos galvenajā shēmas failā:

  
    // 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;

Ieguvumi:

Apsvērumi:

4. Saskarnes (Interface) un apvienojuma (Union) tipi

Saskarnes un apvienojuma tipi ļauj definēt abstraktus tipus, kurus var implementēt vairāki konkrēti tipi. Tas ir noderīgi, lai attēlotu polimorfus datus – datus, kas var pieņemt dažādas formas atkarībā no konteksta.

Kā tas darbojas:

Piemērs:

  
    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!]!
    }

Šajā piemērā gan User, gan Product implementē Node saskarni, kas definē kopīgu id lauku. SearchResult apvienojuma tips attēlo meklēšanas rezultātu, kas var būt vai nu User, vai Product. Klienti var vaicāt `search` lauku un pēc tam izmantot `__typename` lauku, lai noteiktu, kāda veida rezultātu viņi saņēma.

Ieguvumi:

Apsvērumi:

5. Savienojuma modelis (Connection Pattern)

Savienojuma modelis ir standarta veids, kā implementēt lapošanu GraphQL API. Tas nodrošina konsekventu un efektīvu veidu, kā iegūt lielus datu sarakstus pa daļām.

Kā tas darbojas:

Piemērs:

  
    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!
    }

Ieguvumi:

Apsvērumi:

Globālie apsvērumi

Izstrādājot GraphQL shēmu globālai auditorijai, apsveriet šos papildu faktorus:

Piemēram, apsveriet produkta apraksta lauku:


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

Tas ļauj klientiem pieprasīt aprakstu noteiktā valodā. Ja valoda nav norādīta, tā pēc noklusējuma ir angļu (`en`).

Noslēgums

Mērogojams shēmas dizains ir būtisks, lai veidotu stabilas un uzturamas GraphQL API, kas spēj tikt galā ar globālas lietojumprogrammas prasībām. Ievērojot šajā rakstā izklāstītos principus un izmantojot atbilstošus dizaina modeļus, jūs varat izveidot API, kas ir viegli saprotamas, modificējamas un paplašināmas, vienlaikus nodrošinot izcilu veiktspēju un mērogojamību. Atcerieties modularizēt, komponēt un abstrahēt savu shēmu, kā arī ņemt vērā savas globālās auditorijas specifiskās vajadzības.

Pieņemot šos modeļus, jūs varat atraisīt pilnu GraphQL potenciālu un veidot API, kas var darbināt jūsu lietojumprogrammas vēl daudzus gadus.

GraphQL shēmas dizains: mērogojami modeļi globālām API | MLOG