We have a pretty big Custom Type with many possible slices.
When trying to fetch a document (with Appolo client) the request fails with HTTP 413 which indicated it is too long.
The project is a mobile app in react native so we make this call directly from the app, not like a Gatsby site that only does it once and could maybe find ways to build it differently (the web team does not have the same problem)
I have found some related issues here in the community but none gives a solution to this problem, an elegant one if possible.
Things we have thought of
using very short fragment name: nor scalable nor readable
making a very simple request with fragments without attributes to retrieve the slice order, then make one detailed request per slice type: Many requests for the mobile + quite a nightmare to then rematch slices since those do not have Ids
Currently, we are stuck, we can no longer implement new slices, making Prismic quite limited/useless for us?
As you might have already realized from reading the other threads, 413 is a common error that can only be solved by rewriting the queries to make them smaller because, at the moment, it is not possible to extend their length beyond the limit.
We have had discussions in the past where we have the idea of switching the API to accept POST requests, which allow you to make more complex queries, but we don't have a plan or ETA for when we'll start implementing it.
I'm curious to know more about your use case and to see an example of the Custom Type. Then, we can try and re-think the way the structure Custom Type schema is built before creating the queries. It is common to see cases where one custom type can be split into two or three, and then it becomes more readable.
The usecase is quite simple. We have an homage that is a succession of UI component, each represented by a slice prismic-side.
Some of the slice could be mutualized but they were created for the web before mobile and since they do not have the same issue for some reason they chose to split the slice to make those as explicit as possible for content editor who are not technical people and should not struggle with huge slices with options - especially when it's complicated in the interface to properly describe how each attribute will affect the slice behavior.
My request is in my previous message, here is the JSON schema.
Hey @nicolas.braun, thank you for sharing this with us. It is true that whenever a project switches needs or adds more complex structure, in your case, a mobile UX, it can turn difficult to re-do things again. The best recommendation that I can give you is to go back to the Custom Types and to minimize the Slices. You could use a Boolean switch to indicate when a Slice is meant to be for mobile or desktop.
There are many things you can do to optimize the way you structure content. Here I'll share with you a Content modeling guide that's very useful when trying to understand this concept
Pau
closed , flag & select 'Something Else' to reopen.
#6
Threads close after a period of inactivity. Flag this thread to re-open it and continue the conversation.