You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are using Redis on our end to save fetch request times and have data as close to the app as possible. However, there is one functionality StoryblokClient provides, which is rels inlining, when the resolve_relations option is used.
FYI, we are using storyblok/astro, and when passing resolve_relations it does 2 things with the same flag:
Enables Content Delivery API to enrich story with resolved relations under rels: [{...}]
Instructs StoryblokClient to process story and inline relations from the array to actual usages (by uuid) in the story contents.
Problem
For bigger pages, we have huge (~10MB+) story json objects returned from StoryblokClient.get(…), caused by relations inserting to the object, which is not possible to opt-out. However, we still need to pass resolve_relations which would instruct Content Delivery API to resolve them and return via rels:[{...}] array (this is very useful, as using client all fetching content comes out-of-the-box, and need for direct link building and fetching).
We have estimated that if StoryblokClient would not inline those relations it would be only 500kb story json which we cache and do the inlining ourselves after we get story from Redis cache. That would be ideal!! Adding a diagram to showcase our business case.
This implies a couple of following ways to think of:
Either allow users to opt-out from inlining bit (possibly for links also? not sure), so they can do the rels inlining themselves
Allow Redis cache integration to the client, to be squeezed in AFTER content delivery fetching, but BEFORE inlining rels and bloating stories, leaving the latter as the last bit and uncachable (or could be configurable for better granular control)
In cases when we have resolve_relations we are doing the following branched-out logic specifically:
Fetch Content Delivery API directly
Add response to Redis cache
Before returning the story (in-app getStory util abstraction), execute custom logic to inline relations into it to have a finalized story for rendering.
Though looking into what is recommended in Reducing the size of the response it only refers to Content Deliver API, hence our problem is that Storyblok Client also reacts to resolve_relations and does the inlining part why do not need.
Unfortunately, we cannot use the StoryblokClient for such cases due to missing opt-out functionality. Or maybe there are other ways to solve the issue we are not aware of?
The text was updated successfully, but these errors were encountered:
Context
We are using Redis on our end to save fetch request times and have data as close to the app as possible. However, there is one functionality StoryblokClient provides, which is rels inlining, when the resolve_relations option is used.
FYI, we are using
storyblok/astro
, and when passingresolve_relations
it does 2 things with the same flag:rels: [{...}]
Problem
For bigger pages, we have huge (~10MB+) story json objects returned from StoryblokClient.get(…), caused by relations inserting to the object, which is not possible to opt-out. However, we still need to pass resolve_relations which would instruct Content Delivery API to resolve them and return via
rels:[{...}]
array (this is very useful, as using client all fetching content comes out-of-the-box, and need for direct link building and fetching).We have estimated that if StoryblokClient would not inline those relations it would be only 500kb story json which we cache and do the inlining ourselves after we get story from Redis cache. That would be ideal!! Adding a diagram to showcase our business case.
This implies a couple of following ways to think of:
Temporary workaround
In cases when we have
resolve_relations
we are doing the following branched-out logic specifically:Though looking into what is recommended in Reducing the size of the response it only refers to
Content Deliver API
, hence our problem is that Storyblok Client also reacts toresolve_relations
and does the inlining part why do not need.Unfortunately, we cannot use the StoryblokClient for such cases due to missing opt-out functionality. Or maybe there are other ways to solve the issue we are not aware of?
The text was updated successfully, but these errors were encountered: