I agree that application developers should worry about application and deployment engineers should not worry about particular resources being served. However,

I agree that application developers should worry about application and deployment engineers should not worry about particular resources being served. However, what I was trying to suggest is something slightly different. What if a web framework was smart enough to generate a routing configuration for a web server, instead of processing some sort of route table on every request? Think of a workflow like this: 1. Application developers can still define routes somewhere in application code as they do now. 2. Framework takes that route table, and generates a routing config for a web server, offline. 3. Deployment engineer does not need to worry about resources being served, but would have to make sure that the generated config is included where appropriate and trigger configuration reload on web server. I (naively) think, that the above three could result in: 1. Nothing really changes for the application developer, except a chunk of redundant code is removed from the top of his code in the stack. 2. Web server configuration languages (or a subset related to routing) are fairly robust by now and rarely drastically change (I'm thinking about nginx and Apache2 here). Add this to an auto-generated configuration and a layer of error is reduced. 3. Deployment engineer does not need to configure any routing, but has to make sure a generated file is included in configuration, when deployed.