APISIX 3.2.0 is the first LTS version since the 3.0 major version. This release is a major milestone for the 3.x era to replace the 2.x era. From then on, a new series of patch versions will be released on the basis of 3.2. This release, as usual, brings many new plug-ins and features, bringing different new ways to play for APISIX users.

New Feature: Service Discovery on Layer 4

Only a few gateways support service discovery, and APISIX is one of them. In the 3.2.0 version, APISIX has implemented the function of service discovery on the original seven layers to four layers. In this way, APISIX can also enjoy the convenience brought by service discovery when using APISIX as a TCP/UDP proxy.Like service discovery on the seventh layer, in order to use service discovery, we need to first config.yaml Configure the address of the service discovery server in:

discovery:
  nacos:
    host:
      - "http://192.168.33.1:8848"

Then configure it on the specific upstream discovery_type and service_name:

$ curl http://127.0.0.1:9180/apisix/admin/stream_routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "remote_addr": "127.0.0.1",
    "upstream": {
        "scheme": "tcp",
        "discovery_type": "nacos",
        "service_name": "APISIX-NACOS",
        "type": "roundrobin"
    }
}'

In this way, when accessing stream_routes, the upstream node will get it from the APISIX-NACOS service of Nacos.

New plugin: RESTful request to GraphQL

In version 3.2, APISIX added a plugin that converts RESTful requests into GraphQL. Suppose you have a GraphQL query like this:

query($name: String!, $githubAccount: String!) {
  persons(filter: { name: $name, githubAccount: $githubAccount }) {
    id
    name
    blog
    githubAccount
    talks {
      id
      title
    }
  }
}

in $name and $githubAccount are two GraphQL variables.

We can expose the same RESTful interface with the following configuration:

curl --location --request PUT 'http://localhost:9180/apisix/admin/routes/1' \\
--header 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' \\
--header 'Content-Type: application/json' \\
--data-raw '{
    "uri": "/graphql",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:8080": 1
        }
    },
    "plugins": {
        "degraphql": {
            "query": "query($name: String!, $githubAccount: String!) {\\n  persons(filter: { name: $name, githubAccount: $githubAccount }) {\\n    id\\n    name\\n    blog\\n    githubAccount\\n    talks {\\n      id\\n      title\\n    }\\n  }\\n}",
            "variables": [
                "name",
                "githubAccount"
            ]
        }
    }
}'

here query is the query statement we want to use,variables is a list of previously declared variables.

It can then be accessed as a RESTful interface:

curl --location --request POST 'http://localhost:9080/graphql' \\
--header 'Content-Type: application/json' \\
--data-raw '{
    "name": "Niek",
    "githubAccount": "npalm"
}'

The result is the same as directly accessing the upstream with the corresponding GraphQL statement:

{
  "data": {
    "persons": [
      {
        "id": "7",
        "name": "Niek",
        "blog": "https://040code.github.io",
        "githubAccount": "npalm",
        "talks": [
          {
            "id": "19",
            "title": "GraphQL - The Next API Language"
          },
          {
            "id": "20",
            "title": "Immutable Infrastructure"
          }
        ]
      }
    ]
  }
}

You can also use the GET request to access the same interface, at this time the parameters need to be passed through the query string:

curl 'http://localhost:9080/graphql?name=Niek&githubAccount=npalm'

New feature: support for setting log format on each log plugin

In version 3.2, we sorted out more than ten access log plug-ins of APISIX. Each plugin now supports configuring custom log formats:

1. Define the global log format in the plugin metadata of the plugin
2. Define the log format of the current route in the configuration of the plugin on the specific routing rule

by clickhouse-logger For example, the following is how to define the global log format:

curl http://127.0.0.1:9180/apisix/admin/plugin_metadata/clickhouse-logger \\
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "log_format": {
        "host": "$host",
        "@timestamp": "$time_iso8601",
        "client_ip": "$remote_addr"
    }
}'

The following is the log format of the current route:

curl http://127.0.0.1:9180/apisix/admin/routes/1 \\
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
      "plugins": {
            "clickhouse-logger": {
                "log_format": {
                    "host": "$host",
                    "@timestamp": "$time_iso8601",
                    "client_ip": "$remote_addr"
                },
                "user": "default",
                "password": "a",
                "database": "default",
                "logtable": "test",
                "endpoint_addrs": ["http://127.0.0.1:8123"]
            }
       },
      "upstream": {
           "type": "roundrobin",
           "nodes": {
               "127.0.0.1:1980": 1
           }
      },
      "uri": "/hello"
}'

New plugin: request body/response body conversion

Are you struggling with how to introduce ancient upstream services that return XML to modern clients that only accept JSON? New in version 3.2.0 body-transformer The plug-in open source solves this problem.

body-transformer The plugin supports conversion between JSON and XML. But that’s not the only thing it can do. It also supports configuring the specific format of the input and output content through templates. for example,

Suppose you have the following JSON template:{"foo":"{{name .. " world"}}","bar":{{age+10}}}and configure it to body-transformer plug-in request.template field:

      ...
      "body-transformer": {
          "request": {
              "template": "..."
          }
      }
      ...

Then when the request content is {"name":"hello","age":20}what is sent upstream is the rewritten {"foo":"hello world","bar":30}.we adopted lua-resty-template to render templates, so you can embed Lua expressions in templates to implement rewriting logic.

The rewriting of upstream output is also similar, except that the plug-in needs to be configured response.template field.

New features: optimizations and more small features

In addition to the several major features mentioned above, this release also includes many changes worth mentioning:

• error-log-logger Plugin supports sending error logs to Kafka
• limit-count Plugin support returns X-RateLimit-Reset response header

etc.

If you are interested in the complete content, please refer to the CHANGELOG released in 3.2: https://github.com/apache/apisix/blob/release/3.2/docs/zh/latest/CHANGELOG.md#320