[HN Gopher] The 'fat service' pattern for Go web applications
       ___________________________________________________________________
        
       The 'fat service' pattern for Go web applications
        
       Author : ingve
       Score  : 22 points
       Date   : 2022-08-08 14:49 UTC (8 hours ago)
        
 (HTM) web link (www.alexedwards.net)
 (TXT) w3m dump (www.alexedwards.net)
        
       | taffer wrote:
       | Looks like the Transaction-Script pattern with an API Layer on
       | top.
        
       | hu3 wrote:
       | 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.
        
       | lakomen wrote:
       | What's next, how to assign values to variables?
       | 
       | This is ancient stuff, beginner stuff. Also I don't agree that
       | the service should be internal. Useless
        
       | jollyllama wrote:
       | Lack of db switchability and mockability are too much for me.
       | Maybe I'm too old fashioned. But the author does a good job of
       | highlighting these drawbacks.
        
         | morelisp wrote:
         | sql.DB is already switchable/mockable underneath. Please stop
         | mocking layers above it just to map to other SQL stores.
        
         | battery_glasses wrote:
         | How often do you find yourself migrating DBs in the course of a
         | project's lifetime?
        
           | jollyllama wrote:
           | Point taken, but IMO it is beneficial to split tests
           | correctly into unit tests vs integration tests, so the
           | ability to be able to mock the call or switch to a test db is
           | highly desirable. Of all of the projects I've worked on over
           | the last five years, there was some external impetus to
           | change db's at least once.
        
       ___________________________________________________________________
       (page generated 2022-08-08 23:02 UTC)