It talks about the drawbacks of having a single Go struct serve as both the schema for the database and the schema for the API. It recommends (correctly) that d

It talks about the drawbacks of having a single Go struct serve as both the schema for the database and the schema for the API. It recommends (correctly) that developers should avoid this, and write two Go structs, one for the API and one for the database, and then manually write some glue code between the two That's been the standard in just about every enterprise Java app I've worked on. Having separate internal and external data models is critical for managing change and preserving backwards-compatibility of your API.