sangeethailango

sangeethailango

Given I have a nested resource with articles having many comments, how do I create an API endpoint for posting comments.
I want my API for creating comments at POST /articles/:id/comments. How do I create this nested API structure?
My resource for Articles and Comments are shown below:

Article resource:

defmodule Account.Blog.Article do
  use Ash.Resource,
    domain: Account.Blog,
    data_layer: AshPostgres.DataLayer,
    extensions: [AshJsonApi.Resource]

  alias Account.Blog.Comment

  postgres do
    table "articles"
    repo Account.Repo
  end

  json_api do
    type "article"
  end

  actions do
    defaults [:read]

    create :article do
      accept [:name]
    end
  end

  attributes do
    uuid_primary_key :id
    attribute :name, :string
  end

  relationships do
    has_many :comments, Comment
  end
end

Comments resource

defmodule Account.Blog.Comment do
  use Ash.Resource,
    domain: Account.Blog,
    data_layer: AshPostgres.DataLayer,
    extensions: [AshJsonApi.Resource]

  alias Account.Blog.Article

  postgres do
    table "comments"
    repo Account.Repo
  end

  json_api do
    type "comment"
  end

  actions do
    defaults [:read]

    create :comment do
      accept [:comment, :article_id]
    end
  end

  attributes do
    uuid_primary_key :id
    attribute :comment, :string
  end

  relationships do
    belongs_to :article, Article
  end
end

Domain:

defmodule Account.Blog do
  use Ash.Domain,
    extensions: [AshJsonApi.Domain]

  alias Account.Blog.{Article, Comment}

  resources do
    resource Article
    resource Comment
  end

  json_api do
    routes do
      base_route "/articles", Article do
        get(:read)
        post(:article)
      end

      base_route "/comments", Comment do
        get(:read)
        post(:comment)
      end
    end
  end
end

I am currently giving the request at POST /comments with the article_id to mention which article the comments belongs to.

Example:

{
    "data": {
        "type": "comment",
        "attributes": {
            "comment": "Good",
            "article_id": "article_id"
        }
    }
}

Showing Posts 1 to 6

zachdaniel

zachdaniel

Creator of Ash

You should be able to do that by including an article_id in the route params for your post.

# include at top level
post Post, :create, route: "/articles/:article_id/comments"

Your post pointed out to me that being able to nest base_routes could clean this up greatly, so I’m pushing a release w/ that ability soon. Then it would look like this:

defmodule Account.Blog do
  use Ash.Domain,
    extensions: [AshJsonApi.Domain]

  alias Account.Blog.{Article, Comment}

  resources do
    resource Article
    resource Comment
  end

  json_api do
    routes do
      base_route "/articles", Article do
        get(:read)
        post(:article)

        base_route "/:article_id", Comment do
          post :comment # would call the `:comment` create action on comment
        end
      end

      base_route "/comments", Comment do
        get(:read)
        post(:comment)
      end
    end
  end
end
shankardevy

shankardevy

wow @zachdaniel that’s super fast! You comment here is 18hours ago and I see this commit implementing this feature17hrs ago! improvement: support nested `base_route`s · ash-project/ash_json_api@bf77d4d · GitHub

This is something I was also looking for as well. However, I would like to understand the difference between using related or post_to_relationship macro inside the routes vs what you have proposed as a new solution here:

For eg., can the following do the same as what you have proposed as nested base_route for creating comment?

  json_api do
    routes do
      base_route "/articles", Article do
         post_to_relationship :comments
      end
end
sangeethailango

sangeethailango OP

@zachdaniel Thank you so much for the quick reply :smiley:. Updated to the newer version and applied the solution.

zachdaniel

zachdaniel

Creator of Ash

related is a route for reading the records of a relationship, i.e

/posts/:id/comments

It can be thought of as an index route that only returns the related records.

post_to_relationship is for “linking” a record or records to another via a relationship. It accepts a very specific input (something called “linkage”), and is typically only used to connect existing things together.

You can see more here: JSON:API — Latest Specification (v1.1)

shankardevy

shankardevy

Just to clarify, please check if my understanding is correct:

1. related option on routes

Use this only for GET requests for related records. Doesn’t work for any other methods.

If Article resource has many Tag relationship, this related option is used to fetch only the associated tags of a specific article.

In this case, the Ash action for the api is placed in the Article resource.

2. post_to_relationship option on routes

Use this option for any other methods other than GET for related records. The related record must already exist. In the case of Article and Tag relationships, both the records must exist already. post_to_relationship is used to create the linkage in ArticleTags resource.

The same applies for patch_relationship, delete_from_relationship to update or delete the link ArticleTags resource record.

In this case, the Ash action for the api is placed in the Article resource.

3. Nested base_route as explained in this post by @zachdaniel

Use this option to do any of the above actions with the main differences as below:

  1. Ash action for the nested route is present in the nested resource rather than in the parent resource as in the above options. i.e., GET /articles/:id/tags will be responded by an action in the Tag resource.
  2. In the nested resource, one has to take care of creating/updating/deleting all the links manually.

Is my understanding correct?

zachdaniel

zachdaniel

Creator of Ash

Yep! Looks right to me :slight_smile:

— All posts loaded —

Where Next? Top

Trending in Questions Top

stjefim
Hello! Suppose you are building workflow (order / task / payment) processing system with the following requirements: Each workflow con...
New
jonnycharles
I’m in search of an Elixir library that offers PDF generation capabilities similar to Ruby’s Prawn. While there have been discussions abo...
New
spammy
I’m looking to build a personal workflow to quickly deploy web applications written in elixir/phoenix, for local consumption (ie not on t...
New
dli
Before I dive in myself, did anyone successfully sprinkle Hologram into their existing LiveView app? Looking for hints regarding: Addi...
New
roeland
Kia ora, We have been using elixir-google-api to connect to Google Drive. However, with the updates to Tesla due to CVEs this is now bro...
New
bottlenecked
Hi all, I wanted to ask how the community is dealing with post-release steps. Today we have Ecto migrations, which make sure that the db...
New
rahultumpala
Hello, I have an Elixir backend that implements a custom protocol over TCP. I want to load test the backend and assess the performance o...
New

Other Trending Topics Top

JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
mcass19
ExRatatui lets you cook up rich terminal UIs in Elixir, powered by Rust’s ratatui via Rustler NIFs. Build interactive terminal applicatio...
New
Damirados
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge & Solve. They are GUI (Emerge) and State management (S...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
ausimian
Emily is an Elixir library that runs Nx computations on Apple’s MLX. Install it as the default Nx backend and Nx, defn, Axon, Nx.Serving,...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews