The ‘fat service’ pattern for Go web applications

Re:The ‘fat service’ pattern for Go web applications by em10fan on Tuesday August 09, 2022 @04:40AM (#32395542)

In my past experience, any decently long lived bit of software (i.e. 5-10 years) goes through migrations to at least 2 different database engines (Usually as part of various other migrations like on-prem->cloud, or due to some licensing/$ reason) over its lifespan. And when you do it does tend to be quite a bit of work.

Same goes for java app containers.

[ Parent | on HN ]

Re:The ‘fat service’ pattern for Go web applications by battery_glasses on Tuesday August 09, 2022 @01:44PM (#32401189)

I guess the question for me is:

Does implementing a different pattern that abstracts away the database engine substantially lower the amount of work it takes to migrate the db in the codebase, and is it worth 5-10 years of dealing with another layer of abstraction that is unused most of the time.

My hypothesis is that even with a more configurable pattern for the DB there is still a lot of code that needs to be changed.

[ Parent | on HN ]