apisix VS Lua

> I think etcd is basically a k8s only project now

I hate etcd with the best of them, but etcd is used in a lot more places than just kubernetes:

https://github.com/apache/apisix/blob/master/docs/en/latest/...

https://github.com/traefik/traefik#:~:text=Etcd,

https://github.com/zalando/patroni#patroni-a-template-for-po...

https://github.com/purpleidea/mgmt/tree/0.0.26/etcd (this one shows up on HN quite a bit)

https://github.com/sorintlab/stolon#features

It's actually one of the major reasons I wouldn't touch those projects

Through this intelligent caching mechanism, APISIX efficiently utilizes system resources when handling a large volume of requests, thereby improving overall system performance and stability. APISIX, with its advanced LRU cache, provides developers with a reliable and efficient API gateway solution, facilitating smooth communication with external services.

The main issue is that priority is documented in the config-default.yaml file, while the phase is buried in the code. Worse, some plugins run across different phases. For example, let's check the proxy proxy-rewrite plugin and, more precisely, the functions defined there:

// references: // https://github.com/tetratelabs/proxy-wasm-go-sdk/tree/main/examples // https://github.com/apache/apisix/blob/master/t/wasm/ package main import ( "github.com/tetratelabs/proxy-wasm-go-sdk/proxywasm" "github.com/tetratelabs/proxy-wasm-go-sdk/proxywasm/types" "github.com/valyala/fastjson" ) func main() { proxywasm.SetVMContext(&vmContext{}) } // each plugin has its own VMContext. // it is responsible for creating multiple PluginContexts for each route. type vmContext struct { types.DefaultVMContext } // each route has its own PluginContext. // it corresponds to one instance of the plugin. func (*vmContext) NewPluginContext(contextID uint32) types.PluginContext { return &pluginContext{} } type header struct { Name string Value string } type pluginContext struct { types.DefaultPluginContext Headers []header } func (ctx *pluginContext) OnPluginStart(pluginConfigurationSize int) types.OnPluginStartStatus { data, err := proxywasm.GetPluginConfiguration() if err != nil { proxywasm.LogErrorf("error reading plugin configuration: %v", err) return types.OnPluginStartStatusFailed } var p fastjson.Parser v, err := p.ParseBytes(data) if err != nil { proxywasm.LogErrorf("error decoding plugin configuration: %v", err) return types.OnPluginStartStatusFailed } headers := v.GetArray("headers") ctx.Headers = make([]header, len(headers)) for i, hdr := range headers { ctx.Headers[i] = header{ Name: string(hdr.GetStringBytes("name")), Value: string(hdr.GetStringBytes("value")), } } return types.OnPluginStartStatusOK } // each HTTP request to a route has its own HTTPContext func (ctx *pluginContext) NewHttpContext(contextID uint32) types.HttpContext { return &httpContext{parent: ctx} } type httpContext struct { types.DefaultHttpContext parent *pluginContext } func (ctx *httpContext) OnHttpResponseHeaders(numHeaders int, endOfStream bool) types.Action { plugin := ctx.parent for _, hdr := range plugin.Headers { proxywasm.ReplaceHttpResponseHeader(hdr.Name, hdr.Value) } return types.ActionContinue }

API7 takes Apache APISIX as its robust foundation, which is open-source and has an active community with over 600 contributors all over the world. The nature of open source allows users to examine the source code, which promotes transparency. This transparency helps users understand how APISIX works, verify its security, and identify and fix any potential vulnerabilities or bugs.

But the best part is that the libraries mentioned here and Apache APISIX are entirely open source, meaning you can look under the hood and modify things yourself.

Default configuration

4. Plugin definition: It is a really important part of plugin implementation that we define as a table with properties for the version, priority, name, and schema. The name and schema are the plugin's name and schema defined earlier. The version and priority are used by APISIX to manage the plugin. The version typically refers to the version that is currently in use like API versioning. If you publish and update your plugin logic, it is going to be 1.1 (You can set any version you wish). But you need to be very careful in choosing priority. The priority field defines in which order and phase your plugin should be executed. For example, the 'ip-restriction' plugin, with a priority of 3000, will be executed before the 'example-plugin', which has a priority of 0. This is due to the higher priority value of the 'ip-restriction' plugin. If you're developing your own plugin, make sure that you followed the order of plugins not to mess up the order of existing plugins. You can check the order of existing plugins in the config-default.yaml file and open the Apache APISIX Plugin Development Guide to determine.

Their use of etcd was a hard pass for me; I don't need more etcd in my life

Apache APISIX Apache APISIX is an open source, dynamic, real-time, high-performance cloud native API gateway. APISIX provides rich traffic management features such as load balancing, dynamic upstream, canary release, circuit breaking, authentication, observability, and more. Official website https://apisix.apache.org/ GitHub projects APISIX (the core): https://github.com/apache/apisix GitHub - apache/apisix: The Cloud-Native API Gateway GitHub - apache/apisix-dashboard: Dashboard for Apache APISIX GitHub - apache/apisix-website: Apache APISIX Website GitHub - apache/apisix-docker: the docker for Apache APISIX GitHub - apache/apisix-go-plugin-runner: Go Plugin Runner for APISIX GitHub - apache/apisix-java-plugin-runner: APISIX Plugin Runner in Java GitHub - apache/apisix-python-plugin-runner: Apache APISIX Python plugin runner GitHub - apache/apisix-helm-chart: Apache APISIX Helm Chart GitHub - apache/apisix-ingress-controller: ingress controller for K8s

The EventSource uses the Lua language to search for any services with ports set to 80 or 443 in the ‘argocd’ namespace. More examples can be found here.

If you're new to the 12 in 24 series, I'm learning and building projects with a new programming language every month - this month, it's the Lua scripting language. You can find source code for the projects I build in the official GitHub repository (check it out, this week's folder contains code for both this and two other bonus projects!).

This month, we're talking about Lua. It's not always a first choice when it comes to programming, but I think there's a lot to enjoy about this little language. Heck, I'm a big game development fan myself - I would look into it even if that was the only reason to.

It’s Portuguese. It’s the same in the Lua codebase [1].

[1]: https://github.com/lua/lua

If we think we need more flexibility for processing records, we can write our own embedded filters using Lua language. Lua is a highly efficient programming language used mainly for embedded scripting.

Lua

➜ ~ brew info lua ==> lua: stable 5.4.6 (bottled) Powerful, lightweight programming language https://www.lua.org/ /opt/homebrew/Cellar/lua/5.4.6 (29 files, 788.7KB) * Poured from bottle using the formulae.brew.sh API on 2023-05-16 at 11:03:06 From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/l/lua.rb License: MIT ==> Caveats You may also want luarocks: brew install luarocks ==> Analytics install: 16,599 (30 days), 56,745 (90 days), 139,027 (365 days) install-on-request: 1,763 (30 days), 6,266 (90 days), 21,105 (365 days) build-error: 0 (30 days)

I think Lua is a good example of doing documentation well. The source code is commented only as much as needed, mainly with brief comments about things that might not be obvious and a small number of longer explanations of how the architecture works (mainly relevant to developers). It also has a super nice feature that's surprisingly rare: each file has a very short line at the top that describes what the file is, so you don't have to guess based on the filename alone. The API is documented in a single HTML file on the website that has both the high level descriptions of the language and architecture, as well as documentation for each public-facing function. The docs are maintained by hand, but the API is mostly stable, so the docs don't need to change very often.

This is using the Lua language and the Solar2d game framework