Post-v1 Roadmap: feedback wanted

We just released v1! That means we can do what we’ve been eagerly awaiting: work on and ship new features!

We don’t have an official roadmap yet, and while I can’t speak for the core team as a whole, here’s a list of some of the things that I think will probably be on our post-v1 roadmap (in no particular order):

  • React 18
  • SSR/Edge rendering
  • Live queries (or something akin to GraphQL subscriptions, if not GraphQL subscriptions)
  • ESM compatibility
  • Distributing the CLI as it’s own binary
  • React state-management libraries
  • Adding a new “side” (CLI, Svelte, React Native, etc.)
  • Adding tRPC as an option
  • Better generators, component organization
  • Sharing code between sides
  • Focus more on performance
  • Continue investigating other GraphQL Clients (e.g. Relay)
  • Better debugging story
  • Ensuring the api and the web sides are decoupled
  • Making the framework more pluggable (e.g. hooking into the CLI)
  • Exploring Yarn 3 features (namely, pnp)
  • Revive the RedwoodJS VSCode extension
  • Improving the contributing workflow
  • Better yarn create-redwood app experience
  • Investigate compatibility with something like Nx, turborepo
  • Better yarn redwood console

Note that not all of these features would require a major release. It’s very likely that most of them could be shipped in a minor release.

But we want the community to drive priorities too. What would you all like to see?


Great list @dom! Plenty of things there I’d love to work on, and that would help in my own RW apps.

Couple of things I’m excited about that are not on that list:

  • Better i18n story
  • Prerendering for cells (aka fuller SSG support)

Thanks @dom! I already started looking into a couple of list items here. Added links to the respective PRs below:

React 18 PoC PR: Explore upgrade to react 18 by virtuoushub · Pull Request #4992 · redwoodjs/redwood · GitHub

turborepo PoC PR: Add turborepo by virtuoushub · Pull Request #5100 · redwoodjs/redwood · GitHub


I think a way to share the code between api and web would be very helpful


I’d love to see a built-in solution for e2e testing, something like:

yarn rw setup e2e cypress
and / or
yarn rw setup e2e playwright

yarn rw e2e to open test runner, some flag to run in CI mode

Automatically configured to use the test db like the unit tests do

  • A command to make a schema translation ready.

  • Recommendations on scenarios that scale.

  • Addition of a generator that matches your schema to use in your scenarios, so you don’t have to manually add all modifications to all scenarios each time.

Those would be 3 topics I’ve actually wanted to work on, the first one being maybe the most obvious to other users.

Also: Graphql Yoga enables file transfer, but our client doesn’t.
Any progress/discussion/plan over this feels important.

Great list though, I’d also be interested in schema stitching, have tried a couple of things and I think the graphql handler might require some serious tweaking for this.

Already mentioned and of importance to me:

  • moaar sides!!!
  • shared code
  • SSR

Hey! My insignificant 2 cents: I would love to see Redwood support Electron.

As a solo developer, I want to focus on the task at hand, not juggling a million code bases. Redwood is a superb step towards my dreams. However, if it supported something like Electron, Redwood now goes from supporting web-apps to all-apps. This means that I can focus on creating the product without worrying about if I’ll need to recreate if for each platform as an app later down the road.


Two questions:

  • Are RedwoodJS Plugins still in the conversation?
  • Are RedwoodRecords going to stay? They are experimental, I’m reluctant to further implement them if they don’t pass the “experimental stage” in v1, it would imply lack of support and possible drop.

Yes. And an important part of the conversation. Depending on how you slice it, though, it’s a big project in and of itself.

1 Like

Something really ambitious, but I would like to share it to find whether it is too ambitious: reversible generators. The tutorial is a good example for such tool as it presents many if not all rw generators.

I would really like to be able to step forwards and backwards through the process started by yarn create redwood-app. This ought to work even for apps that went beyond the point where tutorial app ends - as long as my app was strictly following the are prescribed by RW.

