Description
Right now, the events endpoint takes 1 second to return. Which is too much. It takes 3 ms to run the SQL query. So I took a look where the issue is. Marshmallow serialization was taking too long. 950+ ms. Thought it's just slow and we can do nothing. But, when I tried querying events with sparse fieldsets and it was only taking 7 ms! I was shocked. So I took a look at all the fields being sent by the server and these fields - revenue, has_sessions, has_speakers, tickets_available, tickets_sold, tickets_remaining are running aggregate queries on event on each fetch! Removing these from schema resulted the API call time to reduce from 1 second to 9 ms. Running aggregate queries, that too not 1 but 5 on each event in a list of events is a tremendously bad idea. We don't even have proper caching in place and flask-json-restapi doesn't have a good way to leverage cache as well. So, in no way these properties are going to remain in the event schema. If there is a need of such properties, lazily load them as relationships in separate queries. I suspect these were added so that frontend could filter events accordingly. We have seen how bad this can be. It's not the job of frontend to filter and apply logic like this. These properties are not even needed for most places like home page and public event page. At most, these properties can be loaded on single event fetch, but not on every event fetch. These will be removed in coming API versions and this will make frontend load extremely faster. Read from 17 seconds to 5-6 seconds hopefully
Apparently, all relationships are loaded by Marshmallow jsonapi just to build the URLs regardless of if you want the relationship or not. So, if you fetch 1 event, every table which has relationship with the event table is queried to see the event ID. So, SELECT event_id from (SELECT * from speakers where event_id = 6). Entire speaker row loaded to get the event ID, which we already know is 6, for every event in the event list. Just the URL building is taking 500 ms for event endpoint...