Transparency + Roadmap

[ivosabev]

I've been using Relay since early 2016, and although I think it is the better paradigm than Apollo, there is a lot of frustration about the lack of transparency on the future of Relay. To an outsider the project seems to be moving very slow without a clear roadmap and time targets.

First there was the huge black hole between classic and the release of modern. There was no clear function set, no way to track the progress and no clear release date.

Last year there were meeting notes which were bringing some sort of security in terms of what is happening with the project, but they have unfortunately ceased.

I understand that in order to accelerate the project there is a need for outside contributions, but there are a lot of stale pull requests from outsiders that have unclear fate. I am sure there are certain design decisions that prevent them from being merged, but if those decisions were clearly presented in the first place it would have been easier to submit pull requests and move them forward faster.

Also it seems that the Relay team is reluctant to introduce features that are not directly related to the work of Facebook. Example would be some advanced subscription use cases, live queries, local schema, offset based pagination. Especially frustrating is the lack of clear guidelines on implementing complex cases with filters, pagination and cursors. I know people have hacked their way through those and have made them work (as I have personally done), but I am sure a lot of people will agree that they are core features and should be implemented properly without hacks and well documented use cases should be provided as part of the official documentation.

I am sharing all this, because I care about Relay and I wish the core team puts more effort to communicate its intentions with the people using and supporting Relay.

Thanks!

[josephsavona]

@ivosabev Thanks for your post and your patience. Much of the core team (myself included) are at React Conf this week so we'll give a proper reply next week. This is definitely a topic we're thinking a lot about and we appreciate your raising this issue.

[josephsavona]

Hey there, it's the end of the week so we wanted to give an update on this. As general context, note that the Relay core team has grown recently and we plan to (continue to) invest in Relay at Facebook. With respect to Relay open-source, we're actively discussing this internally and working to define concrete goals and a plan. Part of that will include reaching out to folks to get more feedback about the community's priorities.

So: thanks again for your patience so far, and please bear with us a bit more as we work out a plan for open-source. We want to make sure that we'll be able to follow through on whatever we commit to.

[juhaelee]

Thanks for the update @josephsavona. I really hope that you guys don't give up on continuing to support relay open-source. It's been a huge part of why I love developing again! Huge thanks to the relay team & contributors.

[sapkra]

@josephsavona Are there any news?

[josephsavona]

Thanks again for writing this and for your patience. We hear your frustration about the lack of transparency, responsiveness, and progress on issues relevant to the community. I speak on behalf of the team when I say that the we care about open-source and supporting the Relay community, and we'd like to do better. We've discussed this quite a bit over the past few weeks and have a provisional plan for going forward with Relay open-source that we'd like to share, along with an update on the state of the project and an overview of our roadmap.

First, it's important to note that Relay remains successful at Facebook: not only are we continuing to invest in Relay, we're dramatically increasing our usage and investment. Part of that includes support from our leadership to invest more in open-source. Of course, we have to be deliberate about prioritization, our goals (and non-goals) for Relay, and who our target audience is. To that end, we want to reiterate that our primary focus with Relay is performance and scalability (via features that support large and/or complex apps) and that we're generally willing to trade some amount of developer experience or flexibility in order to achieve those properties. We will continue to be highly wary of any contributions that could regress performance; within that constraint, however, we're open to feedback and contributions that make Relay easier to use.

Plan for OSS

What this means for the Relay open-source project is that, in the short-term, the core team will focus on supporting folks who are already using Relay. In particular we hope to improve the APIs for common tasks, fix bugs, and help the community to implement key features that are difficult to achieve without our collaboration. To achieve this we will experiment with regularly devoting time for the whole team to check-in on the community, review PRs, give updates on the roadmap, etc. It will be an iterative process to for us to learn how to better support the community, so please continue to give us feedback and suggestions. We can't commit to addressing every last issue, but we will work to address the most urgent issues first. Some things we're considering here are persisted queries (in open source) and configurable object identity. Our leadership team is supportive of and excited about this plan.

Tentative Roadmap

Finally, we have a bunch of exciting features on our roadmap:

