> wouldn't the obvious way be to make the private field private (lowercase)?

That may break other things - `gorm`, for example, will ignore private fields - inconvenient if you want to serialise `User` to your DB.

▲

CactusRocket a day ago | parent | next [-]

If you use the same struct in both an HTTP API and an ORM, you're Doing It Wrong in my opinion. These should be completely separated. Exactly to prevent accidental leaking or injection of data.

▲

zimpenfish a day ago | parent [-]

> If you use the same struct in both an HTTP API and an ORM, you're Doing It Wrong in my opinion.

If you mean "public API", yep, 100% agree. Internal API between microservices though? Perfectly safe and cromulent, I'd say.

	▲	CactusRocket 10 hours ago \| parent [-]
		I tend to disagree with that, also. :) Even within one codebase there's immense value in having separate structs/classes per "layer" or domain. E.g. a different set of structs for the database layer than for the "business layer" (or whatever your application's internal setup is). When that boundary is moved to outside the application, so an HTTP API between microservices, I feel even more strongly (though indeed still not as strongly as in what you call a "public API"). E.g. I have seen plenty of times a situation where a bunch of applications were managed within one team, the team split up and now this "internal API" has become an API between teams, suddenly making it "public" (when viewed from the teams perspective).

▲

CafeRacer 2 hours ago | parent | prev [-]

Humanity should ignore gorm in all honesty