feat: base images subscriptions

[lusergit]

Base images subscriptions

Exposes subscriptions for the base images domain, allowing users to subscribe to CUD operations on

• Base Images
• Base Images Collections

Checklist

• I have read the CONTRIBUTING.md
• I have added tests that prove my fix is effective or that my feature works
• I have added or updated documentation (if appropriate)

[coveralls]

Pull Request Test Coverage Report for Build bf28b85f909e6cfa1a2d8faf0979a4904073df67-PR-1197

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+77.8%) to 77.757%

---

Totals
Change from base Build 21471501704:	77.8%
Covered Lines:	2545
Relevant Lines:	3273

---

💛 - Coveralls

[ArnelaL]

Since we’re also adding subscriptions for the :destroy action, it would be beneficial to add tests covering those cases as well.

Additionally, I suggest adding an option to subscribe only to a specific base_image or base_image_collection. This can be achieved by defining a read action by ID on the resource:

    read :get_by_id do
      argument :id, :uuid, allow_nil?: false
      get? true

      filter(expr(id == ^arg(:id)))
    end

and using that action in subscription:

subscribe :base_image_updated do
        action_types [:update]
        read_action :get_by_id
        relay_id_translations [id: :base_image]
      end

[ArnelaL]

nit: I'd prefer if we stay consistent in all tests, and decide on a single format for defining queries for subscriptions. Here one test uses globally defined query and other local one, while in device_subscriptions_test the query is defined inside subscribe function.

[lusergit]

I'd say that we can let the tests decide, we don't need a fully standardized way of testing this.
I updated however the queries to provide a default one and let the tester then set the actual query to run, so that it's more similar to what happens with the devices subscriptions 👍

[lusergit]

Additionally, I suggest adding an option to subscribe only to a specific base_image or base_image_collection

I agree with you that it should be available and I think this is something the filters would be great for! Unfortunately ash does not allow to use relay IDs in sorts and filters yet, which is not ideal :(

By using a custom by_id action the schema changes, reporting an id field

type RootSubscriptionType {
  baseImage(
    "A filter to limit the results"
    filter: BaseImageFilterInput # <- this is where I would expect filters to happen
    id: ID! # <- not really here
  ): base_image_result
}

My idea hence is to wait for this kind of support from the ash library itself and not allowing this specific behavior for now (without using raw IDs),

what do you think @ArnelaL ?

[ArnelaL]

Additionally, I suggest adding an option to subscribe only to a specific base_image or base_image_collection

I agree with you that it should be available and I think this is something the filters would be great for! Unfortunately ash does not allow to use relay IDs in sorts and filters yet, which is not ideal :(

By using a custom by_id action the schema changes, reporting an id field

type RootSubscriptionType {
  baseImage(
    "A filter to limit the results"
    filter: BaseImageFilterInput # <- this is where I would expect filters to happen
    id: ID! # <- not really here
  ): base_image_result
}

My idea hence is to wait for this kind of support from the ash library itself and not allowing this specific behavior for now (without using raw IDs),

what do you think @ArnelaL ?

In my opinion, since we’ll need this behavior for certain resources when adding subscriptions on the frontend, the best approach is to implement it selectively for those resources. If and when Ash adds support for filtering by Relay ID, we can then extend this to the remaining resources.

For this PR specifically, I don’t think this type of subscription is needed on the frontend, so there’s no need to add it here.

[lusergit]

Since we’re also adding subscriptions for the :destroy action, it would be beneficial to add tests covering those cases as well.

On this, I'd make a new PR based on #1198, as in one of those commit osman introduced a macro to check the deletion, I didn't forget 👍

[lusergit]

/fast-forward