Middlewares

[Minivera]

Small question: I want to record some usage data whenever all endpoints on a specific service are being called and I was thinking of doing something like a middleware I'd add to the service. Is there any way to do so with encore? Or would there be another recommended way of doing this kind of pattern with encore?

[eandre]

Hey, it's not something that's currently supported. Partly because it's technically tricky since Encore API endpoints have different signatures, and partly because a lot of the common use cases for middleware (logging, tracing, authentication, request serialization/deserialization, etc) are already supported or will be supported through a different approach.

We definitely need to support middleware in some form, though. But first I'd love to understand your use case a bit more. What sort of usage data? Encore does automatically track certain metrics for you (available in the cloud console), and we could expose those over an API of some kind.

In the short term though, the easiest would probably be to define a helper method of some kind that you call at the start of each endpoint to collect the usage data, if that would work for your use case.

[Minivera]

For this specific use case, I want to track how many time a user with a specific API key calls some endpoints in a given period of time. This would be for billing purposes since I'd want to implement something like a limit on the number of calls a user can make in a period of time based on the plan they have selected.

For example, if I was using gofiber:

app.Use(func(c *fiber.Ctx) error {
  err := checkAPIRateLimit(c)
  if err != nil {
    return err // This would stop the call here.
  }

  return c.Next()
})

A helper method would definitely work for me, I was thinking of using a middleware to simplify the code a little like the auth handler allows us to do currently. Talking about the auth handler, maybe a possible way to implement this could be to follow the auth handler pattern? Something like

//encore:middleware
func UsageMiddleware(ctx context.Context, next middlewares.Next) error {
  err := checkAPIRateLimit(c)
  if err != nil {
    return err // This would stop the call here.
  }

  return next()
}

//encore:api auth
//encore:api:middleware UsageMiddleware
func UpdateDocument(ctx context.Context) error {
	...
}

[eandre]

Thanks for explaining the use case better, that makes sense. It's definitely something to consider; I feel like we lack a bit of data on other use cases to make a decision about this right now. I especially wonder about what sort of information middleware need access to (such as request payload), and if there are use cases for running middleware after the API handler ran or only before.

[Minivera]

Would you like me to find other use cases for my application or potentially do some research on how middleware are used in other frameworks? I'd say, in general, middlewares have access to the entire request information, can change the response, and can return errors to stop the request if something went wrong (The authHandler in encore is a middleware technically). Express middlewares can be executed before or after the endpoint (Or even only on an error), though executing middlewares after the request is a bit weird in its execution. Gofiber, on the other hand, only allows middleware prior to the request. Maybe their docs page on middleware can give a good idea of the use cases? https://docs.gofiber.io/api/middleware

[sopta]

Hey guys,

it would be interesting to take a look at the different approach that Hapi framework offers https://hapi.dev/.

I'd suggest defining all scenarios (well almost :D) where middlewares are typically used and try to find out a better approach (if there is one) Just because other fws have support for middlewares, doesn't mean Encore have to blindly support them.