[digitaltrees]

We might release it as a framework of gems.

We created an Abstract controller that handles all of the typical behavior for a resource, auth, filtering, pagination, tenancy, import/export, serialization etc.

Then we expanded rails generators to cover ALL typical behavior. And the markdown file calls the generators.

It was a bit complicated to model polymorphic behavior but we got it working thanks to Ruby/Rails.

But the basic premise that made this work is: Use only restful actions; don’t turn it into RPC. Recognize that most RPC/graphql functions are state changes that could have been a patch request. So instead of /clients/activate its /clients with a status attribute for “activate” or “archive”. Then most nested routes aren’t needed, use accepts nested attributes for and return child ids in the show action. There’s more to it that this but by strictly following conventions and modeling the data for rest, the api ends up Super simple.

Our standard controller only whitelists strong params. All other behavior is automatic.

[mierz00]

What do the markdown files look like?

[digitaltrees]

Defines the resources, attributes and relationships. That’s it.

Client first_name last_name organization:references

Organization name tax_number has_many:Clients