should we add an optional path param to the route decorators?

[leeuwis]

Started yesterday on an example for next-api-decorators and stumbled on the following issue structure wise.

So for the example I wanted to create a simple CRUD example, with the following routes:

• GET /api/users (list)
• POST /api/users (create)
• GET /api/users/:id (read)
• PUT /api/users/:id (update)
• DELETE /api/users/:id (delete)

Because we have 2 GET routes, this would normally be split in 2 files:

├── api
│   ├── users
│   │   ├── [id].ts
│   │   ├── index.ts

// or

├── api
│   ├── users.ts
│   ├── users
│       ├── [id].ts

But it feels weird to split up the handler into multiple files, you would expect to have one User class that handles all the user related routes. If we wouldn’t have the list route, it could be done with one class by using an id query parameter instead of the path parameter.

If we want to tackle this problem, it could be a solution to add an optional path param to the decorators like:

@GET('/:id')

The above syntax should be possible if we use this structure (which catches both /users and /users/:id):

├── api
│   ├── users
│   │   ├── [[...id]].ts

And I say “If we want” because it might just not be the right use case for next-api-decorators, maybe it should only be used for simple routes and not to create a complete CRUD API.

Any other thoughts on this?

[ggurkal]

Creating [[...id]].ts will make it possible for clients to request both /users/1 and users/1/bla (and other variants), and then the req.query.id will become an array as ['1', 'bla'] for which we can add an option to the @Get decorator, like @Get('id', { array: true }) or @Get('id', [Number, String]), or just @Get('id', { depth: 2 }) with default depth: 1.

If only @Get('id') is used, we will simply get the first value of req.query.id.

What are other possibilities you can think of? 🤔

P.S: I think @mitchelvanbever and @BJvdA can give some input here.

--

This discussion led me to try some other possibilites, and yesterday i could create a prototype of a router that works with this package. I'll create another discussion for that.

[BJvdA]

That syntax looks good to me, seems like an optimal solution

[ggurkal]

I suppose the @param decorator also works with all the pipes?

Yes.

[mitchelvanbever]

To me it looks like a very nice addition to the suite as well 💯

Have we tested how it affects production deployments? Since you mentioned everything will be concecatenated into a single file I'm not sure how that is handled by vercel to ultimately create the serverless functions.

[ggurkal]

That's the case for the other discussion (#42). But in any case, if you import another file into an api route handler file, that imported file will be concatenated into the api route handler file.

[mitchelvanbever]

@ggurkal do you have a link for me when I can check the above implementation on a production deplyoment?