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.

▲

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 11 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 3 hours ago | parent | prev [-]

Humanity should ignore gorm in all honesty

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

▲ 20 hours ago | parent | prev [-]

[deleted]