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.
Client first_name last_name organization:references
Organization name tax_number has_many:Clients
Have you heard about Lisp?
I might have forgotten a (
Ruby is clean. Which I love.
Wrt "forgetting" parentheses, the Lisp people have ways around that: they set up their editors so they operate on the expressions and can't "forget" a paren. They operate on the logical blocks (which is easy (because of the parentheses)).