Ash.Api.Dsl (ash v1.51.2) View Source
A small DSL for declaring APIs
Apis are the entrypoints for working with your resources.
Apis may optionally include a list of resources, in which case they can be
used as an
Ash.Registry in various places. This is for backwards compatibility,
but if at all possible you should define an
Ash.Registry if you are using an extension
that requires a list of resources. For example, most extensions look for two application
environment variables called
:ash_registries to find any potential registries
Table of Contents
List the resources present in this API
resources do resource MyApp.User resource MyApp.Post resource MyApp.Comment end
:allow_unregistered?- This is still experimental, but will be supported if you run into any issues.
By default, an api will only work with resources that are explicitly included in the provided registry. In order to separate your application into multiple domains, you may wish to "mix and match" your resources across contexts. Specifying this option allows you to refer to resources in different apis in your resources, and allows providing any resource to api actions (to facilitate that requirement).
Be sure to remove the Ash.Registry.ResourceValidations extension from your registry as well. The default value is
:registry- Allows declaring that only the modules in a certain registry should be allowed to work with this Api.
This option is ignored if any explicit resources are included in the api, so everything is either in the registry or in the api. See the docs on
Ash.Registryfor what the registry is used for.
To optimize for compile times, you can place the connection from the api to the registry in application configuration.
To accomplish this:
- Configure an
otp_appwhen using your api, e.g
use Ash.Api, otp_app: :my_app
- Add application config to set up the connection
config :my_app, MyApp.Api, resources: [ registry: MyApp.Api.Registry ]
A reference to a resource
:resource- Required. The module of the resource