Delen via

Wat is er nieuw in Data API Builder 1.6

Deze incrementele release is gericht op caching met meerdere lagen, uitgebreide logboekregistratie en waarneembaarheid, geheimbeheer en verbeteringen in query's/paginering.

Introductie: Niveau 2 Cache (Gedistribueerd)

Data API Builder heeft lang ondersteunde cache van niveau 1 (L1) in het geheugen en cachegerelateerde HTTP-aanvraagheaders zoals no-store, no-cacheen only-if-cached om het cachegedrag te beïnvloeden.

In deze release hebben we gedistribueerde cache op niveau 2 (L2) toegevoegd.

Globale runtimeconfiguratie:

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

Entiteitsspecifieke overschrijvingen:

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

Cacheniveau L1L2

TL;DRL1L2 = Request → L1 → L2 → DB → L2 → L1 → Response

Een entiteit waarvoor caching is ingeschakeld, maakt standaard gebruik van niveau L1L2. L1 is de cache per proces in het geheugen. L2 is de gedistribueerde cachelaag (momenteel Redis) plus een backplane voor coherentie tussen exemplaren. Met L1L2 controleert een cachelookup eerst L1. Bij een L1 miss wordt gecontroleerd L2 of caching op niveau 2 globaal is ingeschakeld en geconfigureerd. Als de vermelding zich niet in een van beide lagen bevindt, voert DAB de databasequery uit. Het resultaat wordt opgeslagen in zowel L1 als L2 (dubbele schrijfbewerking). Toekomstige aanvragen op hetzelfde exemplaar worden bediend vanuit lokaal L1.

Aanvragen op andere exemplaren kunnen van L2 ophalen en de vermelding in hun eigen L1 promoveren. Als de lokale container wordt gerecycled, vermijdt een L1 miss gevolgd door een L2 hit nog steeds een ronde trip naar de database, zodat u een warme gedistribueerde cache hebt. Als L2 niet globaal is ingeschakeld, gedraagt een entiteit zich ingesteld op L1L2 als L1. Een optionele partitie-instelling scheidt Redis-sleutels en het backplane-kanaal, zodat alleen containers die die partitie delen deelnemen aan dezelfde gedistribueerde cacheruimte.

Inleiding: Flexibele logboekregistratie

Vóór release 1.5 waren ontwikkelaars onderworpen aan de standaardlogboekniveaus en filters die in DAB zijn vastgelegd. We ondersteunen nu configureerbare filters en niveaus voor logboeken die door de engine worden verzonden.

In release 1.6 voegen we nu toe aan onze lijst met sinks. Naast het publiceren van Application Insights en OpenTelemetry biedt Data API Builder nu ondersteuning voor zowel bestanden als Azure Log Analytics als doelen. Uitgebreide, configureerbare logboekregistratie waar u deze nodig hebt.

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

Bestandsdoel

Voorheen waren DAB-ontwikkelaars meestal beperkt tot consolelogboeken in de container. Met release 1.6 kunt u nu logboeken wegschrijven naar lokale bestanden in een containermap om systematisch te troubleshooten en DAB-gedrag te observeren in uw favoriete monitoringsoplossing. Het koppelen van een containervolume als doelmap is een eenvoudige manier om logboeken in de levenscyclus van containers te behouden.

Voorbeeld van configuratie van bestandssink:

{
  "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-Sink

Bedrijfsontwikkelaars hebben vaak te maken met strengere vereisten dan aan lokale foutopsporing kan voldoen. Veel organisaties verplichten gecentraliseerde logboekregistratie, compliancecontrole en integratie met bedrijfsbewakingsoplossingen. Ter ondersteuning van deze scenario's kan Data API Builder worden geïntegreerd met Azure Log Analytics. Logboeken stromen over naar een beveiligd, gecentraliseerd platform dat overeenkomt met bedrijfsbeleid voor retentie, governance en waarneembaarheid.

Voorbeeld van azure Log Analytics-sinkconfiguratie:

{
  "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
    }
  }
}

Versus Application Insights

Waar Application Insights zich richt op app-prestatiebewaking (APM), biedt Azure Log Analytics een bredere dekking. Hiermee worden logboeken samengevoegd van apps, Azure-resources, VM's, containers, netwerken en beveiligingshulpprogramma's. Deze logboeken worden gecentraliseerd in een werkruimte voor KQL-query's (Kusto Query Language), correlatie en naleving.

Verbeteringen aan query's en paginering

Inleiding: IN-operator (SQL backends, GraphQL)

Met de nieuwe IN operator van DAB kunt u filteren met meerdere waarden in GraphQL-query's vereenvoudigen. Het vermindert gekoppelde filters, waardoor schonere OR SQL wordt gegenereerd. Deze functie maakt deel uit van de GraphQL-syntaxis van DAB en bevindt zich nog niet in de REST-syntaxis $filter van DAB.

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

Met de nieuwe relatieve nextLink optie van DAB kunnen ontwikkelaars de engine configureren om relatieve koppelingen te verzenden in plaats van absolute koppelingen. Deze functie, een frequente communityaanvraag, is vooral handig in scenario's voor reverse proxy en het herschrijven van domeinen waarbij relatieve koppelingen niet-overeenkomende hostnamen voorkomen.

{
  "runtime": {
    "pagination": {
      "next-link-relative": true // default is false
    }
  }
}
  • Wanneer next-link-relative true is, zal nextLink relatief ten opzichte van / zijn (begin met /).
  • Wanneer false, is het een absolute URL.

Gezondheidscontroles

Als u een snellere samengestelde status wilt leveren, worden statuscontroles van Data API Builder nu parallel uitgevoerd. Dit vermindert de latentie in implementaties met meerdere bronnen, met name wanneer er verschillende eindpunten betrokken zijn en statuscontroles worden gebruikt om de implementatiestatus van de DAB-container te bepalen, zoals in de .NET Aspire-toepassingshost.

Voorbeeld van een Health DOP-configuratie:

{
  "runtime": {
    "health": {
      "max-query-parallelism": 8 
    }
  }
}
Configuratie Minimaal Verstek Maximum
max-query-parallelism 1 4 8

DWSQL-beleid

Data API Builder heeft ontwikkelaars altijd toegestaan beleid op API-niveau te configureren. Deze beleidsregels worden toegevoegd als extra predicaten aan de WHERE-clausule van de query en ondersteunen @item en @claim ondervraging, die geavanceerde beveiliging op rijniveau biedt zonder dat er databasewijzigingen nodig zijn.

Met release 1.6 breidt Data API Builder deze mogelijkheid uit naar Azure SQL Data Warehouse (dwsql), een gegevensbron die tot nu toe al wordt ondersteund, maar zonder beleidsintegratie. Ontwikkelaars kunnen nu beleidsregels definiëren die DWSQL in overeenstemming brengen met andere SQL-databasetypen.

Voorbeeldentiteit met beleidsconfiguratie:

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

Wanneer een authenticated gebruikerOrders in dit voorbeeld opvraagt, voegt de engine WHERE Region = <user's claim:region> automatisch toe.

  • Last updated on