Dela via

Nyheter i Data API Builder 1.6

Den här inkrementella versionen fokuserar på cachelagring på flera nivåer, utökad loggning och observerbarhet, hemlig hantering och förbättringar av fråge-/sidnumrering.

Introduktion: Cachelagring på nivå 2 (distribuerad)

Data API Builder har länge haft stöd för nivå 1 (L1) i- minnescachen och cacherelaterade HTTP-begärandehuvuden som no-store, no-cache, och only-if-cached för att påverka cachebeteendet.

I den här versionen har vi lagt till distribuerad cache på nivå 2 (L2).

Global körningskonfiguration:

{
  "runtime": {
    "cache": {
      "enabled": true,
      "ttl-seconds": 30,
      "level-2": {
        "enabled": true,
        "provider": "redis",
        "connection-string": "localhost:6379",
        "partition": "prod-api"
      }
    }
  }
}

Entitetsspecifika åsidosättningar:

{
  "entities": {
    "Products": {
      "source": "dbo.Products",
      "cache": { "enabled": true, "ttl-seconds": 120, "level": "L1L2" }
    },
    "Orders": {
      "source": "dbo.Orders",
      "cache": { "enabled": true, "level": "L1" }
    }
  }
}

Cachenivå L1L2

TL;DRL1L2 = Begäran → L1 → L2 → DB → L2 → L1 → Svar

Som standard använder en entitet med cachelagring aktiverat nivå L1L2. L1 är cacheminnet per process i minnet. L2 är det distribuerade cachelagret (för närvarande Redis) plus ett bakplan för enhetlighet mellan instanser. Med L1L2 utför en cachesökning först en kontroll av L1. Vid en L1 träffmiss kontrollerar L2 om nivå 2-cachelagring är globalt aktiverad och konfigurerad. Om posten inte finns i något av de båda lagren kör DAB databasfrågan. Resultatet lagras i både L1 och L2 (dubbel skrivning). Framtida begäranden på samma instans hanteras från lokala L1.

Begäranden i andra systeminstanser kan hämta från L2 och överföra posten till sin egen L1. Om den lokala containern återvinns undviker en L1 miss följt av en L2 träff fortfarande en databasrundresa, vilket resulterar i en varm distribuerad cache. Om L2 inte är aktiverat globalt fungerar en entitet som L1L2 beter sig som L1. En valfri partitionsinställning innehåller Redis-nycklar och backplanskanalen så att endast containrar som delar partitionen deltar i samma distribuerade cacheutrymme.

Introduktion: Flexibel loggning

Före version 1.5 var utvecklare föremål för standardloggnivåerna och filtren hårdkodade i DAB. Vi stöder nu konfigurerbara filter och nivåer för loggar som genereras av motorn.

Nu, i version 1.6, lägger vi till i vår lista över sänkor. Förutom Application Insights och OpenTelemetry-publicering har Data API Builder nu stöd för både fil- och Azure Log Analytics som mål. Omfattande, konfigurerbar loggning var du än behöver den.

{
  "telemetry": {
      "log-level": { },
      "open-telemetry": { },
      "application-insights": { },
      "azure-log-analytics": { }, // new!
      "file": { } // new!
    }
  }
}

Filsänka

Tidigare var DAB-utvecklare främst begränsade till konsolloggar i containern. Med version 1.6 kan du nu skicka loggar till lokala filer i en containermapp för att systematiskt felsöka och observera DAB-beteende i önskad övervakningslösning. Att montera en containervolym som målmapp är ett enkelt sätt att bevara loggar över containerns livscykel.

Exempel på konfiguration av filesänk:

{
  "runtime": {
    "telemetry": {
        "file": {
          "enabled": ...,               // Turn file logging on or off
          "path": ...,                  // Folder path for log files
          "rolling-interval": ...,      // How often a new log file is created
          "retained-file-count-limit": ..., // Max number of log files to keep
          "file-size-limit-bytes": ..., // Max size of a log file before rolling
        }
      }
    }
  }
}