Ideally, a redwood app should maintain a special log that records all actions - and offer a step back it this step is reversible. I am not sufficiently experienced with databases, but I there some of them that can be reversed. Rather than limiting the app generation to CLI local app, this process generation should be similar to puppeteer.

If this messages make me remind you of Jules Verne, think how many of his visions materialized.


SSR :slight_smile:


+1 for ESM compatibility.

Also, improving CLI performance would be a major win in terms of DX.

Right now all commands seem to hang for a few seconds before spitting out the output. It feels unresponsive. A rewrite to a low level language like Rust would likely solve this issue, but maybe there’s a simpler solution?

  • SSR/Edge rendering
  • Focus more on performance
  • Live queries (or something akin to GraphQL subscriptions, if not GraphQL subscriptions)
  • Better generators, component organization
  • React state-management libraries
  • Ensuring the api and the web sides are decoupled

State management is an interesting one and I have yet to found something that is easy and well organized as vuex in the react landscape. I found redux to be extremely complicated and react context is build on top of those design flaws I would say so no bueno!

Recoil I liked but I had little bit problem with setting it up correctly in redwood.js project all of my tests were failing because of some provider thing but apart from that it did work. It play really well with react particularly the “hooks concept”. However I didn’t really like the code organization it reminds of the Redwood Services. I’m the type of person that would most likely reach for RedwoodRecord instead.

Mobx is another on that I have played with it in the past in my previous job we used that. The problem is the different mental model that it comes with. It’s very class based like very much OOP style it might throw some developers off that are used to more function or hooks style of development.

Apollo client I have not tried but I don’t think redwood should use that either, in my opinion. I would not mind if the created their own state management solution. The did that with redwood router

Ensuring the api and the web sides are decoupled

For example if I have the django & graphql or rails & graphql can I still get the same integration and benefits on the client like code sharing and so forth? Maybe more guidance here I’m not sure.

  • Better generators, component organization

Component organization here is a bit messy I always remember rails generator having the easiest structure to follow when it came to CRUD

posts/ directory


I’m seeing remix and other tools out there trying to restore some of this.

1 Like

Sounds like you have something more to say about Redwood services? At scale I had to rethink about them, maybe there’s something here.

Great to know, it’s a way of contributing I’m looking forward to. Some cookbooks could be pretty good first examples of plugins actually - I’m eyeing at the File Upload, currently implementing it.

Most of the things I would like to see

  • React 18
  • SSR/Edge rendering
  • Live queries

I think the those are the top things

Additionally would like to see better error messages. A lot of times there are issues that pop up with really vague errors. Maybe that falls under * Better debugging story

I really like the idea of more sides. I think that it can really make redwood stand out against other frameworks in the space. I think that we should probably nail down patterns on things that are missing from the API side first like live queries and SSR before we expand though.

If we focus on some more server-related things it would be nice to figure out emails and async jobs things that all apps need at some point.

I would add Zustand, which is an excellent state manager, too much underestimate in my opinion

1 Like

Last time I looked at state management libraries I really liked the look of Hookstate. But then I just did what I needed with React Context instead, and have been happy with that choice in multiple projects over the last few years.

For anyone interested in Recoil I’d suggest you also take a look at Jotai

GraphQL Subscriptions please :pray::pray::pray:


Definitely on the list. We’re curious however how you’d use subscriptions (carts, etc)?

We’ve been making a list of examples. Thanks!

I’d like to throw into the mix improving docker image DevEx. Size and time reduction being the primary goal.

Docker is important because:

  • Its a very common deploy platform.
  • Without it, we are excluding the demographic of developers who build apps for external clients.
  • Its necessary for dynamic tags to appear to bots and link scrapers. Those little messaging/twitter images are :fire:

I’ve documented my latest journey here Docker size reduction by pi0neerpat · Pull Request #2 · pi0neerpat/redwood-release-devops-example · GitHub and there is more discussion in Containerize Redwood Sides with Docker Compose - #5 by pi0neerpat