Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FastAPI – Easily create robust, standardized API endpoints in Rails and Postgres

github.com

Post reply on HN
Print view View original

21–26 of 26 posts

Re: FastAPI – Easily create robust, standardized API endpoints in Rails and Postgres

#21

Post by jordanthoms »

jerhinesmith wrote: post #5
carlosdp wrote: post #2

I'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…

ActiveModel::Serializer is really nice, but it doesn't seem particularly fast when large responses are involved - when we have 500+ comments to serialize it can take 400ms or more in the views code.

Is there a way to speed it up when building large responses?

Re: FastAPI – Easily create robust, standardized API endpoints in Rails and Postgres

#22

Post by bradrobertson »

pjam wrote: post #13

I like the idea, but I would be really reluctant to use a gem that has no tests, especially when the core methods are clearly not trivial, a bunch of them are ~100 lines long. Not that the number of lines tells how complicated a method is, but I think it is a good indicator.

I was going to say the same thing. I wouldn't even think about touching this gem. Multiple methods close to 200 lines long, all in a single file with no test suite. I shudder to think what the cyclomatic complexity of the 'api_comparison' method is. Have fun contributing to this project.

Re: FastAPI – Easily create robust, standardized API endpoints in Rails and Postgres

#23

Post by keithwhor »

adamonduty wrote: post #19

I'm a little scared that this builds SQL statements directly. Did you consider at least using prepared statements? Was there such an awful performance hit using ActiveRecord, or something that couldn't be done with it?

Yep --- couldn't effectively use and parse subqueries with ActiveRecord alone.

Re: FastAPI – Easily create robust, standardized API endpoints in Rails and Postgres

#24

Post by byroot »

jordanthoms wrote: post #21
jerhinesmith wrote: post #5

Earlier quoted context omitted.

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…

ActiveModel::Serializer is really nice, but it doesn't seem particularly fast when large responses are involved - when we have 500+ comments to serialize it can take 400ms or more in the views code. Is there a way to speed it up when building large responses?

You can add caching to it pretty easily. If you cache the objects independently and leverage memcache multiget you can get some very nice speedups.

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.

Re: FastAPI – Easily create robust, standardized API endpoints in Rails and Postgres

#25

Post by cheald »

keithwhor wrote: post #20
cheald wrote: post #18

Earlier quoted context omitted.

I don't think so. The data as presented to the user through the API is a view concern. The model should never, ever know or care about how it is presented; serialization (which is used to marshal the data as a whole for transport and reconstitution) and presentation (which is used to transform the data into some form acceptable for consumption by an external entity) are separate processes with separate goals. I think…

Good points. I think it boils down to an issue of semantics, though. FastAPI effectively eliminates (or hides) the View layer by allowing the Model to determine which fields it should allow the View to access. If you don't believe this is explicit enough (which could be a fair argument!), it's perfectly reasonable to suggest this "breaks" standard MVC conventions (as it can easily be construed as the View being part…

Well, it certainly meets those goals, but it does so by putting view logic into the model layer.

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.

Post reply on HN