Discussion regarding the complex response structure for REST & GraphQL (Developer Experience)

Discussions
35

Yup I was just re-reading through our notes from the meeting we did this morning and intended to share what we discussed and what we are thinking.

Actions we are taking right now:

  • Doing a bit more research into other existing implementations such as Facebooks Relay: https://relay.dev/ and how they are doing things as functionally our setup is very similar to theirs
  • Researching a bit into getting caching working (it is possible but not just as simple as apollo’s native config for it) as it’s a huge area of concern from everyone

Actions we plan to take in the next month or so:

  • Have a community call (or steal part of an existing one) to cover some of the background with this
  • Record a video or write a lengthy blog-post explaining some of the future needs we have from the response structure to support the following three features:
    • Content Versioning
    • Publication Workflows
    • Better meta information about an entity’s i18n locale
  • Breaking down our focus towards keeping things stable and some bits of the longer term plan

What we discussed was the following (keep in mind we aren’t taking a full decision right now because some people are on vacation next week and we want to do more research before we just rush into things).
I hope everyone can understand we don’t want to just take a decision on this lightly, especially now that we have extended the v3 EOL til Sept 2022.

  • Removing data {} is not possible now or in the future because it would conflict with high level meta {}
  • attributes {} could be removed in theory now but it would conflict with our long term plans in the future with meta {} (merged, we will probably touch on this in the video/blog post)
  • We are willing to make a breaking change for GraphQL plugin but would require a long and complex RFC before we would do that, not a short term solution but yes a plugin could technically be ejected from the versioning system the core uses. There would need to be a lot of validation from the community around the RFC that we didn’t have when we first issued the RFC (largely the problem on our side because it wasn’t clear what feedback we wanted, and it wasn’t shared enough)
  • Researching Relay => why does it work so well => why is it so accepted by their community => what learnings can we take from that => their caching layer?
  • Can SDKs help the end user? Is this stuff we can build to help?

We also discussed a bit on the RFC side and what went wrong and how to prevent it in the future:

  • RFC needs more readers AND interactions (comments, discussions, debates, not preferences but breaks downs on why an alternative is better with trade offs, ect)
  • More data in the RFC, too much internal information and context wasn’t shared
  • RFC format wasn’t clear enough, not enough descriptions
  • RFC process was too fast // Strapi v4 Beta process was too short (won’t happen again, we were under a time crunch due to poor timeline planning in v4)
  • Ideally we really should publish RFCs long before we start development and engineering team needs to be more active reading responses and responding to RFCs. Small team problems that we are fixing slowly but simply we need more devs.

Funnily enough one of the original respondents to the RFC when we published it was a community member who now works for us so we were able to rapidly gather some cool insights and in the future we would like to have some of these discussions in person such as in community calls going forward as it was really helpful to get that point of view.

TLDR: Nothing major happening right now, it’s clear we need to do some research but we need to make decisions carefully, we can’t “just revert” back to v3 style. Keep in mind that we did what we did as we were building pre-reqs for what we want to build in the future (ideally this year). That was never described to any of you and it’s what we need to do now.

Give us a bit of time we are listening and we do plan to engage with the community to find a working resolution to this. Your opinions are very valuable to us, time crunches just didn’t make things easy and too much got rushed.

5 Likes