Hacker News Reader

Comment by kardianos | Hacker News Reader

Have a large line of business application written in Go. The type system is just fine. Here is the key: stop writing CRUD structs and junk. Use a framework that understands your schema / data storage system. Declare what you need done, then let application definitions do the work.

"Microservices" is a business setting is somewhat laughable. After a number of years, yes, I have a handful of services that run outside of the main program. But the Line of Business core application might as well be a single executable.

View on HN

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.

The 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.

Am 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.

> stop writing CRUD structs and junk. Use a framework that understands your schema / data storage system. Declare what you need done, then let application definitions do the work.

Which frameworks have you used successfully?

> Use a framework that understands your schema / data storage system.

The whole supposed premise of golang is that it shuns frameworks. What frameworks do you recommend in golang for such applications?

You're still going to end up writing mapping logic back and forth between your RPC layer, internal layer, and DTOs. It's extremely verbose and error prone in golang to manually write them.

I'm not suggesting you use a web-framework.

If you write a business application, first have an application framework, specific to your application. And no, you won't have mapping logic between RPC and internal and DTO.

Most people don't understand how to build an application. They think in terms of RPC and encoding, not in terms of Screens, Actions, and Workflows.

> first have an application framework, specific to your application.

So we're reinventing the wheel each time no?

> And no, you won't have mapping logic between RPC and internal and DTO.

How would it work then? Use the same DTO across the board?

> Most people don't understand how to build an application. They think in terms of RPC and encoding, not in terms of Screens, Actions, and Workflows.

What are Screens, Actions, and Workflows?

Reply on news.ycombinator.com