ngscheurich
Polymorphic field in Absinthe
Hi all! My GraphQL education is still in a fairly nascent stage and I’ve run into an issue that seems like it should be easy to solve, yet I can’t figure out a solution. This makes me think I have a flawed mental model and/or a suboptimal implementation.
Here’s a brief rundown of the relevant pieces of my application, with some of my possibly incorrect understandings made explicit:
- A PostgreSQL table,
datapoints, that contains apayloadcolumn (among others) which is set to themaptype in my Ecto migration. As far as I understand, this configuration means that Ecto will create that column asjsonband encode/decode as appropriate. - The
payloadmap should contain a:valuekey which is one of data shapes: a boolean value, a string, or a list of strings. I am enforcing this rule via various strategies which I can’t imagine have any bearing on my GraphQL conundrum. - An Elixir module that defines an Ecto schema for the
datapointstable withfield(:payload, :map). - An Elixir module that defines an Absinthe schema. It defines an object,
:datapoint, as part of the root query object.
My issue comes into play when I try to define the :payload field on the :datapoint object in my schema, i.e.:
object :datapoint do
field(:id, :id)
field(:name, :string)
field(:type, :string)
field(:payload, # ??? #)
end
How should I tell Absinthe that this field should be one of type :boolean, :string, or list_of(:string)? I’ve gone down quite the rabbit hole of unions, interfaces, and custom scalars, but nothing seems quite right… I can share more code upon request, but I don’t want to start this off with a giant wall of text, and I’m hoping I’m missing something simple. ![]()
Any help is very greatly appreciated!
Marked As Solved
benwilson512
Once again you’re actually 100% on the right path. The GraphQL type system has your back here actually, because you’ve got 3 completely different return types, so it forces you to articulate the branches you want to handle:
query ($elderId: String!, $datapointName: String!, $count: Int) {
datapointsForElder(elderId: $elderId, datapointName: $datapointName, count: $count) {
name,
type,
payload {
... on BooleanPayload { __typename value }
... on StringPayload { __typename value }
... on ListPayload { __typename value }
}
}
}
The addition of __typename is handy since it will annotate in the result JSON which outcome it was.
And yeah! I’m looking forward to the conference as well, please stop by and say hi!
Also Liked
benwilson512
Hey @ngscheurich!
The GraphQL type system only permits unions between objects. This leads to the following slightly cumbersome solution:
object :boolean_value do
field :value, non_null(:boolean)
end
object :string_value do
field :value, non_null(:string)
end
object :string_list do
field :value, list_of(:string)
end
union :payload do
types [:string_value, :string_list, :boolean_value]
resolve_type fn payload ->
#exercise for the reader
end
end
ngscheurich
Thanks for the quick response, @benwilson512!
So, it seems like I was sort of on the right path, which is a nice sanity check. Here’s the code I was working on:
object :boolean_payload do
field(:value, :boolean)
end
object :string_payload do
field(:value, :string)
end
object :list_payload do
field(:value, list_of(:string))
end
union :payload do
types([:boolean_payload, :string_payload, :list_payload])
resolve_type(&resolve_payload_value/2)
end
defp resolve_payload_value(value, _) when is_boolean(value),
do: :boolean_payload
defp resolve_payload_value(value, _) when is_binary(value),
do: :string_payload
defp resolve_payload_value(value, _) when is_list(value),
do: :list_payload
My confusion is around how to write the query, e.g., what I should sub-select on payload here:
query ($elderId: String!, $datapointName: String!, $count: Int) {
datapointsForElder(elderId: $elderId, datapointName: $datapointName, count: $count) {
name,
type,
payload {
???
}
}
}
I’m looking at inline fragments at the moment, like ... on BooleanPayload { value } but something about that doesn’t seem quite right…
It seems like I have more of GraphQL problem, so I’ll study up on that part of the equation—any advice is, of course, appreciated though.
P. S. Looking forward to seeing you at The Big Elixir this week!
benwilson512
This is really more of an ecto qustion than an Absinthe question. I’d use a custom ecto type that always returned dates instead of sometimes an atom. Your GraphQL clients shouldn’t know or care that you’re using mysql.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #javascript
- #code-sync
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








