Feedback and questions about features and limitations

General Feedback

Redwood seems to be very productive and fun to work with. Outside of some small Firefox bug that is likely easy to fix. I think your project has huge potential and is exciting. If this succeeds then it won’t just improve productivity in isolation of teams and individuals, there is also the gain of building community around social media, blogs, open source, stack overflow and so on. The web development community desperately needs this generally and especially within the JS ecosystem and Redwood seems very promising. This is why I took time to write this hopefully useful feedback.

The structure of a Redwood app seems to be quite well thought out. All the bikeshed color decisions are made for you so you can focus on the right things faster and more often.

Another cool thing is providing code generation over abstraction. This saves time looking up for API docs, because one can look at the generated code and quickly understand how things are wired up. The CRUD scaffolding is a good example of this. When starting the tutorial I quickly checked if I can find the initial ReactDOM.render() call in an index.js and wether it was obvious where to put static assets and was not dissapointed.

Also the development performance is enjoyable. Everything happens quite fast and seemingly with low overhead, especially when comparing partly similar frameworks like Gatsby. I expect that the performance will suffer a bit when the project grows, but I wanted to note that development performance is a primary concern to me.

But typically tutorials show a happy path. I want to address some of the concerns I have and explain some of my experiences and requirements.

A framework needs to reasonably flexible, or else it would be just as or more convenient to just wire things up manually. Please note that I don’t expect Redwood to solve all these issues within, but it shouldn’t get in the way.

I hope this will be somewhat helpful as a feedback and possibly clarify things up for myself.

Basic Expectations

In general I expect things to just work like in any sane Nodejs and React based environment/ecosystem like:

  • npm packages just work w/o the need for weird configuration or plugins

  • transpiling from other languages like Typescript, ClojureScript and so on

  • embedding WASM into modules

  • configuration can be exposed and changed, including webpack

  • I’m not locked into when and where my CSS is compiled and included, free to use node-sass for example

  • I get to decide when and where React renders things (server, client) w/o having to bang my head against a wall

  • integrating with Redux (or similar) is painless, there is no hard lock-in with hooks.

You get the idea. I’m more interested in the flexibility that JS/Nodejs gives. Using the same language for everything is of secondary concern, allthough that has some nice properties like you are showing with your Form integration for example.

But when considering to use and support a framework, then I want to be sure that I will not be constrained regarding implementation details outside of the Big Ideas (integrated SSG, GraphQL, generators, DevOps), but rather enabled in terms of wiring things together nicely and quickly.

Note about Redux: Hooks are nice in isolation but they inherently complect rendering with state management. In my opinion this isn’t a YAGNI issue but about separating concerns and better introspection. And in my case I absolutely need my React components to be functional, not “functional”, because I’m working closely with a designer who can also implement/alter/refine things with SCSS and JSX (the ‘templating’ part) and putting stateful logic into components adds a lot of friction.

The decisions I want to be made for me (outside of the Big Ideas) are things like file structure, formatting, naming conventions and so on, because these things don’t matter in detail, they just have to be consistent and reasonable.

Scaling Complexity

As someone who works partly solo (freelancing and consulting) and partly in small teams I’m rarely concerned with performance scale initially (AKA serving more users more quickly in the future) but rather with changing requirements.

Many of my/our applications and sites start out simple and get incrementally more integrated into some workflow with automation, configuration/abstraction/APIs and so on.

People who come to us want to have a direct channel of communication and figure things out along the way. They trust us to be pragmatic and critical. This is why we can’t sell in packages or pre-configured services, we can’t compete in that area with larger teams and agencies. So our value comes from our knowledge, flexibility and adaptability.

I think/assume Redwood does a very good job so far in this regard. SSG & React enable one to start out as ‘just’ a performant and nicely structured website while the GraphQL integration enables growing with features into an application.

My hope/expectation here is that a Redwood app is agnostic to whether it does dynamic data fetching (yet). So if a project is at a website stage and only needs to fetch data for the SSG aspect, then it can do that from w/e source is available or specified, what ever that might be (a google drive or a bunch of markdown files or a CMS service …).

Data Layer

I know this issue is very much under development, but discussing this might be of value as well.

GraphQL inherently solves an issue on the API layer that has major implications for modelling a data flow, by making it easy to separate mutations and queries and it makes relations explicit in the language.

We just recently had to solve a problem, where we suddenly needed an audit trail for data mutations in a more traditional web application. A client needed to get a better overview of: ‘who changes what’, ‘where does this data come from’ and so on. Implementing logging that is both useful and consistent with multiple moving parts in an application after the fact turned out to be challenging.

I’m not worried at all about SQL here and especially not about PostgreSQL, but I have little experience with Prisma. In short I need it to not get in the way, when I for example have to model mutation and persistence as an event stream and reads as a property graph with user defined schemas. How well would that work with Prisma? And with Cells and Forms?

As a sidenote: SQLite is a robust and very ergonomic alternative. In my opinion it is generally underappreciated. I’m referring to a comment in the blog tutorial.

Deployment Concerns

I can appreciate that Netlify gets to have first class support from Redwood, I started to use their service as well for small projects and prototypes very recently and I’m thinking about using it more. But it is absolutely critical that I don’t need to worry about lock-in here at all.

Just this week we are integrating a site with an cloud infrastructure of an important, big client. This was a fixed requirement from the start of the project. Due to the nature of my/our work we cannot always decide where our code lives.

The biggest concern here is FaaS, which is a new paradigm and not yet well adopted around the world. The minimum requirement here is that it would at least be compatible with all big providers like AWS, Google, Azure. But how reasonable is it to implement the infrastructure around ‘functions’ with on prem or the data center around the corner? This is not a hypothetical question we literally have a data center around the corner.


When discussing FaaS some time ago I jokingly said that they are reinventing PHP for other languages. There are benefits to this but also downsides. Stateless functions are easy to reason about and easy to scale both in complexity and performance. But the downside is well, that they are stateless.

For example one of the big value propositions of a Nodejs backend is how ergonomic websockets are. But your architecture seems to be completely stateless if I understand correctly (SSG & FaaS). So when a stateful server is needed for some reason, then it would live completely outside of Redwood I assume.

I know I dumped a bunch of unrelated things into this feedback, but again I’m kind of excited about your poject and at this point I also want to figure out where Redwood fits in and where it doesn’t.


This is so helpful, @dgb23 Can’t thank you enough both giving your time to the tutorial as well as this write-up. Very valid and most of all gives us perspective of your in-the-trenches needs. Your core assumption is correct — we want Redwood to be a huge asset for people+teams like you, but we won’t know if we are getting there unless you say it’s the case!

This deserves more than a quick reply so I’ve put it in front of our (small) team to get some collaborative thinking and response. You’ll be hearing from us.