Is it a good design to let the traefik plugin do complex logics?


My team is currently having a debate on if we should build traefik plugin to handle the complex logic such as validating api keys and count how many time the key has been used, etc., which needs to call endpoints of other services as well as interacting with cache and database.

In my opinion a plugin should be lightweight and should not do much heavy lifting, but I'm not sure if there is a more complicated usage of plugin.

There may be a third option: use ForwardAuth and just create an API that handles all logic and returns status 200 if the request can be forwarded to the service. That would be a little less coupled to Traefik, maybe a bit easier to test.

We've considered this option. One advantage of using plugin is that theoretically it should have better performance since traefik doesn't need to send requests to a separate auth server back and forth.

If you can run the ForwardAuth service on the Traefik server, then you could use fast localhost access.

Main delay will probably be database connections, check that Traefik plugins can stay alive all the time and can enable a permanent database connection pool.

We're deploying on k8s. hmm..

Maybe tag your post with k8s.

Traefik plugins are pretty slow in comparison to vanilla Go code. I recommend performing a load test beforehand.