I post a proposal for Router and Controller refactoring.
Here are the different parts of a request processing chain. We have to take care to keep the whole chain asynchronous (this is not the case with the actual code!).
The first part is routing request to actual handling code:
I propose to keep the already implemented action anotations because it leave Controllers loosely coupled with the Router. It also keep the responsibility to the router to handle controller instantiation/release. The router must also handle a (configurable) timeout before auto closing a request with an error (to avoid bad async code going nowhere)
The second part is the actual Controller: This part is public and must be implemented by the end user in his application. Because the code must be async, I suggest to instantiate one controller per request to avoid accidental property sharing. The controller must expose to the end-user properties like request/responce. It must also provide a helpers methods to populate request. Finaly, it must also provide a method to auto send (terminate) the responce to the client.
Lastly the responce must be handled by our application. For now we will just handle basic requests like json or Raw content data. The code must be extensible to others content (like html from a template renderer).
My intent is to implement two sorts of Controllers: HttpControllers that handle http requests, and ConsoleControllers that handle console requests (imagine something like tsfw generate database?). ConsoleControllers are out of the question for now but I think the naming is pretty good even if we never implement these.
Okay so here is my proposal:
[x] Keep the actual route registering (using anotation)
[x] Keep the actual router but:
[x] Instantiate a new controller on each requests
[x] populate request/responce/send variable with correct objects in each slot
[x] Dispatch it asynchronously
[x] Keep the actual Controller but:
[x] Rename ControllerResult to HttpController (because it contains methods to handle http things)
[x] Make HttpController a subclass of Controller
[ ] Make all demo Controllers in test app a subclass of HttpController (because, well, they are Http Controller)
I'm actually working on a PR to show this implementation working. However feel free to discuss and add your opinion here.
I post a proposal for Router and Controller refactoring. Here are the different parts of a request processing chain. We have to take care to keep the whole chain asynchronous (this is not the case with the actual code!).
The first part is routing request to actual handling code: I propose to keep the already implemented action anotations because it leave Controllers loosely coupled with the Router. It also keep the responsibility to the router to handle controller instantiation/release. The router must also handle a (configurable) timeout before auto closing a request with an error (to avoid bad async code going nowhere)
The second part is the actual Controller: This part is public and must be implemented by the end user in his application. Because the code must be async, I suggest to instantiate one controller per request to avoid accidental property sharing. The controller must expose to the end-user properties like request/responce. It must also provide a helpers methods to populate request. Finaly, it must also provide a method to auto send (terminate) the responce to the client.
Lastly the responce must be handled by our application. For now we will just handle basic requests like json or Raw content data. The code must be extensible to others content (like html from a template renderer).
My intent is to implement two sorts of Controllers: HttpControllers that handle http requests, and ConsoleControllers that handle console requests (imagine something like tsfw generate database?). ConsoleControllers are out of the question for now but I think the naming is pretty good even if we never implement these.
Okay so here is my proposal:
I'm actually working on a PR to show this implementation working. However feel free to discuss and add your opinion here.