"Side effect" terminology is confusing

[benjie]

Perhaps we should use "mutation" instead.

Hi, I'm trying to convert my server from v4 to v5, starting with custom resolvers.
In the migration guide, in makeWrapResolversPlugin, I see that "Plans with side effects are only expected/supported in field plans on the Mutation type. Side effect plans elsewhere may lead to unexpected results."
Is there another way of connecting queries (not mutations) to external systems? S3, Grafana, ... I'm primarily concerned about "custom columns" that need to be read from auxiliary systems outside of the database, which we previously implemented using plain custom resolvers.

---

Discussion centres around using loadOne/loadMany to load resources from an external server.

---

I think the only cause for my confusion was the term "side effect" which has different meanings depending on context: in React and languages like Scala/Haskell, a side effect is anything that is visible outside of the function/component itself - a network call, logging, ... - as in "a pure function has no side effects visible to any observer", e.g., 1+1.

Looking at the GraphQL spec, it uses the term in a lot looser way - "a side effect-free field resolution must not modify the database" or something like that, e.g., no INSERTs during a query.

This led me to start with the Grafast sideEffect() plan, and to assume that a lambda() must be a pure (= side effect-free) function (not to break optimizations or whatever). Not sure if there's anything to fix: reading the docs again, I see a hint of if in the sideEffect docs (is expected to have a side effect (change data or state on the backend)).

---

Me:

In GraphQL we generally only care about whether the client can observe the side effect or not.
Thanks for calling this out; I don't come from a Scala/Haskell background so I would never have considered a network fetch as a side effect! (To me, that's just an implementation detail.) I do understand that you wouldn't do a network fetch in a pure function (or in PostgreSQL terms: "immutable"); for me side effects are equivalent to Postgres' VOLATILE and non-side effects can be IMMUTABLE or STABLE. This may be wrong, and maybe we should change the name of the method.
(Though technically a network fetch isn't necessarily STABLE. And a client can't necessarily directly observe all side effects, but often they're still detectable via inference - e.g. if you can insert a record but not see the result, attempting to insert the record again may yield an error.)
Maybe I should just rename it to mutation.
I just wanted to avoid using that because it might confuse with the GraphQL operation type itself.