Azure Log Analytics-mottagare

Företagsutvecklare ställs ofta inför strängare krav än vad lokal felsökning kan uppfylla. Många organisationer kräver centraliserad loggning, efterlevnadsgranskning och integrering med lösningar för företagsövervakning. För att stödja dessa scenarier integreras Data API Builder med Azure Log Analytics. Loggar flödar in i en säker, centraliserad plattform som överensstämmer med företagsprinciper för kvarhållning, styrning och observerbarhet.

Exempel på konfiguration av Azure Log Analytics-mottagare:

{
  "telemetry": {
    "azure-log-analytics": {
      "enabled": ...,                 // Turn logging on or off
      "auth": {
        "workspace-id": ...,          // Workspace ID
        "dcr-immutable-id": ...,      // Data Collection Rule
        "dce-endpoint": ...           // Data Collection Endpoint
      },
      "dab-identifier": ...,          // Unique string to identify log source
      "flush-interval-seconds": ...   // How often logs are flushed
    }
  }
}

Kontra Application Insights

Där Application Insights fokuserar på övervakning av appprestanda (APM) ger Azure Log Analytics bredare täckning. Den aggregerar loggar från appar, Azure-resurser, virtuella datorer, containrar, nätverk och säkerhetsverktyg. Dessa loggar är centraliserade på en arbetsyta för KQL-frågor (Kusto Query Language), korrelation och efterlevnad.

Förbättringar av sökfråga och paginering

Introduktion: IN-operator (SQL-backend, GraphQL)

DAB:s nya IN operatör förenklar filtrering av flera värden i GraphQL-frågor. Det minskar länkade OR filter och genererar renare SQL. Den här funktionen är en del av DAB:s GraphQL-syntax och finns ännu inte i DAB:s REST-syntax $filter .

query {
  products(filter: { status: { in: ["ACTIVE", "PENDING"] } }) {
    items { id name status }
  }
}

MED DAB:s nya relativa nextLink alternativ kan utvecklare konfigurera motorn så att den genererar relativa länkar i stället för absoluta länkar. Den här funktionen, en vanlig community-begäran, är särskilt användbar i scenarier med omvänd proxy och domänomskrivning där relativa länkar förhindrar felaktiga värdnamn.

{
  "runtime": {
    "pagination": {
      "next-link-relative": true // default is false
    }
  }
}
  • När next-link-relative är true, är nextLink relativ och börjar med /.
  • När falseblir det en absolut URL.

Hälsokontroller

För att leverera en snabbare sammansatt status körs nu hälsokontroller för Data API Builder parallellt. Detta minskar svarstiden i distributioner med flera källor, särskilt när flera slutpunkter är inblandade och hälsokontroller används för att fastställa distributionsstatusen för DAB-containern, till exempel i .NET Aspire-programvärden.

Exempel på DOP-konfiguration för hälsa:

{
  "runtime": {
    "health": {
      "max-query-parallelism": 8 
    }
  }
}
Konfiguration Minimi Förinställning Maximum
max-query-parallelism 1 4 8

DWSQL-principer

Data API Builder tillät alltid utvecklare att konfigurera principer på API-nivå. Dessa principer läggs till som extra predikat för frågans WHERE-sats och stöd @item och @claim förhör, vilket ger avancerad säkerhet på radnivå utan att kräva databasändringar.

Med version 1.6 utökar Data API Builder den här funktionen till Azure SQL Data Warehouse (dwsql), en datakälla som redan stöds men utan principintegrering förrän nu. Utvecklare kan nu definiera principer som bringar DWSQL i linje med andra SQL-databastyper.

Exempelentitet med principkonfiguration:

{
  "entities": {
    "Orders": {
      "source": "dbo.Orders",
      "permissions": [
        {
          "role": "authenticated",
          "actions": [ "read" ],
          "policy": "@item.Region = @claim.region"
        }
      ]
    }
  }
}

I det här exemplet, när en authenticated användare frågar Orders, lägger motorn till WHERE Region = <user's claim:region> automatiskt.