Advanced Routing Strategies

[00:00:00]
>> Speaker 1: That was just one level This example is showing you how you can go multiple levels, so I can mount another router on the router that was mounted I can go infinitely deep There's really nothing stopping you from doing that

[00:00:00]
This is really good if you want to segment your router, your API based on different versions You're using API with slash V1, V2 like this is great for that You can segment all that stuff or maybe you segment them based on microservices and different teams working on different microservices, so everybody gets their own sub-router

[00:00:00]
That's why you do it that way because it's an organizational thing, maybe it's a technical thing—it could be any reason in which you might want to separate these things out You can go infinitely deep if you want to

[00:00:00]
Just realize the deeper you go, all these things coalesce into one registry of all your routes, so you have to be wary of possible collisions that I discussed before about which one's going to run first If you keep going deep and there's a potential collision with some other nested and set or another route that you don't know about, whichever gets registered first is the one that's going to happen

[00:00:00]
If you have a sprawling router configuration, that could be nasty to debug I think that's where you'll move on to better hygiene with registering routes—maybe instead of just writing strings, you would have enums and globals for your route names so you can reuse them versus someone just typing in whatever string they want

[00:00:00]
Because it's just JavaScript and there's nothing stopping you, you can conditionally make routes For example, if you're in dev mode, you want to add dev routes specifically for development, maybe a web app panel that shows certain stuff and needs access to a specific database, so you only enable these routes if you're in dev mode

[00:00:00]
Or maybe there are feature flags powered by environment variables that you set inside your hosting provider, and the feature only gets enabled if that environment variable is set to true You can then add the route for that feature

[00:00:00]
Similar to A/B testing or versioning scenarios There are many ways to organize routes In this app, we're mostly going to organize them by resource-based approach What does that mean Every resource like a habit, a user, or authentication will be separated out by resource

[00:00:00]
There's really no wrong way to do this You could also use a feature-based approach, breaking things out by what a user experiences, which might make sense if different teams are working on different features You might break routes down by versions or co-locate things

[00:00:00]
Instead of having a routes folder, you might have separate folders for authentication, users, habits, and tags Each folder would contain routes, tests, handlers, and database queries for that specific resource, with an index file combining everything collectively

[00:00:00]
These are just different examples I've personally used for various reasons If I'm just trying to get something out the door, I'll use a simple, flat approach I'll add a section about common endpoints like the health check

[00:00:00]
Many services have a `/health` endpoint that monitoring tools ping repeatedly Services like Uptime Robot monitor your application by constantly checking if it returns a 200 status code If the response changes or takes longer, it can trigger alerts or show performance degradation

[00:00:00]
Pinging is an effective way of determining not only if your service is up but also its performance If ping times increase, it could indicate traffic growth, performance issues, or recent code changes affecting the application

[00:00:00]
I'll briefly mention API versioning, catch-all routes, and how these techniques apply to single-page applications (SPAs) For SPAs, servers need to always return the index.html file, allowing client-side routing to handle navigation

[00:00:00]
Modern deployment platforms like Netlify handle this automatically I'll also cover some common routing pitfalls: remembering to export routers, understanding route order, and avoiding route conflicts For instance, a route with `/id` and a specific route like `/profile` can conflict if not ordered correctly

[00:00:00]
Just be mindful of route handler implementation and testing, and you'll create robust routing configurations.