3 ms·
Can you share an example of this approach? Because "writing CRUD structs and junk" is what my whole company does all day. Wire representation, controller layer,
by closeparen 5y ago
Can you share an example of this approach? Because "writing CRUD structs and junk" is what my whole company does all day. Wire representation, controller layer, database layer, storage representation. Typing out the big list of fields over and over with slight variations. Unit testing the mappers between them. Table-driven testing all the error branches in lists of sequential operations. Nobody ever wants to abstract the notion of data because "it's not type safe." I'd love to see a credible take on it, besides "shove everything in map[string]interface{}." It seems everything in Go's design is against this kind of abstraction.
- kardianos 5y agoThe first step is to represent the data source (eg database) in the code, so you can ask: what is the schema here? This goes beyond just the database schema, but also intent. Is this a soft delete table? How is it audited? Child/Parent relationships. So when you pass around data, it isn't "just in a map[string]interface{}", but a data buffer that knows about itself. Then you can tell it to do operations on itself, and pipe data from one system (ui) to another system (database or api). This is what Go is REALLY about. You make machines to handle your work. You don't loose meta-data; but you don't loose sleep about typing (Go is typed but not rich typing like Rust). Go is all about the tooling. When you make a line of business application, write the tool first.
- closeparen 5y agoAm I understanding correctly that a "data buffer" would be like a serialized representation with some kind of schema at runtime? That makes sense. I just don't know how to shake the standard that the fields of business entities become the fields of Go structs.