Grouping Middleware for API Routes

[rogadev]

The docs refer to grouping as "layout grouping" specifically, but I'm curious to know if I can add (group) grouping folders within API routes to run middleware functions. If not, I think it's a pretty cool idea. Consider the following:

src/routes/api/
├ +server.ts            // ⬅️ handles authentication, returning `fail(401)` if not authenticated
├ (admin)/
│ ├ +server.ts          // ⬅️ validates if the user is of role "admin", returning `fail(401)` if not
│ └ vehicles/+server.ts // ⬅️ returns the full list of all vehicles
└ (drivers)/
  ├ +server.ts          // ⬅️ gets the driver ID and passes it along with the request
  └ vehicle/+server.ts  // ⬅️ returns the vehicle this specific driver is assigned to

Not only would this provide the visual benefit of seeing what api endpoints are accessible by which user types, but it would greatly reduce the amount of code I have to write. I could, of course, write a reusable set of auth check functions, import them, etc - but even this would be lines of needless import statements and function calls if it works the way I've described above.

Someone let me know if this already works the way I think it should because I'm not clear on the implementation if that's the case.

[wwwdepot]

Using server hooks + a switch statement (in api/+server.ts) should get the job done.

1. server hooks -> perform auth check -> assign user to event.locals
2. +server.ts route can access event.locals, do a switch or If-statement on that & perform whatever based on user permission

import { error, json } from '@sveltejs/kit';
import type { RequestHandler } from './$types';
import { doAdminStuff, doUserStuff } from './whatever-this-file-is';

export const GET = ((event) => {
	switch (event.locals.userRole) {
		case 'admin':
			return doAdminStuff(event);
		case 'user':
			return doUserStuff(event);
		default:
			throw error(401, 'who are you');
	}
}) satisfies RequestHandler;

[rogadev]

Indeed, but the one biggest problem I have with this is that it gets extremely cumbersome as your project scales up. The other issue I have is that this is running extra processes on every request, which can become unnecessary overhead.

By breaking the logic out and allowing me to group up specific logic functions to run only on specific API routes I am:

1. Reducing boilerplate code that would otherwise have to be at the beginning of every endpoint with the same starter logic.
2. Reducing the out-of-scope overhead by putting every api endpoint behind an increasingly complicated logic statement containing this specific logic for specific endpoint groups.
3. Makes the scoped logic far more maintainable, readable, and more easy to scale up as needed.

What do you think?

[coryvirok]

I do something like this in my app. Although it feels like more of a hack than a good practice. More info - #6315 (comment)

[rogadev]

That looks more like you're talking about the frontend grouping. Which is awesome and I love it - but I specifically want this for API endpoints for my backend routes.

[coryvirok]

I pretty much only use it server-side. It makes things easier in hooks.server.ts when determining if the request should be authenticated, etc. Check out the example I linked - #6315 (comment)

[rogadev]

To expand a little bit, I see a few ways for people to handle some of what I'm going to call "starter logic". Auth logic is probably the easiest to describe, so I'll use that in this example.

Each file starts with starter logic

You could directly write the logic for each endpoint in each endpoint file. Obviously you'll end up extracting this out into a utils-like collection of endpoint starter logic functions, but this isn't "proper" middleware in my opinion. Additionally, it does nothing to visually show you what logic is applying to what endpoints without physically going into each file and looking at which function you've implemented for each endpoint.

hooks.server.ts

You could write an overly complicated switch statement containing every route and flow all your requests through this, but this file fires on EVERY request. You might not need logic to run on every request, which means that many requests have needless extra cost associated to them. Additionally, as the complexity of your app grows the complexity of this logic can get out of hand really quickly.

Grouping

I just think this is the best option. You can visually see what your groups look like. You can easily update logic to apply across several endpoints at once. You are only running the logic that is relevant to each groups of endpoints. Your logic is simple, clean, readable, maintainable, and easily expandable.

I'd love to get more opinions on this topic.