I didn't see this mentioned in the article: wouldn't the obvious way be to make the private field private (lowercase)?

(I'm not a Go developer, just tried the language casually).

    type User struct {
     Username string `json:"username_json_key,omitempty"`
     Password string `json:"password"`
     isAdmin  bool
    }

https://go.dev/play/p/1m-6hO93Xce

▲ zimpenfish a day ago | parent | next [-]

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

▲

CafeRacer an hour ago | parent | next [-]

Humanity should ignore gorm in all honesty

▲

CactusRocket a day ago | parent | prev [-]

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 21 hours 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 9 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).

▲ never_inline a day ago | parent | prev | next [-]

You can annotate `json:"-"` which is equivalent of @JsonIgnore

	▲	zimpenfish a day ago \| parent [-]
		Covered in the article along with a potential snafu - adding anything else (`-,omitempty`) turns it into a key "-", not the "ignore this field" indicator.

▲ arp242 a day ago | parent | prev | next [-]

That works, but then you also can't access isAdmin from another package.

	▲	pdq a day ago \| parent [-]
		You can just make an IsAdmin() public function to expose it.

▲ 18 hours ago | parent | prev [-]

[deleted]