search

BTBTravis / redi-run-api

Python Backend for a student project redi-run
0 stars 1 forks source link

Training data requests #5

Open khomtali opened 4 years ago

khomtali commented 4 years ago

Hi @BTBTravis In airtable there are 3 tables:

  1. Plans
  2. Trainings
  3. Types

The third one I need only for collapsable descriptions (plan to do one more Route for it with path="/training/info", because together with training plan will be too much information for one page). So if you could do another endpoint for that table, it would be great. Or I can create a constant for that informations such as a const with zones descriptions.

About plans, in PR #34 I've added two select forms and I would like to send its values to backend to get the right training plan. Could you please also implement this opportunity instead of returning all the table? Is it possible in air table? Then as I see that a link in airtable (ex field Training 1) to the right training I receive as a key to the second table. And I don't understand how it can help me to get info about this training from the 2nd table... Is it possible to have instead of this key an object of this training under the fields Training 1 and Training 2? Alternative is not so crucial because if it exists it's always a cross-training.

BTBTravis commented 4 years ago

Hey @khomtali I'm a bit confused already includes types no? https://btbtravis.github.io/redi-run-api/#/default/get_trainings

BTBTravis commented 4 years ago

As far as the cross referencing of fields I think would best to do this on the frontend. Directly after you fetch the training data you can parse it into the structure you app needs.

khomtali commented 4 years ago

Hey @khomtali I'm a bit confused already includes types no? https://btbtravis.github.io/redi-run-api/#/default/get_trainings

yes, sure. My idea was to upload only types without other info. I would like to upload training plans only after user presses 'configure' button on training tab. Maybe the best solution will be just to create a constant for types description.

BTBTravis commented 4 years ago

You may want to make the fetch call as the app loads then store the results somewhere. Then as user browser the app the info will be ready and you can display parts of the data such as types earlier then full training plan later. I think it will be smoother because the data will be instantly there when switching tabs vs switching tabs and having to wait for another server call.

Also I noticed the first training data request every minute is quite slow. This is because the backend has to do several calls to airtable and there is a rate limit. After it calls it stores the result in cache for a minute. So the next call is near instant. If you want this to be faster please create a backend issue and I'll think of a way to improve it. We could have longer cache for example or setup a cron to call airtable every 30min and make the cache 30min...

BTBTravis commented 4 years ago

I'm not a fan of hard coding the types because is possible for the data to change in airtable and then code changes would be needed...