3 ms·

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

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 https://go.dev/play/p/1m-6hO93Xce

deleted 1y ago
[deleted]
never_inline 1y ago
You can annotate `json:"-"` which is equivalent of @JsonIgnore
- zimpenfish 1y ago
  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 1y ago
That works, but then you also can't access isAdmin from another package.
- pdq 1y ago
  You can just make an IsAdmin() public function to expose it.
zimpenfish 1y ago
> 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 1y ago
  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 1y ago
    > 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 1y ago
      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 1y ago
  Humanity should ignore gorm in all honesty

deleted 1y ago

[deleted]

never_inline 1y ago

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

zimpenfish 1y ago
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 1y ago

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

pdq 1y ago
You can just make an IsAdmin() public function to expose it.

zimpenfish 1y ago

> 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 1y ago
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 1y ago
  > 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 1y ago
    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 1y ago
Humanity should ignore gorm in all honesty