Follow OpenCRUD specification

[Aurelsicoko]

What is the expected behavior?

We should follow the OpenCRUD specification for our GraphQL API. It will allow everyone to enjoy futures generic services like documentation (as Swagger does with REST API) and easily switch between different GraphQL APIs which are following the same specification.

Thank @schickling for the proposal! We'll add this to our roadmap and we'll certainly make the small changes when we'll develop the mutations part.

---

• I'm sure that this issue hasn't already been referenced

[derrickmehaffy]

If I might poke a little bit more at this, I think the general restAPI should as well to allow for easy use of swagger. I suggested such a feature a few months back to have swagger documentation included in strapi, but it wasn't in the pipeline.

[derrickmehaffy]

OpenAPI Specification: https://github.com/OAI/OpenAPI-Specification

For the same reason as OpenCRUD and would allow for easy use of swagger with strapi (extremely useful for documenting the API without having to "try" and decipher the documentations page: https://strapi.io/documentation/guides/requests.html#api-reference

[download13]

Resposting here:

Pagination using start and limit work well for small collections, but querying large datasets will eventually require the ability to paginate using cursors.

You can see in the OpenCRUD specification they allow using after or before as cursor parameters that enable efficient traversal of large result sets.

This feature request may be redundant if #1057 gets implemented first, but if you guys were planning on doing incremental feature additions to the GraphQL plugin, this would be a great one to have.

Thanks!

[carvajalluis]

@lauriejim if I understand correctly this is not getting done?

I'm trying to use https://gitlab.com/paulisloud/next-graphql-static-export with strapi but it asumes that you have cursor pagination with graphQL

because i would rather prefer to export my complete API , i guess i would have to create my own process then

[lauriejim]

It's not done and it's not a topic we will work on in next months.
This issue is open from a long time - no really activity on it.
This is the reason why I choose to close it.
Yap if you wan to deal with this package you will have to custom your own things.

[n8tb1t]

So, currently there is no an efficient way to fetch data with cursor.

[shved90]

I need this feature quite a bit for several projects, been forced to hack around to get persistent filters to work, instead of relying on inbuilt functionality thats been gutted by strapi.
Would love to see this implemented <3

[n8tb1t]

@shved90 can you please show, how you did it with persistent filters ?

[tobyhinloopen]

Too bad this isn't an option. I suppose one could order by some field (EG id DESC), and instead of using _start, use id_lt= using the last value of the sort column.

...that works, right? 🤔

[Steffan-Harris]

I'd like to see this feature implemented too!

[devskope]

Any word on cursor based pagination?

[baptisteArno]

Argh then I'm stuck. Is there an easy way to implement custom cursor pagination?

[derrickmehaffy]

We will be looking as cursor pagination in Q3 when we do the database refresh: https://portal.productboard.com/strapi/1-roadmap/c/73-database-layer-v4

[baptisteArno]

Too bad this isn't an option. I suppose one could order by some field (EG id DESC), and instead of using _start, use id_lt= using the last value of the sort column.

...that works, right? 🤔

This is a good workaround, it works well in my current project! It even improves performance for large offsets because it uses the power of indexes.

[derrickmehaffy]

This issue has been mentioned on Strapi Community Forum. There might be relevant details there:

https://forum.strapi.io/t/swagger-parameters-not-working-cannot-pass-column-names-to-swagger-parameters/4042/2