Currently I use a script that runs every time the server starts on my application to create all of the routes. I did this so that I wouldn't have to manually create all of the various routes by hand. I would like to convert this to codegen for the following reasons:
It will make it clearer which routes exist at compile time (useful for stuff like Swagger)
It can potentially help with type narrowing
It can help with visualization of all functions that occur at each route
Routes can be locked behind switches and flags more easily
It can speed up compile times (potentially with incremental changes?)
For point 1, I think that services like Swagger will need to be able to know the routes that exist at compile time to generate all documentation. By running codegen, it can be clear which routes have been modified and which routes will need documentation updates.
For point 2, it can help with type narrowing. Currently, even if I were to run privacy checks on routes, there is no compile time guarantee that values will not be null. Because of this, every route that requires authorization needs to ensure that the user is authorized again. If there is codegen for authorization, then typescript can narrow the types automatically and if the current route requires the user be logged in, that route can guarantee it. I have to think more about how the typing would work exactly. I may have to create some types that ensure the req param has non-null fields which will error out at the route building stage if possibly null.
For point 3, this is especially true for schema validation and authorization. It will be clear what functions are being called or not. This can also include custom functions.
For point 4, this is more-so to actively prevent routes that should not be available from being exposed. I can think about a few ways this could be implemented with the script version, and I'd definitely need middleware to check the current status of the route, but it can make it easier to disambiguate which routes are affected by gating.
For the 5th point, in the future, I plan to be able to require that only affected routes be recompiled. I don't know the specifics around this, and it probably does not have any bearing with smaller apps, but I believe that in the future when the app grows, the script to generate routes will take significantly longer. It also would allow for the routes to be rebuilt without having to re-establish connections with the database, cache, and other services.
Although I believe a script can accomplish everything I've stated without requiring a compilation step, moving towards codegen can make route creation simpler and easier to test with better type handling. I may also get rid of the nested folder strategy I've been using for routes in favor of defining them in singular folders, but I'd like to do more research before I commit to that.
Currently I use a script that runs every time the server starts on my application to create all of the routes. I did this so that I wouldn't have to manually create all of the various routes by hand. I would like to convert this to codegen for the following reasons:
For point 1, I think that services like Swagger will need to be able to know the routes that exist at compile time to generate all documentation. By running codegen, it can be clear which routes have been modified and which routes will need documentation updates.
For point 2, it can help with type narrowing. Currently, even if I were to run privacy checks on routes, there is no compile time guarantee that values will not be null. Because of this, every route that requires authorization needs to ensure that the user is authorized again. If there is codegen for authorization, then typescript can narrow the types automatically and if the current route requires the user be logged in, that route can guarantee it. I have to think more about how the typing would work exactly. I may have to create some types that ensure the req param has non-null fields which will error out at the route building stage if possibly null.
For point 3, this is especially true for schema validation and authorization. It will be clear what functions are being called or not. This can also include custom functions.
For point 4, this is more-so to actively prevent routes that should not be available from being exposed. I can think about a few ways this could be implemented with the script version, and I'd definitely need middleware to check the current status of the route, but it can make it easier to disambiguate which routes are affected by gating.
For the 5th point, in the future, I plan to be able to require that only affected routes be recompiled. I don't know the specifics around this, and it probably does not have any bearing with smaller apps, but I believe that in the future when the app grows, the script to generate routes will take significantly longer. It also would allow for the routes to be rebuilt without having to re-establish connections with the database, cache, and other services.
Although I believe a script can accomplish everything I've stated without requiring a compilation step, moving towards codegen can make route creation simpler and easier to test with better type handling. I may also get rid of the nested folder strategy I've been using for routes in favor of defining them in singular folders, but I'd like to do more research before I commit to that.