Route matching like in express

[ChristophP]

Hi,

we're using VPS/Vike at Burdaforward and currently use mulitple express routes that call renderPage().
I would like to simplify this by having only one express route that calls VPS as shown in this example

However, I am not sure this is currently possible due to differences in routing between express and VPS.

1. /some/static/route -> /some/static/route works
2. /some/:param -> /some/@param works
3. /some/glob/* -> /some/glob/* works
4. /some/glob-in-the-middle/*.html -> ??? is it true that VPS only allows globs at the very end of the route path

This test suggests that the example number 4 currently isn't possible with VPS routing

So the main difference seems to be how globs are treated.

• you can't have more than one
• it can only be the last thing in the path

The latter happens quite often for us with things like /path/to/*.html.

So is it correct that globs followed by other characters is currently not possible? Is there a reason for this restriction? Is anything planned to enable this in the future?

Thanks a lot for you help

[brillout]

See c1537dc, let me know whether that works for you.

I'm glad BurdaForward is still working on its vite-plugin-ssr project. Let me know if you run into any issues, and feel free to keep me updated how things go. The raison d'etre of vite-plugin-ssr is increased flexibilty and I'm looking forward to further support BurdaForward's use case.

On a tangent: is there any chance to get sponsoring up again? This makes a massive difference. I'm trying to make ends meet with sponsoring but, as you can imagine, 33% of the monthly sponsoring goal is very tough. (I basically have to save every penny to make it work.) I'd love continue working full-time on vite-plugin-ssr but I need the help of companies. Thanks for considering it and also thanks for already sponsoring earlier this year. I'm very much looking forward to make it work while consolidating BurdaForward's bet on vite-plugin-ssr. (We can sign a contract ensuring that I'll be working on vite-plugin-ssr for at least X amount of months/years if that's something you'd be interested in. Although, honestly, I love working on vite-plugin-ssr so it's just a matter of securing sponsors.)

[ChristophP]

Cool I will see of I can solve that case using route functions. Thanks for you quick reply. 👍

Regarding the sponsoring, I passed on this message to my team leads.

[ChristophP]

I just checked out the routing functions and it seems like they would let us do what we want.

I looked at this particular example and I was wondering the following:

• we basically would like our routes to behave like express routes
• express uses path-to-regexp under the hood
• would it make sense to just call path-to-regexp inside a route function?

Regarding the sponsoring again: we'll need to discuss this internally of course. We don't currently have any need to additional features I think, but of course we have a vital interest in VPS's ongoing maintenance and development.

[brillout]

Yes (ed38e73), although I'd recommend using vite-plugin-ssr's route strings whenever possible for improved DX. (Let me know if you have a reason for choosing path-to-regexp over vite-plugin-ssr's route strings.)

Regarding the sponsoring again: we'll need to discuss this internally of course. We don't currently have any need to additional features I think, but of course we have a vital interest in VPS's ongoing maintenance and development.

Thanks. Let me know how it goes, even if it's a no, so that I can plan accordingly.

[ChristophP]

Our two main reason for wanting to use express routes (even thought otherwise the DX of the VPS route strings is nice) are

1. We want users to create their own routes, they are all familiar with the express route syntax and we want them to use what they are familiar with.
2. We need the ability to glob for things "ending in something" like some/path/*.html

Thanks. Let me know how it goes, even if it's a no, so that I can plan accordingly.
Will contact you when I hear something.

[brillout]

While I can't speak for your users, I'm inclined to think that familiarity isn't worth it: the DX drawbacks being that Route Functions are slightly more verbose, and missing out on potential upcoming features such as #698 (as typesafe links cannot work with Route Functions).

As for globbing, vite-plugin-ssr could add support for globs in the middle. Let me know if that's something you'd be interested in.

Will contact you when I hear something.

🙏

[ChristophP]

Hey, sorry for dropping the ball. I was on vacation for a few days.

While I can't speak for your users, I'm inclined to think that familiarity isn't worth it: the DX drawbacks being that Route Functions are slightly more verbose

Yes, I agree that route strings are much easier to use. The difference would be that the route functions would only be in our framework code, while the users of the framework would specify there routes as (express-style) strings. Route functions would allow us to abstract that away from our users.

As for globbing, vite-plugin-ssr could add support for globs in the middle. Let me know if that's something you'd be interested in.

It would be great if VPS supported globbing across slashes and in the middle of the string. That would save us from implementing that ourselves or more specifically writing our own logic for setting the precedence in our route function.

I will try to give you an indication of the sponsoring by the end of next week. The globbing part (while helpful and appreciated) would likely not have a impact on the sponsoring decision just to let you now that for your prioritization.

[brillout]

Yes, I agree that route strings are much easier to use. The difference would be that the route functions would only be in our framework code, while the users of the framework would specify there routes as (express-style) strings. Route functions would allow us to abstract that away from our users.

I see. If you don't mind missing out on the upcoming typesafe links feature then this seems like a good solution to me. (While typesafe links are a nice-to-have, I think missing out on them is fine. Also I'm not sure when it will be implemented as there are many higher priorities in the pipeline.)

It would be great if VPS supported globbing across slashes and in the middle of the string. That would save us from implementing that ourselves or more specifically writing our own logic for setting the precedence in our route function.

I played around with an implementation: glob-example-implementation (see the unit tests showcasing globs in the middle). So it should be fairly easy to add this functionality to VPS.

Although I'm wondering: are you sure you want this to be built into VPS? I'm asking because it means that route strings would then look like /news/@category/*.html which doesn't fit Express.js's syntax. For full flexibility it may end up being better to have BurdaForward implement its own glob router. As shown by glob-example-implementation it's actually reasonably simple to implement one.

To be clear: I'm open to make it a built-in feature, I just wonder if it's the right move for BurdaForward.

to let you now that for your prioritization

Thanks for being upfront about it. I do want to further support your routing use case though as I care about BurdaForward's successful use of VPS.

The globbing part (while helpful and appreciated) would likely not have a impact on the sponsoring decision just to let you now that for your prioritization.

Makes sense. The way I see it is that the increased support and higher feature request prioritization is just a bonus. Beyond the generosity of contributing to an open source project, I'd say the main argument is that it makes sense to support a project you depend on that enables you to implement an architecture foundational to your business and that is in its vulnerable early stage.

Let me know if you have any other questions or doubts about your vite-plugin-ssr usage. (I'm available for a call or visit to your Munich office if it's something you'd want.)

[ChristophP]

Although I'm wondering: are you sure you want this to be built into VPS? I'm asking because it means that route strings would then look like /news/@category/*.html which doesn't fit Express.js's syntax. For full flexibility it may end up being better to have BurdaForward implement its own glob router. As shown by glob-example-implementation it's actually reasonably simple to implement one.

The syntax would not be a problem for us. See we way we currently do things is our framework users specify routes very similar to how it's done it VPS. Here a brief look into to what we do roughly.

// some-page/index.route.ts
export const route = "/some/express/:style/route*.html"

From that file, we generate a corresponding file which serves as the VPS route string in a pre-build step. While doing this we convert express style routes to VPS style routes. This happens under the hood with the user never knowing about it. So from the above we get.

// generated-files/some-page/index.route.ts
export const route = "/some/express/@style/route*.html" // note the @ here that used to be a :

We do some extra magic since the globbing in the middle part is not working in VPS yet and basically routing happens twice first in Express and then again in VPS.
However, in order to simplify our routing logic I was thinking we could replace the many express entrypoints with routing functions that roughly look like this:

function route({ pathName }) {
  const { match, otherStuff} = pathToRegexp(allRoutes, expressStyleRoute)  // call express routing lib
  if (!match) return false;

  return { routeParams: ... },
}

Having a the VPS globbing in the middle would make it even simpler and allow us to not have to use a route function at all. However, it wouldn't be a blocker.

That would allow us to

• eliminate our double routing with express AND VPS we currently do by handing all routing over to VPS
• significantly simplify the work we do right now by translating and generating routes.

Makes sense. The way I see it is that the increased support and higher feature request prioritization is just a bonus. Beyond the generosity of contributing to an open source project, I'd say the main argument is that it makes sense to support a project you depend on that enables you to implement an architecture foundational to your business and that is in its vulnerable early stage.

I agree, ensuring and supporting the ongoing support would be the biggest benefit.

[ChristophP]

I've further developed the implementation and added BurdaForward tests

Oh very exciting 👍

What kind of other (glob) routes do you expect to need?

The ones you have already are actually the ones we have. We mainly have two cases involving globbing

• articles: *.html (usually a long SEO slug followed by .html like german-football-team-replaces-hea-coach-following-loss-to-japan.html)
• categories: * (our Catch All Route, could be something like /sports/basketball/nba.

So Regarding BurdaForward, the current test cases should should be sufficient.

I'm interested to see how you implemented the routing precedence logic (we actually write our own route sorting logic for express, if VPS Vike supports the globbing in the middle, we could actually get ride of our implementation and reply on VPS route specificity instead which would be great)

[brillout]

👍 I'll merge the new implemention tentatively today / this WE. I'm hopeful/confident it will increase bundle size only marginally, so it shouldn't be a problem.

As for precedence logic, I think the following does the trick: pick routes without globs first, then pick the route with the least amount of params, then (upon equal amount of params) pick the route with the most amount of static segments.

[ChristophP]

Hey that sounds amazing. 🎉
This will be super useful and should allow us to simplify our codebase significantly.
Also hopefully other Vike users will enjoy this as well.

Make sense how you are thinking about conputing the precedence.

Thank you for doing this.

[brillout]

Just released [email protected] which should now work for BurdaForward's globs in the middle use cases.

(FYI it turned out to be complex to support all edge cases; a linear processing of the route string doesn't work in some important scenarios, even for only a single glob *. To avoid exploding complexity (and therefore bundle size), the route strings are now transformed into a RegExp. The good news is that the new router is now not only much more feature rich regarding globs but also slightly less KBs than the previous implementation.)

[ChristophP]

That is awesome. That should allow us to remove a bunch of the workaround we have built to make globbing work. :-)

(FYI it turned out to be complex to support all edge cases; a linear processing of the route string doesn't work in some important scenarios, even for only a single glob *. To avoid exploding complexity (and therefore bundle size), the route strings are now transformed into a RegExp. The good news is that the new router is now not only much more feature rich regarding globs but also slightly less KBs than the previous implementation.)

Yeah, I imagine that the processing of the route string gets much more complex with globs. Glad you were able to find a flexible and also size efficient solution 🎉

Hope we get around to upgrading to this Vike version soon and take advantage of Vike's routing.

[brillout]

@ChristophP FYI small breaking change about glob matching (3a45aa2) pre-released in 0.4.168-commit-42406a9 (stable release is coming soon). You may need to replace /news/press-releases/* with /news/press-releases* (depending on what you want), see commit or feel free to ask.

[ChristophP]

@brillout Seems like /a/* no longer matches /a, if I understand correctly. That should not be a problem in our case but thanks for the heads up.

[brillout]

Exactly. You now have to use /a* instead of /a/* if you want to match /a.