Re:The ‘fat service’ pattern for Go web applications
by hu3 on Monday August 08, 2022 @03:46PM
(#32390153)
I've successfully implemented this pattern in a medium sized project with about 500 different CRUD screens and their business rules.
Works well and is very easy to grasp for newcomers to the project.
One pitfall to avoid is mixing request processing with business logic. Certain types of request processing/filtering belong to middlewares and/or the request handlers (Controller Actions). It is very easy to the inexperienced developer to put request processing inside service code.
For example: file upload handling for the user avatar, should it belong to the user service or controller? Or perhaps a dedicated async file upload handler?
I tend to encapsulate messy file upload handling and calling it from the controller so services get a clean file_id. There are different approaches though.
Works well and is very easy to grasp for newcomers to the project.
One pitfall to avoid is mixing request processing with business logic. Certain types of request processing/filtering belong to middlewares and/or the request handlers (Controller Actions). It is very easy to the inexperienced developer to put request processing inside service code.
For example: file upload handling for the user avatar, should it belong to the user service or controller? Or perhaps a dedicated async file upload handler?
I tend to encapsulate messy file upload handling and calling it from the controller so services get a clean file_id. There are different approaches though.