⭐ [Enhancement]: Add Compression

[JerryNixon]

Data API builder does not currently support response compression (e.g., gzip or brotli), which can significantly reduce payload size and improve performance over slow or high-latency networks. Compression is especially beneficial for large JSON responses, common in REST and GraphQL endpoints. Adding support at the server level—either via built-in middleware or integration guidance—would help DAB serve clients more efficiently. This is a common feature in modern web APIs and would be a strong addition to the roadmap.

Sample request

GET /api/employees HTTP/1.1  
Host: api.example.com  
Accept-Encoding: gzip, deflate, br  

Sample response

HTTP/1.1 200 OK  
Content-Encoding: gzip  
Content-Type: application/json  
Content-Length: 920  

Payload impact

Payload Type	Uncompressed (bytes)	Gzipped (bytes)	Compression Savings
Large JSON array	4,356	920	~79%

Configuration Update

{
    "runtime": {
        "compression": {
            "level": "fastest" | "optimal" | "none" <default: optimal>
        }
    }
}

CLI update

dab configure --runtime.compression.level fastest

Starter JSON Schema section

{
  "runtime": {
    "type": "object",
    "properties": {
      "compression": {
        "type": "object",
        "description": "Configures HTTP response compression settings.",
        "properties": {
          "level": {
            "type": "string",
            "enum": ["fastest", "optimal", "none"],
            "default": "optimal",
            "description": "Specifies the response compression level."
          }
        },
        "additionalProperties": false
      }
    }
  }
}

Basic ASPNET implementation

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCompression(options =>
{
    options.EnableForHttps = true;
    options.Providers.Add<GzipCompressionProvider>();
});
builder.Services.Configure<GzipCompressionProviderOptions>(options =>
{
    options.Level = CompressionLevel.Fastest;
});

var app = builder.Build();

app.UseResponseCompression();

// map endpoints and controllers

app.Run();

FAQ

1. Is this backwards compatible?
   Yes. Clients that don’t request compression (via Accept-Encoding) receive uncompressed responses exactly as before.

2. Does this require a special client?
   No. Most modern browsers and HTTP clients (like curl, Postman, fetch, axios) already support compressed responses out-of-the-box.

3. Does this impact controller logic?
   No. Compression is handled at the middleware level, completely separate from your controller logic or data access code.

4. What is the compute cost compared to bandwidth savings?
   Compression uses CPU but reduces payload size dramatically. In most APIs, the tradeoff favors compression—especially for large or repetitive JSON responses. The CompressionLevel.Fastest option balances speed and size.

5. Does this work over HTTPS?
   Yes. Response compression is fully supported over HTTPS and can be explicitly enabled with EnableForHttps = true.

6. Can it be customized for specific MIME types?
   Yes. You can add custom MIME types (e.g., application/graphql+json) if needed.

7. What compression formats are supported?
   Gzip is most common, but Brotli and Deflate are also supported in ASP.NET Core with the appropriate providers.

8. Does it work with REST and GraphQL?
   Yes. Compression applies to all HTTP responses regardless of the endpoint type, including both REST and GraphQL APIs.

9. Does Hot Chocolate support it?
   Hot Chocolate runs on ASP.NET Core and inherits its middleware pipeline, so response compression works with it automatically—no special configuration needed in Hot Chocolate itself.