• Support for “data-driven dependencies”. We recently landed support for a new @match directive that is designed to support dynamically loading the React component(s) most appropriate to render a piece of content. Rather than have to download all the code to handle all the ways you might render a piece of content (imagine some content that may be markdown or plain text and has to be rendered appropriately), @match allows the client and server to negotiate how that content will be rendered (e.g. which React component). The selected component - and its data dependencies - can then be downloaded dynamically. We're early in the work that needs to be done here but we're really excited about this feature.
• Simplifying the React/Relay APIs. Relay Modern dramatically simplified the core of Relay, but to ease migration we kept the React integration APIs such as QueryRenderer and FragmentContainer very similar to their classic counterparts. We now have extensive experience with these APIs ourselves and via feedback from the community - Relay isn't as easy to use as it could be or as we would like it to be. We plan to simplify the React/Relay APIs to make common tasks such as pagination and refetching easier to understand and implement. Of course, API changes can be disruptive, so our plan is to keep existing APIs working as-is as much as possible, and potentially augment them with opt-in alternatives.
• Compatibility with React Suspense and Async/Concurrent Mode. We've been closely collaborating with the React core team in anticipation of these exciting features. The simplified version of the React/Relay API will also be suspense- and concurrent-compatible.
• Incremental data-delivery with @defer and @stream. We're planning to implement them and document the client/server contract for others to implement in open-source.

The end of the year is approaching, so look for another update in January or early February. Happy Holidays!

[kastermester]

@josephsavona The simplifications you are talking about include the work that is being commited at the moment with the @refetchable directive I assume?

Love the plan, sounds great! Would it in any ways be possible for you to share some more concrete details of some of these new features/changes? Maybe some example code or something similiar? I'm thinking we are probably many that would love to either plan the way we structure our own code and/or provide some feedback that might help drive the APIs and features even further :)

[josephsavona]

@kastermester we're working to get the relay-experimental package back in open-source (we removed it because of some issues with syncing and version compatibility). It will be easier to share details once there's code in oss to point to. Expect an update in the next couple weeks.

[josephsavona]

A couple updates:

• Now that React 16.8 is out and there is an official release with hooks, we can move relay-experimental back into open source. This is a priority for us as we are starting to integrate aspects of the experimental branch into core.
• We published meeting notes from our recent discussion w several contributors, which includes ideas around several major themes that affect OSS users such as customizing object identity, compiler configuration, server rendering , etc.

[sorenhoyer]

@josephsavona so where is the relay-experimental branch and what is the status of hooks? When can we expect them to be released?

[josephsavona]

@sorenhoyer Good timing: with a bit of luck, relay-experimental will land on GH today. @jstejada is resolving the last (hopefully) issues.

[jstejada]

hey @sorenhoyer (and anyone else following this diff), I'm still figuring out some issues that have come up with our internal infra that are blocking me from moving the code to OSS, but hopefully those will be resolved soon, and we'll move it as soon as possible

[maraisr]

Will we need to pull and build the experimental branch ourselves, or will the canary dist release?

[jstejada]

Finally was able to land Relay Hooks in open source: https://github.com/facebook/relay/commit/b83aace7a95f5fd82cbb30d1f6888bcc4767eeb5 Apologies for the delay on that. The code is in open source now, but we won't be releasing Relay Hooks into any existing or new packages yet; that will likely occur over the next month or 2. If you want to consume them, you'd need to build the code directly from this repo.

cc @sorenhoyer @maraisr

[sorenhoyer]

Thanks @jstejada - we're just about to start a new project, so great timing! Very tempted to start that project using Relay hooks. :-)

[jgcmarins]

Incremental data-delivery with @defer and @stream. We're planning to implement them and document the client/server contract for others to implement in open-source.

This is awesome!

Should we report any update here?

[pie6k]

May I ask if is there any particular reason you don't want to publish hooks as experimental feature? I'd love to play with that

[sibelius]

relay-experimental is taken by another user on npm https://www.npmjs.com/package/relay-experimental

[pie6k]

That's actually quite interesting reason :)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.