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:
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:
Yes. And an important part of the conversation. Depending on how you slice it, though, it’s a big project in and of itself.
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 
+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?
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.
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
index.html
show.html.erb
new.html.erb
edit.html.erb
I’m seeing remix and other tools out there trying to restore some of this.
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
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
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 
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:
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
I wonder if we could take advantage of git to do this somehow. Generator triggers a check for any uncommitted code and then tags you at pre-generator so you could at least rollback. I know i do this manually anytime i run a generator i’m not familiar with.
Thank you @zpeters for your response. Your idea will certainly offer a minimalist solution - I did something similar for the same reason as you (we obviously are discussing a transactional application development). Here is the terminal log of the step: yarn redwood g scaffold post
(node:18259) ExperimentalWarning: stream/web is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
✔ Generating scaffold files...
✔ Successfully wrote file `./web/src/components/Post/EditPost
Cell/EditPostCell.js`
✔ Successfully wrote file `./web/src/components/Post/Post/Pos
t.js`
✔ Successfully wrote file `./web/src/components/Post/PostCell
/PostCell.js`
✔ Successfully wrote file `./web/src/components/Post/PostForm
/PostForm.js`
✔ Successfully wrote file `./web/src/components/Post/Posts/Po
sts.js`
✔ Successfully wrote file `./web/src/components/Post/PostsCel
l/PostsCell.js`
✔ Successfully wrote file `./web/src/components/Post/NewPost/
NewPost.js`
✔ Successfully wrote file `./api/src/graphql/posts.sdl.js`
✔ Successfully wrote file `./api/src/services/posts/posts.js`
✔ Successfully wrote file `./api/src/services/posts/posts.sce
narios.js`
✔ Successfully wrote file `./api/src/services/posts/posts.tes
t.js`
✔ Successfully wrote file `./web/src/scaffold.css`
✔ Successfully wrote file `./web/src/layouts/PostsLayout/Post
sLayout.js`
✔ Successfully wrote file `./web/src/pages/Post/EditPostPage/
✔ Generating scaffold files...
✔ Successfully wrote file `./web/src/components/Post/EditPost
Cell/EditPostCell.js`
✔ Successfully wrote file `./web/src/components/Post/Post/Pos
t.js`
✔ Successfully wrote file `./web/src/components/Post/PostCell
/PostCell.js`
✔ Successfully wrote file `./web/src/components/Post/PostForm
/PostForm.js`
✔ Successfully wrote file `./web/src/components/Post/Posts/Po
sts.js`
✔ Successfully wrote file `./web/src/components/Post/PostsCel
l/PostsCell.js`
✔ Successfully wrote file `./web/src/components/Post/NewPost/
NewPost.js`
✔ Successfully wrote file `./api/src/graphql/posts.sdl.js`
✔ Successfully wrote file `./api/src/services/posts/posts.js`
✔ Successfully wrote file `./api/src/services/posts/posts.sce
narios.js`
✔ Successfully wrote file `./api/src/services/posts/posts.tes
t.js`
✔ Successfully wrote file `./web/src/scaffold.css`
✔ Successfully wrote file `./web/src/layouts/PostsLayout/Post
sLayout.js`
✔ Successfully wrote file `./web/src/pages/Post/EditPostPage/
✔ Generating scaffold files...
✔ Successfully wrote file `./web/src/components/Post/EditPost
Cell/EditPostCell.js`
✔ Successfully wrote file `./web/src/components/Post/Post/Pos
t.js`
✔ Successfully wrote file `./web/src/components/Post/PostCell
/PostCell.js`
✔ Successfully wrote file `./web/src/components/Post/PostForm
/PostForm.js`
✔ Successfully wrote file `./web/src/components/Post/Posts/Po
sts.js`
✔ Successfully wrote file `./web/src/components/Post/PostsCel
l/PostsCell.js`
✔ Successfully wrote file `./web/src/components/Post/NewPost/
NewPost.js`
✔ Successfully wrote file `./api/src/graphql/posts.sdl.js`
✔ Successfully wrote file `./api/src/services/posts/posts.js`
✔ Successfully wrote file `./api/src/services/posts/posts.sce
narios.js`
✔ Successfully wrote file `./api/src/services/posts/posts.tes
t.js`
✔ Successfully wrote file `./web/src/scaffold.css`
✔ Successfully wrote file `./web/src/layouts/PostsLayout/Post
sLayout.js`
✔ Successfully wrote file `./web/src/pages/Post/EditPostPage/
EditPostPage.js`
✔ Successfully wrote file `./web/src/pages/Post/PostPage/Post
Page.js`
✔ Successfully wrote file `./web/src/pages/Post/PostsPage/Pos
tsPage.js`
✔ Successfully wrote file `./web/src/pages/Post/NewPostPage/N
ewPostPage.js`
✔ Adding layout import...
✔ Adding set import...
✔ Adding scaffold routes...
✔ Adding scaffold asset imports...
✔ Generating types ...
nik$ yarn rw dev
(node:18427) ExperimentalWarning: stream/web is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
gen | (node:18454) ExperimentalWarning: stream/web is an experimental feature. This feature could change at any time
gen | (Use `node --trace-warnings ...` to show where the warning was created)
gen | Generating TypeScript definitions and GraphQL schemas...
gen | 28 files generated
web | (node:18458) ExperimentalWarning: stream/web is an experimental feature. This feature could change at any time
web | (Use `node --trace-warnings ...` to show where the warning was created)
api | (node:18497) ExperimentalWarning: stream/web is an experimental feature. This feature could change at any time
api | (Use `node --trace-warnings ...` to show where the warning was created)
api | Building... Took 369 ms
api | Debugger listening on ws://127.0.0.1:18911/e2286fbd-9a52-4503-9545-7bd60a5462e6
api | For help, see: https://nodejs.org/en/docs/inspector
web | assets by path static/js/*.js 4.44 MiB
web | asset static/js/app.bundle.js 2.88 MiB [emitted] (name: app) 1 related asset
web | asset static/js/src_pages_Post_PostsPage_PostsPage_js.chunk.js 458 KiB [emitted] 1 related asset
web | asset static/js/src_pages_Post_PostPage_PostPage_js.chunk.js 456 KiB [emitted] 1 related asset
web | asset static/js/src_pages_Post_EditPostPage_EditPostPage_js.chunk.js 319 KiB [emitted] 1 related asset
web | asset static/js/src_pages_Post_NewPostPage_NewPostPage_js.chunk.js 318 KiB [emitted] 1 related asset
web | asset static/js/runtime-app.bundle.js 49.3 KiB [emitted] (name: runtime-app) 1 related asset
web | asset static/js/src_pages_NotFoundPage_NotFoundPage_js.chunk.js 3.37 KiB [emitted] 1 related asset
web | asset README.md 1.9 KiB [emitted] [from: public/README.md] [copied]
web | asset favicon.png 1.7 KiB [emitted] [from: public/favicon.png] [copied]
web | asset index.html 483 bytes [emitted]
web | asset robots.txt 24 bytes [emitted] [from: public/robots.txt] [copied]
web | Entrypoint app 2.93 MiB (2.89 MiB) = static/js/runtime-app.bundle.js 49.3 KiB static/js/app.bundle.js 2.88 MiB 2 auxiliary assets
web | orphan modules 408 KiB [orphan] 116 modules
web | runtime modules 33.1 KiB 17 modules
web | modules by path ../node_modules/ 2.76 MiB 830 modules
web | modules by path ./src/ 72.1 KiB
web | modules by path ./src/components/Post/ 33 KiB 7 modules
web | modules by path ./src/pages/ 10.4 KiB
web | modules by path ./src/pages/Post/ 4.89 KiB 4 modules
web | + 2 modules
web | modules by path ./src/*.css 22.2 KiB
web | ./src/scaffold.css 2.39 KiB [built] [code generated]
web | + 3 modules
web | modules by path ./src/*.js 4.49 KiB
web | ./src/App.js 1.63 KiB [built] [code generated]
web | ./src/Routes.js 2.86 KiB [built] [code generated]
web | ./src/layouts/PostsLayout/PostsLayout.js 1.98 KiB [built] [code generated]
web | webpack 5.71.0 compiled successfully in 4112 ms
web | <e> [webpack-dev-server] [HPM] Error occurred while proxying request localhost:8910/graphql to http://[::1]:8911/ [ECONNREFUSED] (https://nodejs.org/api/errors.html#errors_common_system_errors)
api | Starting API Server...
api | Loading server config from /Users/nik/dev/learning/storybook/my-redwood-project/api/server.config.js
api |
api | Importing Server Functions...
api | /graphql 118 ms
api | (node:18502) ExperimentalWarning: stream/web is an experimental feature. This feature could change at any time
api | (Use `node --trace-warnings ...` to show where the warning was created)
api | ...Done importing in 119 ms
api | Took 161 ms
api | API listening on http://localhost:8911/
api | GraphQL endpoint at /graphql
api | 18:16:04 🌲 Server listening at http://[::]:8911
api | 18:18:39 🌲 incoming request POST xxx /graphql
api | 18:18:39 🐛 Checking if GraphiQL Request
api | 18:18:39 🐛 Extracting GraphQL Parameters
api | 18:18:39 🐛 Processing Request
api | 18:18:39 🐛 execute-start
api | 18:18:39 🐛 mutation CreatePostMutation($input: CreatePostInput!) {
api | createPost(input: $input) {
api | id
api | __typename
api | }
api | }
api | 18:18:39 🐛 CreatePostMutation
api | 18:18:39 🐛 variables
api | 18:18:39 🐛 graphql-server GraphQL execution started: CreatePostMutation
api | (node:18502) ExperimentalWarning: buffer.Blob is an experimental feature. This feature could change at any time
api | 18:18:39 🌲 Starting a sqlite pool with 13 connections.
api | 18:18:39 🐛 execute-end
api | 18:18:39 🐛 -->
api | 📦 Result Data
api | {
api | "createPost": {
api | "id": 1,
api | "__typename": "Post"
api | }
api | }
api | 18:18:39 🐛 graphql-server GraphQL execution completed: CreatePostMutation
api | 18:18:39 🌲 request completed 100ms
api | 18:18:39 🌲 incoming request POST xxx /graphql
api | 18:18:39 🐛 Checking if GraphiQL Request
api | 18:18:39 🐛 Extracting GraphQL Parameters
api | 18:18:39 🐛 Processing Request
api | 18:18:39 🐛 execute-start
api | 18:18:39 🐛 query FindPosts {
api | posts {
api | id
api | title
api | body
api | createdAt
api | __typename
api | }
api | }
api | 18:18:39 🐛 FindPosts
api | 18:18:39 🐛 variables
api | 18:18:39 🐛 graphql-server GraphQL execution started: FindPosts
api | 18:18:39 🐛 execute-end
api | 18:18:39 🐛 -->
api | 📦 Result Data
api | {
api | "posts": [
api | {
api | "id": 1,
api | "title": "shrimps",
api | "body": "I really love them - in any dish",
api | "createdAt": "2022-04-14T22:18:39.898Z",
api | "__typename": "Post"
api | }
api | ]
api | }
api | 18:18:39 🐛 graphql-server GraphQL execution completed: FindPosts
api | 18:18:39 🌲 request completed 7ms
This is the step from the very first introduction to RW - Quick Start | RedwoodJS Docs. If I tell anyone that I would like to undo this step (``yarn redwood g scaffold post`) everyone would tell me to start this app creation from scratch - and they would be right. However RW intent is to be used to create serious applications - and in that case, let me cite one of my friends here:
But at the end of the day, it’s just a bunch of best practices wrapped up in code generators. I don’t know if you see my blog ever, but the opening four paragraphs of this one capture my concerns with “wizards” of this type. The tutorial is impeccable in its explanations, but side effects like this one give me hives:
“In the Success component, where did posts come from?
In the QUERY statement, the query we’re calling is posts. Whatever the name of this query is, that’s the name of the prop that will be available in Success with your data.”
This kind of naming thing (very common these days; RWJS is no worse than any other) is awful. People do not remember where they come from; new people in the codebase have to spend hours debugging to figure out the provenance of the data, what the fields on the magic object are, etc. etc. … there is something to like about “opinionated” frameworks, but I want those opinions wrapped up in documented APIs, not invisible side-effects.
Now, assuming that it is possible and feasible to implement transactional development process it will address all critical comments of my friend (a very well known and respected person in the industry).
I also like your list @dom and I would like to see a number of additional application templates. At the moment, having just one (redwood-app), app created RW apps have the same ancestor, and then many of us look for answers on how to remove parts of it (example: app that uses only API side).
Ideally, it would be great to have template generator with the support for storing the templates created with it, so the command:
yarn create my-rw-template my-redwood-project
Any type of application that has multiple client instances, where any of the clients might mutate the DB and the other clients shall be dynamically updated. Other examples include dynamic data sources such as IoT devices, that mutate the DB with telemetry (i.e. GPS location) and all clients shall dynamically update the location on a map.