Load all recipes only on demand when editing a recipe

[christianlupus]

Currently, we are loading all recipes at the beginning of the editing of one recipe (here). As long as no reference is to be inserted/modified, this is just a waste of network power.

This should be delayed until it is really needed (lazy-loading).

[seyfeb]

I second this. And additionally, it could be discussed if it’s desirable to keep the data in the Vue store to even further reduce the network load

[coatmaker618]

I can see that for bandwidth constrained systems or somewhere with lots of recipes (if you are importing entire cookbooks worth of stuff--which props to you!) But I'd rather see loading in background so that if I do want to look at a few recipes I don't need to wait for it to load each one.

[christianlupus]

It is a general question what and how much information is to be cached in the frontend and what should be stored in the backend and served appropriately.

This is a fundamental decision to be made as it affects both the future API design as well as future work in the app.

I see in general three options here:

1. Do not cache anything in the frontend and rest all information from the backend.
2. Cache only pairs of id/key and recipe name.
3. Cache all recipes metadata as written in the recipes JSON file.

Of course there are arbitrary combinations of data that can be stored in the cache but the effect is mainly the same.

The caching has the following benefits (the lists might be incomplete):

• faster loading of recipes
• less API endpoints required
• direct access to all recipes within frontend

There are also some drawbacks:

• split brain possible: how to solve concurrent edits?
• cache validation: how is new data fetched/notified?
• initial startup of the app is delayed by reading all recipe

In any case, there is still the possibility to load the recipes in blocks to avoid to large requests. For the variants without much caching this will be essential for performance most probably. The Westin of pushing can be addressed separately but the main focus is the amount of data to be cached in the frontend.

There are a few locations and issues in the app that need a decision on this question. Done features might be implemented either in frontend or in backend but the frontend cache might prevent effective usage of the backend here.

I will try to get a better understanding of the timing in the next days for a cookbook with a decent number of recipes to see the overhead of reading all recipes.

I am asking all developers to state their opinion ideally with some sort of reasoning here..

[seyfeb]

I wonder where this should be going. E.g., should the app become a PWA like discussed here for the Notes app? Then it should probably have all data cached in the frontend to be able to access it offline. However this might require some large initial download (which may be done in the background). This sounds like a larger undertaking although I am no expert since I have never written a PWA myself.

We could go the route to cache a minimalistic amount of data for the recipes (id & name) which should allow us to easily do things like showing the name instead of the id for linked recipes while at the same time not requiring the download of large amounts of data. A list of use cases might be helpful to figure out which data is most relevant (e.g., should we also have a thumbnail cached?)

Regarding the points "cache validation" and "split brain": We could always query the serve for updates on a cached data item when it is used. If it is unchanged the server may return a 304 (Not Modified).

[christianlupus]

OK, sorry, I was misled by some assumptions and checked/verified these recently. I thought the /api/recipes endpoint would return the complete set of recipes including all information. This is simply wrong. I corrected also the API documentation in #1006.

The point I am still making is:
In the AppIndex component we have already a cache of all recipes in the data. This is exactly the data we need during editing a receipt and that we are (re)downloading upon showing.
If we moved the data to e.g. AppMain, we could reuse the cache.

By making the listing faster in #1003, this might no longer be a big issue.