August 5th, 2016This month marks a year since we released Relay and we'd like to share an update on the project and what's next.
A Year In Review #A year after launch, we're incredibly excited to see an active community forming around Relay and that companies such as Twitter are using Relay in production:
For a project like mission control, GraphQL and Relay were a near-perfect solution, and the cost of building it any other way justified the investment. -- Fin HopkinsThis kind of positive feedback is really encouraging (I'll admit to re-reading that post far too many times), and great motivation for us to keep going and make Relay even better. With the community's help we've already come a long way since the technical preview. Here are some highlights:
- In March we added support for server-side rendering and for creating multiple instances of Relay on a single page. This was a coordinated effort over the course of several months by community members Denis Nedelyaev and Gerald Monaco (now at Facebook).
- Also in March we added support for React Native. While we use Relay and React Native together internally, they didn't quite work together in open-source out of the box. We owe a big thanks to Adam Miskiewicz, Tom Burns, Gaëtan Renaudeau, David Aurelio, Martín Bigio, Paul O’Shannessy, Ben Alpert, and many others who helped track down and resolve issues. Finally, thanks to Steven Luscher for coordinating this effort and building the first Relay/ReactNative example app.
- Denis Nedelyaev created isomorphic-relay, a package that helps developers build server-rendered Relay apps where data is prepared on the server and then used to bootstrap the app on the client.
- Jimmy Jia created react-router-relay to integrate Relay data-fetching into React Router.
- Pavel Chertorogov released relay-network-layer, which adds features such as batching query requests, middleware, authentication, logging, and more.
Retrospective & Roadmap #Earlier this year we paused to reflect on the state of the project. What was working well? What could be improved? What features should we add, and what could we remove? A few themes emerged: performance on mobile, developer experience, and empowering the community.
Developer Experience #Next, we've paid attention to the community's feedback and know that, to put it simply, Relay could be "easier" to use (and "simpler" too). This isn't entirely surprising to us - Relay was originally designed as a routing library and gradually morphed into a data-fetching library. Concepts like Relay "routes", for example, no longer serve as critical a role and are just one more concept that developers have to learn about. Another example is mutations: while writes are inherently more complex than reads, our API doesn't make the simple things simple enough. Alongside our focus on mobile performance, we've also kept the developer experience in mind as we evolve Relay core.
Empowering the Community #Finally, we want to make it easier for people in the community to develop useful libraries that work with Relay. By comparison, React's small surface area - components - allows developers to build cool things like routing, higher-order components, or reusable text editors. For Relay, this would mean having the framework provide core primitives that users can build upon. We want it to be possible for the community to integrate Relay with view libraries other than React, or to build real-time subscriptions as a complementary library.
What's Next #These were big goals, and also a bit scary; we knew that incremental improvements would only allow us to move so fast. So in April we started a project to build a new implementation of Relay core targeting low-end mobile devices from the start. As you can guess since we're writing this, the experiment was a success. The result is a new core that retains the best parts of Relay today - colocated components & data-dependencies, automatic data/view consistency, declarative data-fetching - while improving performance on mobile devices and addressing several common areas of confusion. We're currently focused on shipping the first applications using the new core: ironing out bugs, refining the API changes and developer experience, and adding any missing features. We're excited to bring these changes to open source, and will do so once we've proven them in production. We'll go into more detail in some upcoming talks - links below - but for now here's an overview:
- Expressive Mutations: We'll continue to support a higher-level mutation API for common cases, but will also provide a lower-level API that allows "raw" data access where necessary. If you need to order a list of cached elements, for example, there will be a way to
- Route-less Relay: Routes will be gone in open source. Instead of a route with multiple query definitions, you'll just provide a single query with as many root fields as you want.
- Cache Eviction/Garbage Collection: The API and architecture is designed from the start to allow removing cached data that is no longer referenced by a mounted view.
Conclusion #If you made it this far, congrats and thanks for reading! We'll be sharing more information about these changes in some upcoming talks:
- Greg Hurrell will presenting a Relay "Deep Dive" at the Silicon Valley ReactJS Meetup on August 17th.
- I (@josephsavona) will be speaking about Relay at React Rally on August 25th.