fn icon indicating copy to clipboard operation
fn copied to clipboard

Middleware for user apps

Open treeder opened this issue 6 years ago • 6 comments

It would be nice to provide middleware for user applications, in the form of another function, so that a user can add things like authentication for instance.

  • User adds route/function to app
  • User adds middleware to app (URL's to functions)
  • During execution, we call URL's before running the function
  • If response isn't 2XX, we respond early and don't run function.

treeder avatar Oct 06 '17 17:10 treeder

Related: https://github.com/fnproject/fn/issues/34

treeder avatar Dec 20 '17 18:12 treeder

Is this on the roadmap at all? It would be very useful!

Daniel15 avatar Apr 18 '19 07:04 Daniel15

@Daniel15 At this moment, you can develop your own middleware along with the extensions to Fn. So, nothing stops you from doing what you want/need.

denismakogon avatar Apr 18 '19 09:04 denismakogon

Sure, I understand that I can write middleware for Fn in Go, but it would be nice to have a simple built-in way to use another function as middleware, so that I could write the middleware in any language I like.

Daniel15 avatar Apr 19 '19 04:04 Daniel15

Thanks for the reply. I’m not sure if that’s something we’d do in short term.

Maybe you’re willing to contribute? Would be nice to start with detailed feature description, use cases, etc.

P.S.: The reason this feature is not available because Fn has changed significantly, at least I think so.

denismakogon avatar Apr 19 '19 04:04 denismakogon

this one is relatively challenging to support at the fn level because it's hard for us to guarantee finality (at least, easily) and scale. there's lots of implications for how to schedule from an fn node back through whatever we'd use to schedule these to other nodes and correlate those (we can get into locality and all this too, eventually; opening the pandora's scheduler box is not wise), and for funsies since functions can themselves call functions, we can end up in a chain that never ends (this just highlights the complexities).

flow is a better/existing idea for this kind of thing, as it handles a lot of this client side and exists today. unfortunately, it's a bit more restrictive on current implementations language (no .net), and is considered somewhat experimental, none-the-less it does work in not too scaled up capacities and the API is open and can be implemented with relative ease.

rdallman avatar Apr 19 '19 17:04 rdallman