1

So, I'm looking at using GraphQL as the basis for an inventory server and have a need to authenticate users. Details on this seem sparse, but in the GraphQL docs it states (emphasis mine):

We recommend passing a fully-hydrated User object instead of an opaque token or API key to your business logic layer. This way, we can handle the distinct concerns of authentication and authorization in different stages of the request processing pipeline.

Now, I understand hydration in the context of plants and animal health. I think pouring water on my servers is a risky (and expensive!) activity. Looking around, I see there's a Java library called "hydrate" (but I won't be using Java, so likely irrelevant). The term makes no sense to me in this context.

What on earth is a "hydrated" object in the context of GraphQL?

Stuart Longland
  • 19
  • 1
  • @pkamb That seemed to discuss the "hydrate" Java package or something that is stored in some non-native format (e.g. JSON) that needs parsing. As stated, I'm not using Java so the question didn't seem relevant and presumably the object I would use would already be in RAM. I'm talking about the usage of the term "hydrate" in the context of GraphQL not Java. – Stuart Longland Jan 01 '21 at 00:59
  • Even though this question refers to the GraphQL docs, the term "hydrate" as it's used there, isn't a GraphQL-specific concept. The linked dupe provides appropriate answers to what the term means. The author here is just drawing a distinction between passing a User object instead of, for example, just the id associated with the User. "Hydrated" is a bit of an odd word-choice here so your confusion is understandable. – Daniel Rearden Jan 01 '21 at 03:23
  • @DanielRearden In other words, it just refers to an object which is fully populated, rather than an "empty" place-holder object which might be populated through lazy-loading? You're right… the term "hydration" is misleading. – Stuart Longland Jan 01 '21 at 06:04

0 Answers0