[RFC] 0005 Server Middleware Extensibility

[svbender]

Read the current draft here: 0005-server-middleware-extensibility.md

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[sebbi08]

hi im currently missing som topic about middlewares from dependencies like we have it in the builder.

In the builder it is currently that every application/library can define there own build steps and they run only for the coresponding like library-a needs to be transpiled with bable library-bneeds no transpiling because it was written in ES5 but the app using this two libs was written in Typescript and need to be transpiled from this.

So when we have to some how also respect this for the middlewares because we alway develop on the source of the libraries and so the corresponding middlewares need to run only on requests to there own source.

[svbender]

@sebbi08 Thanks for your comment.

It is currently not planned to detect/include server middleware of dependent projects.

However, the custom server middleware can be located in a dependency. Assuming the extension is defined in that projects ui5.yaml file.

This dependency can then be included in your project.
To use the custom server middleware, you only need to configure it in your projects ui5.yaml (where the UI5 Server is started).

Regards,
Sven

[sebbi08]

@svbender thats true but lets asume we dont have a "simple" middleware like transpiling in library-a but rather some complex stuff that need acces to files of library-a. with the syntax

module.exports = async function({workspace, dependencies, options}) {
    return function (req, res, next) {
      // middleware code...
      next();
    }
};

while developing the files need would be found in the workspace collection and when used in the project they have to be searched in the dependencies

[Thodd]

@sebbi08: We reconsidered this feature and tried to work in your feedback.
Would you please take another look at the new API proposal concerning the Reader arguments?

[sebbi08]

@Thodd thats a nice way. now we can write the middleware in the dependencie and also reuse it from there. thanks

[cschuff]

First of all once again: Thanks for your great work!

Any updates on this RFC? Is it already on the roadmap? When can we expect some progress?

BR
Chris

[RandomByte]

@cschuff it's on the roadmap. Maybe @ecker can share some info on the timeline?

[ecker]

@cschuff Hi Christian, LTNS 😉, middleware extensibility is one of our major topics, and while finishing some other important tooling topics, we'd like to continue on it soon, i.e. the next weeks/month(s).

[cschuff]

Hi Andreas 👋, that is great news. ui5-tooling really is a major improvement to the ui5 dev ecosystem!

Resolved

[RandomByte]

Demo: SAP/openui5-sample-app#50

Based on WiPs SAP/ui5-project#190 and SAP/ui5-server#200

[matz3]

I don't quite like the idea of having the both sync and async options for the middleware functions.
When using middlewares programatically, you would always need to check whether the middleware is async or not (or always wrap it with Promise.resolve()). Also using async middlewares is cumbersome in general as you can't easily use them in an existing scenario which needs to be executed sync. For sure you could register the middleware once the Promise resolves, but this leads to an initial timeframe where the middleware is not mounted yet but the server might be already started.

So I would like to go back to my initial opinion to make the middlewares always return a function, not a Promise.
In case a middleware needs to do some async stuff initially (which we don't have right now, or?) it might just queue the incoming requests and handle them once the initialization has finished by waiting for an initial Promise to resolve.
Yes, this makes such middlewares a bit more complex to write/maintain, but I see a bigger advantage on the consumer side.

[RandomByte]

@matz3 While implementing SAP/ui5-server#200, knowing that the middleware modules could return a promise lead to some good design choices allowing them to do so in the future. We could definitely start with synchronous middleware modules now and wait for someone to come up with a good use case for returning a promise in the createMiddleware function.

Again, my idea was that a middleware could do some initial processing with the resources provided to the createMiddleware function before being ready to serve requests. But as we are still lacking a real scenario for this I'm fine restricting it to sync for now. But I would like to hear @Thodd`s opinion on this too.

[RandomByte]

We decided to remove the npmMiddleware configuration option from the RFC for the time being.

It was meant to offer a quick way to integrate generic middleware modules that do not make use of UI5 Tooling specific APIs and therefore do not require any UI5 Server specific implementation. Also, they must not require any configuration to be passed to them. An example is the helmet module.

To consume such modules with the current state of the RFC, you now need to wrap such modules into a custom middleware extension.

Please let us know if you would like to see this additional feature in a future version of the UI5 Server.

[RandomByte]

Implementation is done and released with UI5 CLI v1.6.0. Functionality is as described in this RFC.

Dedicated documentation is pending as part of #160 and should be published sometime tomorrow or early next week

Therefore merging this RFC 🎉

Thanks to everyone for your feedback!

[RandomByte]

Documentation now available at https://sap.github.io/ui5-tooling/pages/extensibility/CustomServerMiddleware/ 🐴