+middleware example with @universal-middleware/router #2050

magne4000 · 2025-01-07T17:24:50Z

WIP around how we can move some logic used in +middleware.ts process to universal-middleware.

@brillout This is mostly to discuss what we should port to universal-middleware and create a proper API.

universal-middleware in progress PR: magne4000/universal-middleware#95

magne4000 · 2025-01-07T17:28:45Z

test/middleware-config/express-entry.ts

+  const middlewares = (await getMiddlewares()) as (RouteDefinition | MiddlewareDefinition)[]
+  const router = new UniversalRouter()
+  apply(router, middlewares)
+  app.all('*', createMiddleware(() => router[universalSymbol])())
+  // TODO replace with UniversalExpressRouter once done.
+  //      It should look like this:
+  // const router = new UniversalExpressRouter(app)
+  // apply(router, middlewares)
+  //      So no need for manually calling app.*, and rely on express routing


This could be moved to vike-node, which would be responsible to create the proper Universal*Router.

👍 And eventually vike-{express,hono,...} so that one Vike extension = one tool (e.g. to fit the text next to the landing page's slot machine).

Btw. I'm currently working on the Vike CLI and one neat thing we could eventually do is to have vike-express have a built-in Express.js server boilerplate, so that the user doesn't have to write a single line of server code (but the user can eject that server boilerplate if he needs to).

It should be simple enough, and I like the idea.
I can see that in Bati we would then just add a comment somewhere or a paragraph in the README to explain that it can be ejected.
We could even allow the user to retrieve the built-in express like this:

import { app } from "vike-express";

👍

We could even allow the user to retrieve the built-in express like this:

Neat idea ✨

test/middleware-config/express-entry.ts

brillout · 2025-01-08T12:48:33Z

I wonder whether/how we can add a name to a universal middleware, so that users can selectively remove middlewares.

Use case: user is using vike-react-authjs but wants a custom server integration. The answer could be that he has to fully eject vike-react-authjs or he replaces the universal middleware with a custom middleware. I guess both are okay, although if it's easy to implement then it would be nice to have some kind of name or other means to select a universal middleware.

magne4000 · 2025-01-08T13:25:56Z

I wonder whether/how we can add a name to a universal middleware, so that users can selectively remove middlewares.

Use case: user is using vike-react-authjs but wants a custom server integration. The answer could be that he has to fully eject vike-react-authjs or he replaces the universal middleware with a custom middleware. I guess both are okay, although if it's easy to implement then it would be nice to have some kind of name or other means to select a universal middleware.

I was thinking about that with the same use case in mind. IMO the best solution would be to be able to just eject the +middleware, but I think we're not there yet.
So adding a name onto them could do the trick for now (and it doesn't hurt).

brillout · 2025-01-08T13:32:04Z

Yea, I think a name is always a good thing to have. I'm just wondering how it could fit with the current DX with withRoute() and withOrder(). Maybe merging these into a single withMeta() could do the trick. Actually, I feel like naming that it withRoute() instead of withMeta() could be a better name. We could then require a name when using withRoute() (and iff. using withRoute() because in the user land setting a name isn't that useful I guess).

magne4000 · 2025-01-08T13:45:21Z

test/middleware-config/pages/middlewareTelefunc.ts

+const middlewareTelefunc = decorate(telefuncUniversalMiddleware, {
+  method: 'POST',
+  path: '/_telefunc'
+})


withRoute replaced by a more generic decorate helper, to make things more explicit, and simplify adding props in the future

Good idea to keep it generic. (Name idea: enhance() instead of decorate(), but I'm fine with decorate() if you prefer it.)

enhance was my first name idea, but I preferred decorate. I'll let that macerate a little and see how I feel about it when we're closer to a finished implementation.

👍 The thing I prefer about enhance() is that it's more visual and concrete, whereas decorate() is more abstract and vague (or maybe it's subjective), thus more difficult to remember.

Bonus: in the docs we can mention "enhanced middlewares", for example:

Enhanced middlewares are middlewares that define a route

Enhanced middlewares must have a name

But I guess we could also say "decorated middlewares".

magne4000 · 2025-01-08T13:54:30Z

test/middleware-config/pages/middlewareVike.ts

-]
+const middlewareVike = decorate(vikeUniversalMiddleware, {
+  method: 'GET',
+  path: '/**'


The path property is kinda tricky to handle.
Most servers have the same basic syntax to declare a path (e.g. /, /:name).

But there are also some discrepancies even with some basic syntax like /** and /*. Some servers will match /a/b/c with both, others will only match such path with the /** syntax (and some do not understand what /** means).

We could have a translation layer for those syntax, but this seems a bit overkill.

My current stance on this subject is as follows:
When using decorate in a lib, use a syntax that works with ALL servers if possible (we could have a really minimal translation layer if we discover some recurring use cases that would benefit from it).
When using decorate in user-land, the user is able to use a syntax specific to the server in use, and when one ever needs to migrate to another server, this should be trivial to manually migrate.

Unless I'm missing something, we could make it that internally all universal middlewares are catch-all middlewares but we wrap a if (!matches(url, path)) return condition. This would allow us to use any path syntax we want.

🤔 that could work.

Currently I'm relying on servers themselves to handle the routing, and fallback to using rou3 for the UniversalRouter. But this is the cause of what I mentioned above.

If I use rou3 for all servers in catch-all, I think that would also simplify some other future ideas I had for handling deployments.
For now I chose rou3 because it's tree-shakable and minimal: (it would be directly bundled into universal-middleware)

👍 Sounds good.

Another idea: we only support a trivial path syntax and we tell users to define a catch-all with a if (!url...) return condition if they want to define advanced routing logic.

Kinda like Vike: Route Strings are very basic while Route Functions enable programmatically defined routes. This strategy has been working well: no one's complaining about the limitations of Route Strings.

But using rou3 sounds good to me as well.

rou3 also have the benefit of prioritizing nested routes.

For instance, with the following patterns /** and /a/**, the path /a/b/c will always match the second pattern.

This is usually what the user will expect

This does not require the user to register routes in a specific order

This does not require a lib to specify an order for middlewares with a path

+middleware example with @universal-middleware/router

c1cf31d

magne4000 commented Jan 7, 2025

View reviewed changes

brillout reviewed Jan 7, 2025

View reviewed changes

test/middleware-config/express-entry.ts Outdated Show resolved Hide resolved

all helpers replaced by decorate + new types

98030e6

magne4000 commented Jan 8, 2025

View reviewed changes

magne4000 added 3 commits January 8, 2025 14:59

add name props onto middlewares

ddee939

bump

b6f0eae

bump

bee132a

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

+middleware example with @universal-middleware/router #2050

+middleware example with @universal-middleware/router #2050

magne4000 commented Jan 7, 2025 •

edited

Loading

magne4000 Jan 7, 2025

brillout Jan 7, 2025 •

edited

Loading

brillout Jan 8, 2025

magne4000 Jan 8, 2025

brillout Jan 8, 2025

brillout commented Jan 8, 2025

magne4000 commented Jan 8, 2025

brillout commented Jan 8, 2025

magne4000 Jan 8, 2025

brillout Jan 8, 2025

magne4000 Jan 8, 2025

brillout Jan 8, 2025

brillout Jan 8, 2025

magne4000 Jan 8, 2025 •

edited

Loading

brillout Jan 8, 2025

magne4000 Jan 8, 2025 •

edited

Loading

brillout Jan 8, 2025

magne4000 Jan 8, 2025 •

edited

Loading

+middleware example with @universal-middleware/router #2050

Are you sure you want to change the base?

+middleware example with @universal-middleware/router #2050

Conversation

magne4000 commented Jan 7, 2025 • edited Loading

Choose a reason for hiding this comment

brillout Jan 7, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brillout commented Jan 8, 2025

magne4000 commented Jan 8, 2025

brillout commented Jan 8, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

magne4000 Jan 8, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

magne4000 Jan 8, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

magne4000 Jan 8, 2025 • edited Loading

Choose a reason for hiding this comment

magne4000 commented Jan 7, 2025 •

edited

Loading

brillout Jan 7, 2025 •

edited

Loading

magne4000 Jan 8, 2025 •

edited

Loading

magne4000 Jan 8, 2025 •

edited

Loading

magne4000 Jan 8, 2025 •

edited

Loading