rbino
Some context to avoid the XY Problem: I’m trying to expose some state which lives in an external API as a resource field.
Let’s say I have a User resource and I want to retrieve the URL for their Gravatar given their email. My understanding is that I can do this with a calculation
calculations do
calculate :gravatar_url, :string, User.Calculations.Gravatar
end
defmodule MyApp.User.Calculations.Gravatar do
use Ash.Calculation
alias MyApp.GravatarAPI
def calculate(users, _opts, _context) do
Enum.map(users, fn user ->
case GravatarAPI.fetch_url(user.email) do
{:ok, url} -> url
{:error, _} -> nil
end
end)
end
end
The problem with this solution is that if I retrieve a list of users using, e.g., GraphQL, the current implementation just silently returns nil without letting the user know that, e.g., the API request failed for a specific user (which is something which can potentially be shown in GraphQL errors).
On the other hand, if I return {:error, :something} if anything fails a single failed API request makes the calculation fails for all the users.
Is there a way around this? Am I using the wrong Ash tool?
The other possibility I thought of is using a resource with no data layer instead of a calculation. n that case, if I call both Simple.set_data and Ash.Query.add_error does the whole query fails (so nothing gets exposed from GraphQL) or is the partial data shown alongside the error?
Trending in Questions
Other Trending 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
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #ai
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming











Showing Posts 1 to 4- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
zachdaniel
This is a good question :). While I think there is something we could do in the future to make this more seamless, if you have a calculation that can partially fail, the best way to do it is to use an embedded type for the return type.
rbino
Thanks, this is indeed an interesting way to go.
I still have to explore how AshGraphql exposes errors, and see if I can expose an error in the retrieval from the API in a similar way
zachdaniel
Yeah…honestly this is probably something that we should add as a feature of calculations, so that calculations should be allowed to fail. Fail-able calculations would have something like
field: %Ash.CalculationResult{result: "result", errors: []}. ThenAshGraphqlcould use thatzachdaniel
The recent refactor of calculation loading would likely make this a relatively simple thing to support, but it would take some time/effort still.