search

multimeric / flapison

Flask extension to build REST APIs around JSONAPI 1.0 specification.
http://flask-rest-jsonapi.readthedocs.io
MIT License
13 stars 4 forks source link

Using toastedmarshmallow for JIT #22

Open Rishi321 opened 4 years ago

Rishi321 commented 4 years ago

Has this library been tested with ToastedMarshmallow? We have been using this library to great effect recently in a project (for about 8 months), but we're now seeing some performance hits during the Marshmallow serialization (sometimes 100's of ms) when dealing with many objects (100's)

I've seen people talk about ToastedMarshmallow and notice that the compute_schema recreates schema instances everytime, according to the ToastedMarshmallow documentation this will reduce the gain heavily.

Is there a reason we recreate schema objects every time? If not, what would be the best way to change the code to allow one schema object per resource?

I tried changing the code and using an in-memory object dict as an object cache, but toastedmarshmallow still made no performance impact. Anybody tried this before?

Also posted here: https://github.com/miLibris/flask-rest-jsonapi/issues/192

multimeric commented 4 years ago

Hi @Rishi321. I'm still hoping to merge with https://github.com/AdCombo/flask-combo-jsonapi, so there is some chance you could ask this question over there.

To answer your question, though, I believe it's fairly core to this library that we can create Schema instances on the fly. For example, if the user requests certain relationships or certain fields via query params, we have to create a new schema that includes these fields, and this has to happen per request.

Consider this function, which does exactly that (builds a schema instance based on the query string): https://github.com/TMiguelT/flapison/blob/379b37774fd16197c803a7b5e3bd9eca99191337/flapison/schema.py#L12-L90.

How could we make this compatible with ToastedMarshmallow?

Rishi321 commented 3 years ago

Sorry for skipping out on the answer for so long, my attention was diverted to other projects. To answer the dynamism of the schema, we could cache the schema based on given query parameters (probably all of them).
This is still gainful because API requests are usually built into code and are standard for an app or websites pages.
Eg. If a page does a query /profiles?include=account,payments then this query is not going to change on this page unless the code of the page is changed, hence the cached schema should be the same for the same type of request on this page.