What is the right way to setup AshJsonApi?

Ash Forum Ash Questions / Help
, , ,
1

I have an sqlite database (Chinook, iTunes-like data), for which I have setup a simple Phoenix project.

The birds eye view:

  • Repo: Music.Repo
  • Api: Music
  • Router: TutorialWeb.Music.Router
  • Resources: Music.Album, Music.Artist

I setup a JsonApi for Music.Artist. The path api/json/music/artists works, but api/json/music/artists/:id errors (KeyError at GET /api/json/music/artists/5 key :arguments not found in: nil).

In IEx, Music.Artist.by_id!/1 works.

And so here are the questions…

  1. how to set this up (api to get by primary key) correctly?
  2. how to get by other attributes? (e.g., api/json/music/artists/name/Nirvana or api/json/music/artists?name=Nirvana)
  3. where to specify the load of calculations/relationships?
  4. are there public examples of AshJsonApi that I can read/learn from?

Truncated code follows:

# Api
defmodule Music do
  use Ash.Api,
    extensions: [AshJsonApi.Api]

  resources do
    resource Music.Album
    resource Music.Artist
end

# Router
defmodule TutorialWeb.Music.Router do
  use AshJsonApi.Api.Router,
    apis: [Music]
end

# Artist resource
defmodule Music.Artist do
  use Ash.Resource,
    data_layer: AshSqlite.DataLayer,
    extensions: [AshJsonApi.Resource]

  sqlite do
    repo Music.Repo
    table "Artist"
  end

  json_api do
    type "artist"

    routes do
      base "/artists"

      get :by_id
      index :read
      # post :create
      # ...
    end
  end

  attributes do
    attribute :ArtistId, :integer do # the unusual upcase attribute name comes from source db
      primary_key? true
      allow_nil? false
    end

    attribute :Name, :string
  end

  code_interface do
    define_for Music

    define :create
    define :read

    define :by_id,
      get_by: [:ArtistId],
      action: :read

    define :by_name,
      get_by: [:Name],
      action: :read

    define :alphabetical

    define :update
    define :destroy
  end

    actions do
      defaults [:create, :read, :update, :destroy]
  end
end
1 Like
2

I think you should be able to use get :read to use the default :read action and then request an artist by the primary key with api/json/music/artists/:id

I’m not sure about your other questions but the tests have some pretty good examples for loading related stuff and filtering.

Also, if you would like to abstract away the funky database column naming, you can specify the source key DSL: Ash.Resource — ash v2.15.19

attribute :id, :integer do
  primary_key? true
  allow_nil? false
  source :ArtistId
end
1 Like
3
  1. there error is bad here, but :by_id in get :by_id is not pointing at an action on the resource. You want get :read. :by_id is the name of your code interface function that also points at :read. @dblack is correct.
  2. you can pass a fiiter statement ?filter[name]=foobar
  3. You don’t specify loads in the DSL/actions, you allow the client to specify them using the include and the fields parameters. You do need to configure in the resource what relationships can be included. For example:
json_api do
  includes [
    friends: [
      :comments
    ],
    comments: []
  ]
end

Would allow using ?include=friends.comments,comments. See the JSON:API spec for more information on how fields and includes are meant to work. https://jsonapi.org/

  1. I don’t know of any open source implementations of ash_json_api unfortunately.
1 Like
4

Thank you @dblack and @zachdaniel. I started with :read but didn’t realize the error was api/json/music/artist/5 looking specifically for :id (and not the primary key). Using source to map :ArtistId to :id and this is working.

And thank you for pointing to the tests — these are terse and to the point, super clear and easy to learn from.

(4) public example: I now have ducks-in-a-row for a 2nd Primer tutorial. This starts from an sqlite c/ Livebook, passes through identities, validation, pagination, telemetry, bulk create, mermaid diagrams, and end with a minimal Phoenix app showing a json api. The Mix/Phoenix part will probably be a Github repo with sequential commits.

(This would set the stage for the last Primer, that uses AirTable-sync’ed postgres, and have auth / policies / pubsub. The trilogy should give someone new to Ash a three-hour straight path through the most important features, and let y’all answer me once instead of answering the same questions repeatedly :stuck_out_tongue: )

3 Likes