Currently, the names of the services are generated by the path of the request. This could split up services which might belong together. For example, on the server side i have a service for notifications, there are /api/notifications get and put routes, so i will get a notificationService. But i also have a url like this /api/notifications/stream which is used for SSE. This route will create a new folder notifications next to the NotificationService.ts file which contains a StreamService.ts for this subroute. For me, they both belong together on the backend.
I think it would be great, if i could use tags for the service naming. I would then add the notifications tag for all these routes and it will create a notificationsService containing all routes which use the notifications tag. This way i would have more control over the generated api.
I know this is tricky and that the tags field in swagger is an array, this is why i would make it an option where the default is the path version of the service names.
Currently, the names of the services are generated by the path of the request. This could split up services which might belong together. For example, on the server side i have a service for notifications, there are
/api/notificationsget and put routes, so i will get a notificationService. But i also have a url like this/api/notifications/streamwhich is used for SSE. This route will create a new foldernotificationsnext to theNotificationService.tsfile which contains aStreamService.tsfor this subroute. For me, they both belong together on the backend.I think it would be great, if i could use tags for the service naming. I would then add the
notificationstag for all these routes and it will create a notificationsService containing all routes which use thenotificationstag. This way i would have more control over the generated api.I know this is tricky and that the tags field in swagger is an array, this is why i would make it an option where the default is the path version of the service names.