FastAPI – Easily create robust, standardized API endpoints in Rails and Postgres
1–10 of 26 posts
Re: FastAPI – Easily create robust, standardized API endpoints in Rails and Postgres
#2I'm confused as to why view logic is being moved to the Model layer, directly breaking MVC. Why is this better than using the tools in Rails that already exist for every use case here? Is there a performance increase?
Re: FastAPI – Easily create robust, standardized API endpoints in Rails and Postgres
#3Why would I use this over ActiveModel::Serializers?
Re: FastAPI – Easily create robust, standardized API endpoints in Rails and Postgres
#4Why was this even created? ActiveModelSerializers or Rabl works just fine
Re: FastAPI – Easily create robust, standardized API endpoints in Rails and Postgres
#5I'm confused as to why view logic is being moved to the Model layer, directly breaking MVC. Why is this better than using the tools in Rails that already exist for every use case here? Is there a performance increase?
I came here to say the exact same thing. After having worked on/scaled an API that served >100k requests per minute, I feel I can say with some experience that defining your JSON in your model is a very bad idea.
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.
Re: FastAPI – Easily create robust, standardized API endpoints in Rails and Postgres
#6I'm confused as to why view logic is being moved to the Model layer, directly breaking MVC. Why is this better than using the tools in Rails that already exist for every use case here? Is there a performance increase?
Good question. If you consider each API endpoint a very specific serialization of a model, are the serialization parameters considered part of the model itself? (I would consider them such, and decided to approach the development with that in mind.)
Re: FastAPI – Easily create robust, standardized API endpoints in Rails and Postgres
#7Why would I use this over ActiveModel::Serializers?
The goal of this project is for easy model accession / querying via JavaScript or some other external interface. The most powerful part of this implementation, I would argue, is the filtering of endpoint data via request.query_parameters.
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.
Re: FastAPI – Easily create robust, standardized API endpoints in Rails and Postgres
#8Why would I use this over ActiveModel::Serializers?
The goal of this project is for easy model accession / querying via JavaScript or some other external interface. The most powerful part of this implementation, I would argue, is the filtering of endpoint data via request.query_parameters. 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.
Couldn't you easily accomplish the same thing via the ransack gem?
https://github.com/activerecord-hackery/ransack/wiki/Basic-S...
Re: FastAPI – Easily create robust, standardized API endpoints in Rails and Postgres
#9Earlier quoted context omitted.
The goal of this project is for easy model accession / querying via JavaScript or some other external interface. The most powerful part of this implementation, I would argue, is the filtering of endpoint data via request.query_parameters. 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.
Couldn't you easily accomplish the same thing via the ransack gem? https://github.com/activerecord-hackery/ransack/wiki/Basic-S...
Yes, I'm sure you could --- in combination with ActiveModel::Serializer.
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.
Re: FastAPI – Easily create robust, standardized API endpoints in Rails and Postgres
#10Why was this even created? ActiveModelSerializers or Rabl works just fine
The reason this project (and many others like it) exist is pretty obvious: Lots of people have to build different kinds APIs using rails, get some experience with Rails, discover it sucks for building APIs out of the box (to much anti-DRY repetition, doesn't deal with auth/permission dichotomy well), and then proceed to roll their own API layer/Auth layer/Permission layer because either:
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.