In Phoenix Controllers, we use the bang-versions of the Ecto Repo functions, such as Repo.get!/3. In production, these errors will be intercepted and a 404 page is presented to the user when working with Phoenix templates.
In Absinthe, is it possible to achieve something similar? I.e. when an Ecto.NoResultsError error is raised, have the following data returned with a 200 http code:
{
"data": {
"user": null
},
"errors": [
{
"message": "Not found",
"locations": [{"line": 2, "column": 3}],
"path": ["user"]
}
]
}
This allows to avoid having to write a set of case/with control structures and use the bang-versions of the Ecto functions, the same way we work with Phoenix Controllers.
Wouldn’t that be the best way to work in resolvers? If not, why? Any alternatives?
I went for a hybrid approach where
- resources’ IDs passed directly as arguments are processed by a middleware which attempts to fetch the resource and puts it in the context, or adds an error (in errors). Example:
field :create_foo, :create_or_update_foo_result do
arg :input, non_null(:foo_input)
arg :organization_id, non_null(:id)
middleware Middleware.HandleNotFoundError,
arg: :organization_id,
context_key: :organization,
fetcher: &MyContext.get_organization(&2.current_user, &1)
resolve(&Resolvers.MyContext.create_foo/3)
end
I can then access the organization in this example from the context.
- IDs passed in the attrs map for the context (
:input object above) are handled by foreign_key_constraint/3 when building the changeset, and I return to the client either changeset errors (in data) or a specialized object like BarNotFound { id }.
And this is where it’s really, really nice to work with soft deletes where I do not have to return nice errors to the client in case there is a foreign key error and deal with annoying questions related to concurrent fetch/delete operations driving one’s crazy (with soft deletes, foreign key errors would only be coming from either a malicious user trying to change the IDs or from a programmer bug).
