FastAPI – Easily create robust, standardized API endpoints in Rails and Postgres
github.com
github.com
A classic example that we ran into repeatedly: Assume you want to have an endpoint that populates a user's profile (for the user to see). You probably want id, name, email, age, location, created_at, updated_at, etc. However, when exposing this same user instance through an endpoint that publicly aggregates users (e.g. search), sending over all those fields is 1) overkill, and 2) raises privacy concerns.
So far, my favorite approach to this problem uses the ActiveModel::Serializer gem (https://github.com/rails-api/active_model_serializers). It moves the JSON logic to something more akin to a view, and provides an easy way to present instances differently depending on the context.
Once you need a list of all the glass marbles with their attributes, but can only see the color of marbles you supervise, and only the radius of a marble if it has a shooter role and only the names and emails of marbles ranked above you... ...and so on... it becomes a situation where each result has to be filtered item by item pretty much. And the filter hierarchies will snowball like tribbles.
Although you can model permission hierarchies, I think there are enough corner cases that it's worthwhile to declare permissions as explicitly as conveniently possible.
API Docs: https://djangorestframework-composed-permissions.readthedocs...
Is there a way to speed it up when building large responses?
AMS have unfortunately no caching by default, and the development was stale for almost a year.
The mailing list is active again since the last couple days, so it might get fixed soon.
I think you've conflated serialization and presentation here; if I can't reconstitute the whole object from the serialization provided, then it's not a serialization, it's a presentation. A valid presentation might be "the serialization of this object", but "a subset of this object suitable for display" is not a valid serialization.
I would argue that it merely allows for more automated (albeit implicit) generation of a View.
The goal here was to simplify the API endpoint creation process for the vast majority of use cases, and provide a standard output that could be easily recognized and consistently managed by any external software.
You might take a look at the Presenter pattern; Draper is an excellent implementation of it, which permits for this kind of "model-attached" view behavior, while maintaining proper MVC separations.
[0] https://github.com/intridea/grape [1] https://github.com/jrhe/grape-active_model_serializers
a) information on existing solutions is hard to find/not obvious or otherwise in the world of unknowns to the author
or
b) existing solutions are too generalized or otherwise structured in ways that don't work for whatever real world particular business cases.
I ran into this with permissions in my current project. Nothing obvious in my realm of knowledge fit (sometimes I suspect this happens because projects only advertise their basic features clearly). So I now have a massive custom permission layer.
Sometimes you also end up with things like this by accident - you need one thing, it's not worth going whole hog to begin with, but then suddenly stuff gets tacked on until you have a whole system you never set out to build.
This allows for "people/?age__gte=25" and other simple logic filters that can be communicated over the HTTP request, and is standard across all models and endpoints.
https://github.com/activerecord-hackery/ransack/wiki/Basic-S...
Our approach was meant to attack a combination of common, specific problems (standardized way to output API data, queryable with logic via HTTP parameters, a single SQL query to collect and aggregate data) with a dead simple, low-overhead solution.