My experience with many other frameworks is that they really help you get started quickly, and some of them truly cover a vast majority of common use cases. But when you reach a point of need or situation where they don't work the way you want, you must then learn how to work around them or enhance them.
That usually means doing a lot of digging and learning, essentially repaying that early time gift you received from all the nice built-ins.
This should be a pretty familiar scenario for many of us here, and perhaps some have experienced this with RedwoodJS. If so, how do you feel about the framework now? How was the workaround/change-behavior experience?
My experience is that full-stack frameworks like rails (and hopefully redwood) free you from a ton of bike-shedding and customization up front and help you get to a point where you outgrow parts of the framework. An advantage of using something like rails today (or over the past 5 years) is that there was a huge crop of unicorn rails startups that all hit those challenges before and a lot of their solutions are codified in open source tools that can be plugged into the framework. In some cases those startups (like shopify, github) have made huge investments in ruby and rails themselves. I hope in a few years that will be the case for redwood.
I like the concept of innovation budgets for startups. You can only innovate on so many vectors because time is typically your most limited resource. Very few startups have a good reason to spend any of that budget on innovations that are not core to their product differentiation. These things include web frameworks, corporate structure, credit card processing, low-level hosting. Just pick a pretty standard solution that fits your use-case and move on. I don't think it's a coincidence that so many of the big startups over that past 10 years were built with big batteries-included frameworks (would be so curious about a larger study of this, I just have cloudy anecdotes).
Don't get me wrong, I love bleeding edge web stuff and playing with new frameworks. But if my priority is making a new company succeed I'm going to look for a framework that minimizes time spent picking libraries and gluing them together nicely and maximizes time I have to iterate on the product and tweak user-facing business logic.
While this thinking isn't wrong, it is optimizing for the wrong thing. By focusing on future development velocity you are trading off current velocity, which is extremely important to build an MVP, test (and eliminate) potential product paths and generally get from 0 to 1 as fast as possible.
There will be a point in the product lifetime when you will outgrow the framework and you will need to rewrite large portions of it and pay off the tech debt. Most projects don't get to that point. Once there, it is also the right time to make those decisions that were classified as premature optimization. Now they are merely tech decisions with one crucial difference: at this point you have much more information about the product, the market, the customers, and your team than you had initially, so now you can take the best decisions about what will really increase your velocity.
If speed to market is not essential (such as a side project for fun) then by all means, it's you now, and it's you later, so take the time to enjoy your craft and become proficient at combining the best tools to make your project shine, instead of opting for the cookie cutter frameworks.
I think you have to strike a balance sometimes, maybe bank on your eventual success and put a few % more in upfront to ease the path later. Using something you already know well is good, given you'll be more productive in it to start with and better understand how it's going to impact you in the future.
I think that's taking the extreme end. Couldn't someone use a larger framework, for example Spring? It's pretty productive with Spring boot, but also large enough that you can expand for your use case. I'm not advocating for Spring per se, as I think .Net core is equivalent.
Yes, and it's difficult to understand the tradeoffs without investing time in a framework. There are a lot of unknown unknowns, both in terms of the market fit and the framework. It's hard to know starting off what "situations" would be difficult for a framework like RedwoodJS.
I'm a nobody but I'll tell you a small experience I had with Pyramid (/ Pylons) - it didn't do too much for you in terms of admin UIs and things like Django etc but one thing it did really well is make a lot of its decisions easy to override. It uses the much-maligned Zope Component Architecture, but in practice it meant most parts of it could be switched out when you needed different functionality.
(random mixing of past and present tense because it's still around and presumably still good but I don't use it)
Co-founder of RedwoodJS here. We are so excited and proud of what Redwood has become, both as a project and as a community! Whether you are setting off to start your side project or looking to become an open-source contributor, I'd like to personally invite you to join us.
With Redwood, no one has to go it alone.
If you have any questions along the way, don't hesitate to reach out to me. I'll be watching comments here. And my DMs are open everywhere.
I have a simple question -- I've looked at GraphQL in the past and it seems extremely limited when you start wanting to do more complicated types of joins for performance, etc. This is such a fundamental thing to any webapp in my mind, and yet when I ask this previously people are often like "uhhh yeah...... use joinMonster I GUESS?"
Has GraphQL improved? I literally can't fathom using some kind of external plugin just to load data using more complex queries for performance reasons.
It really depends on how the resolvers are written, GraqhQL is just a interchange mechanism like RESTful APIs . You can do same things good or bad on both.
Depending on the framework that use for your DB-to-GraphQL layer (like Hasura / join monster/ PostGraphile / subZero etc) there can be some there can be some limitations on what it can and cannot do, but that is not really a GraphQL problem.
The GraphQL specific gotchas for me where
- For most part component level queries works well, occasionally batching in higher component is important for performance, for example instead of executing a secondary query on each row of the table ( say fetching photos of user profiles from a different store) doing it one level up can speed things up.
- Caching has to be solved very differently than RESTful APIs, GraphQL has everything in one endpoint as POST and you cannot leverage CDN's to cache the canonical resource URLs
- Less verbosity or nested request-responses could be important for UX performance, using HATEOS style discoverability usually results in many APIs calls 2-3 levels or more deep, in RESTful systems that is not a major problem as you are caching API responses in nodes in dozen locations/CDN PoPs near the user but that is not possible in GraphQL, so you have to keep mind of verbosity, that can also impact how you store and index your database and how you configure and run replicas etc at scale.
---
Anecdotally I have used Hasura as GraphQL frontend for an existing mature PostgreSQL db and APIs, (1 tb+, 1000's of concurrent users), and it scales fairly well even with 4-5 level nested joins or fetch ten of thousands of nested records. Hasura also does subscriptions reasonably well and they don't use triggers for implementing it.
Some areas that needed a bit work around for me - recursive CTEs, cross-db joins, performance of very large counts ( postgres problem - using HLL or tuples from the planner if approximate values are fine.
GraphQL is designed around CRUD fetching patterns - so typically you would have a query per data type slice, and that query can be as complex as you like. In order to avoid N+1 queries, you should use dataloader: https://github.com/graphql/dataloader.
You can also join additional data to reference in deeper resolvers, but that's an antipattern AFAIK.
FWIW, the Guild (the group behind a lot of the more popular GraphQL libraries) has recently take stewardship of this package, and it looks like there are already a few recent PRs merged into the repo.
Lack of updates also isn't necessarily an indicator of disuse. It currently has close to 5 million weekly downlaods, roughly 1/5th of express which is probably the most popular library for building APIs in node.
Well if that is possible, that's great, but when I've asked similar questions before the answer is always to use some external library like joinmonster or whatever.
This is easily possible with the low-level graphql NPM package which is the base of many frameworks. Most give you an option to get through the abstraction and do it.
Nothing about GraphQL causes a join monster.. that's just unbounded limits on the front end queries.
You could validate against having too many layers of nesting in one query, validate pagination, provide abstract relationships for the many nesting and special case those joins, etc.
It's basically a question of how to efficiently query data. There's always ways, but it might require some trimming of allowed graphql queries.
> You could validate against having too many layers of nesting in one query
The GraphQL Server in RedwoodJS does query depth limiting out-of-the-box. You can configure it, but by default the depth is 11 -- because all the best things go to 11.
My utmost gratitude to you David, Tom, Peter & Rob, getting on the RedwoodJS train early on has been a great choice of life changing vehicle.
Also, very excited about that launch week! Can't wait to see the community grow.
So, going through your tutorial and coming up on an issue/error... when I scaffold the 'posts' I keep getting an error:
API listening on http://localhost:8911/
api | GraphQL endpoint at /graphql
api | 15:23:32 Server listening at http://[::]:8911
web | <e> [webpack-dev-server] [HPM] Error occurred while proxying request
localhost:8910/graphql to http://[::1]:8911/ [EADDRNOTAVAIL]
(https://nodejs.org/api/errors.html#errors_common_system_errors)
web | <e> [webpack-dev-server] [HPM] Error occurred while proxying request
localhost:8910/graphql to http://[::1]:8911/ [EADDRNOTAVAIL]
(https://nodejs.org/api/errors.html#errors_common_system_errors)
RedwoodJS is an open-source project. We are in a unique position to receive funding from Preston-Werner Ventures, which allows us to develop the codebase as well as cultivate an amazing community.
Although it's not a typical for-profit business model, we are sustainable and will enthusiastically continue building Redwood to v2 and well beyond.
Instead of giving an edgy reddit-like repeated response in clear pursuit of karma, perhaps you could read the link the GP comment just gave you.
> So my million dollar spend on Redwood development comes with no strings attached, except that we continue to focus on building the best app framework for startups.
It's a personal investment and a passion project. Unless they're lying, there is no business model.
Preston-Werner is an investor in Netlify, RedwoodJS was built with Netlify in mind (though it supports others hosting companies but not to the same extend).
Netlify is competing with Vercel that has Next.js. So basically RedwoodJS was built to sell more Netlify hosting plans the same way Next.js was for Vercel. It is therefore safe to say that RedwoodJS will continue to exist as long as Netlify is a thing... unless Next.js completely owns the market and RedwoodJS's reason to exist makes no sense because of too few users.
Right now there is no business model, on purpose. This is why I'm personally supporting it. I think what David meant is that we are sustainable because I am committed to sustaining the project. Our goal is to find a properly sustainable model in the future that meshes well with our mission and ambition. It will be exciting to figure that out!
Good on you, one could've said the same about Next.js. Technically there is no business model, but one has been built providing additional services around it.
Next.js was an OSS project before ZEIT (now Vercel) hired on the developers, if memory serves. Next.js was certainly not the main vision for Guillermo as far as I know, but it ended up becoming a very large focal point due to its widespread success. Now, Vercel has an entire ecosystem - Next.js is certainly a 'product' in that regard.
Sure – so when somebody asks what your business model is, do like mojombo did and say there’s no model and there’s a patron instead of doing what thedavidprice did and say that it’s not a typical for-profit model but they are sustainable. One is a clear and simple answer, one is a weird dodge.
Any details you can share about why the project is using rather obsolete tools (yarn, webpack)? I understand they're old and stable, but I took the project for trying to be on the leading edge.
These were state of the art tools when we started work on Redwood more than two years ago. We're investigating other more modern alternatives, but swapping them out is a finicky and time consuming project and we've been focused on primary features. We will keep evaluating our dependencies and you may see some changes in v2!
Ha! My thoughts exactly. If I had more time it would make for an interesting post about all the lessons learned as we navigated the pains of Node.js in all its forms.
Lesson One — Building and Bundling are hard but don't make it harder.
We (by that I mean Peter and Danny) took a hard look at new tools, and, well, they let us down. We reverted a few steps that took us months to figure out. But we learned. And someday we'll make a move to different tooling. But in our opinion, those tools are not ready yet. (Side note: I read a tweet about how buggy SWC is with Next. Anecdotally, although we're stoked for the future of SWC, it remains as a draft PR yet to be merged in the Redwood Repo. We also reverted the primary part of our ESbuild implementation. So the tweet jived for me with our experience.)
The hype is all about speed and performance. But I think the reality is fairly simple:
- implementations become unintelligible spaghetti over time
- everyone has been burnt by having to manage this themselves
- poor implementations lead to diminishing performance
Turns out the existing tools are fairly robust. But to use them we spent an epic amount of time tuning and refactoring. It's complex. But it isn't broken. If you're willing to let good enough be good enough, set a benchmark, hit it, etch it in CI, and call it good.
Lesson Two — Let go but pin the packages
Note: We chose to have @redwood packages include all the dependencies and config and integration under the hood. Redwood apps have very little package overhead out of the box. This means we have to tame the dragon behind the scenes.
The "cool kids" seem to be moving to pnpm (and/or Yarn pnp). I've been burned many times by the monstrosity that is node_modules, but, to be fair, it's also fairly incredible what we're able to achieve. I don't think any one package manager is going to be the cure for what ails us. But I do think it's possible to MakeItWork regardless of what you choose:
- pin your packages because the dependency of your dependency is your enemy
- lean hard into CI; then lean harder
- stay current; give in and let Renovate update
Yarn 3 is a phenomenal tool. (Plus the core team is top-notch.) And we're not even using pnp yet. We do have a long way to go and yes, a faster install would be great and a smaller size on disk and etc. and etc. But, again, I think people have been burned by having to figure it out themselves and finding things unmaintainable in the long run.
---
I'm tired and likely not making much sense anymore. I might have lost the thread, but I think the overall point I was trying to get to is this --> zOMG I'm so tired of talking about build tools and package managers and chasing incremental performance gains and can't we just focus on features that move the needle and have fun again? Oh, and PIN your damn packages 'cause that "^" is nothing but trouble!
webpack was older when rollup came out than gulp was when webpack came out. if not for create-react-app's impact, we'd probably all have moved on 2-3 years ago
I don’t know much about rollup, it doesn’t seem to be that different, but some of the newer tools are rust and go based and better tuned for performance during development. JS tooling is generally slow and weirdly complex, and people seem to acknowledge these issues and improve on them.
that's just how our industry behaves. we like shiny new conveniences and tend to want to adopt them as soon as they're viable.
this moment with postgres, node, webpack, babel, scss, and react feels off in a way. there are genuinely more capable alternatives to all of those that take less time to learn and work effectively with, perform better, cost less, and are trusted by big institutions. rails never felt this entrenched when it was the leading default, for example.
there are a lot of positives to this that non-web engineers have seen for a long time--education becomes better and more accessible, people can have more stable and successful careers, and groups can take on more ambitious missions--it's just surprising from how i've seen web engineers approach their trade over the past 15 years
Older versions of npm (6 and below?) had many issues. Recent versions are more predictable. npm is fine. yarn 1 has always been a solid choice.
There's nothing wrong with webpack except its lengthy build times. It's not a knock on webpack, it's more a knock on using JavaScript (node) for everything. Vite uses esbuild which is coded in Go. Next.js adopted swc (Rust) and hired the lead.
I recommend Next for large react apps and vite for apps that would otherwise use create-react-app. Obviously if you're doing Vue, use vite.
I am in the unique position of having built a large part of the RedwoodJS framework (up until about a year ago), and then building Snaplet[1] in RedwoodJS.
So I have the perspective as a creator and a user!
Of course, as an author, there may be some bias, but I've found RedwoodJS to be malleable to all my, and my teams, needs: It's prescriptive all the way down to the architecture, with the intention that you have an "escape hatch" when you want or need something customized.
They did a really nice job creating an awesome experience by having picked up a nice set of tools and bundling them together. IMHO It is the first true full stack Javascript/Typescript framework that thought on all the important details: logging, great tutorial, community that helps, etc.
Thanks! Our mission is to help more startups explore more territory, more quickly. We're hoping to achieve this by integrating all the bits you need up front so you have less work to do on your framework, and can spend your precious time building and scaling your app or startup!
Ah, that is exactly what's going on. Definitely deserving of a :facepalm: from myself and those of us on the Core Team who missed that. Tom is adding a link back to www.
Congrats! I've been keeping up with Redwood since the original announcement, and the progress they've made has been incredible. The generators and command line utilities are top notch (compared to Rails, thats a high bar to clear) and the general structure of everything seems very well thought out. Still missing a good official solution for background jobs, but I see there is a workaround in the 'How To' section on the documentation. The core team members are super nice and the community is very welcoming.
I'm not convinced the "client side app + Graphql server" is the best model for most startups, however. I tend to lean more on server rendered pages with a little bit of progressive enhancement. But I assume the people who made Redwood are more knowledgeable than me :)
> I'm not convinced the "client side app + Graphql server" is the best model for most startups
Startups don't know what they need when just getting started. When you have a Graphql api you can spin up any number of other tools not just "client side apps", it can connect to a mobile app, cli, any number of other tools and you don't need to go back to the drawing board to make it happen. I've been using Redwood for quite a while and on my app I just spun up a public api with api keys and still maintain my private api specifically for internal app use in less than a day. When I started my project I didn't know I would need that.
Alright, that is a very good point. If the possibility of other nodes interacting with your service is high (ie “you’re gonna need an API eventually”), this might well be the best option.
I'm a Redwood user for my side project that I hope to launch in the next few days. For me Redwood has been great. I know React but was always frustrated with expanding past the UI layer e.g. data fetching, storing. I had tried NextJS in the past (didn't love the filename routing approach) but never actually got anything to production.
I'm in an architect role for work now and I get to code less and less during the day. RedwoodJS has enabled me to actually build something in my own time and (hopefully) launch it.
I didn't know GraphQL or Prisma before starting to use it but between the Redwood docs, Prisma docs and with some RW community help I've made good progress.
I followed the tutorial and made a toy app with it. I thought the tutorial was well written, easy to follow, and touched on topics of importance for developers.
In regard to the framework, it is appereant they have thought about the developer workflow and designed a process that would lead to greater productivity.Two aspects I really enjoyed were cells (UI mixed with API calls) and integration with Storybook. I would say that its combination of scaffolding, easy authentication with dbAuth, and Storybook integration provides a lot of productivity benefits.
This is of course if you're interested in basic CRUD. I don't know how it would be for non-CRUD apps.
Co-creator of RedwoodJS here. Hard to imagine that this was just 2 years ago. 2 years in pandemic times is like 5 years in normal life! We put so much of our lock-down time into this framework. I can't actually think of a better way to have spent the time building something awesome with awesome people.
In my experience, the best way to avoid fighting frameworks, is to keep framework use minimal, and just write the 30 lines of UI code yourself for your custom form.
Why does the JavaScript rendering require so many abstractions layers ?.
I understand the promise that frameworks sort of do the heavy lifting for you, but after 2 years into the app, you are stuck with the framework, and the work hours to fix problems are going up, cause most of your code is hidden inside the framework.
I use Web Components and some minor libraries, having so much easier time going this way.
Not to kick down the hard work on developing of Redwood, but I'm just tired of being forced to use these frameworks on jobs.
At startup stage the team picks a monolithic framework, after 2 years the developers are depressed building with it and leave, then new developers that come are met with a mess and fixing even easy bugs, is practically rewriting 5000 lines of code of the app, because everything is so entangled.
> I understand the promise that frameworks sort of do the heavy lifting for you, but after 2 years into the app, you are stuck with the framework, and the work hours to fix problems are going up, cause most of your code is hidden inside the framework.
For the most part, i'd say that frameworks being largely standardized and having ecosystems around them is a really good thing: people who are familiar with Vue/Angular/React (front end) and with Spring Boot/Express.js/Django/Rails (back end) can start working with your application more quickly than if it uses your custom "sort-of-like-jQuery-but-not-really" set of libraries/framework for the front end or your own thing for back end, which obviously will fall short in regards to documentation, consistency or ready made components.
You can hire for Vue/Angular/React and Spring Boot/Express.js/Django/Rails, you cannot hire for your bespoke in-house solution.
Also, the devs behind those solutions can spend more time and resources on making them better than your entire app will have put into it.
That's why i largely avoid projects which have bespoke solutions like that, especially for back end frameworks, which typically are a minefield of badly written and badly tested code, as well as present numerous security related challenges. That stance was truly cemented when in one project i was stuck with an untested framework that stored half of the functionality in the DB, used JDBC directly through numerous abstractions, had commented out sections of code strewn about the codebase and had comments in Lithuanian, a language that i don't speak and had no documentation whatsoever.
Of course, i've also seen things go into the opposite direction too far: instead of something like Bootstrap or its integration with any of the aforementioned popular frameworks/libraries being used, picking Tailwind CSS and spending weeks if not months mucking about with custom components without actually shipping features and solutions to business problems.
If you are lucky enough to have front ends simple enough to be adequately handled by a few hundred/thousand lines of JS then by all means go ahead (right tool for the problem and all that), but that has never been my experience in any of the enterprise projects that i've worked on.
Admittedly, however, i do feel these standard frameworks/libraries also getting more and more complicated as time goes on, because their eventual transformation into something that tries to do "everything" (and thus downfall) feels almost inevitable.
I don't have anything against Redwood per se but I find the collage of those technologies (personally) unappealing.
Looks to me what it is: a "safe", as in common, meshed stack for new teams to develop mvps.
But nothing of Redwood makes me think, "this is the missing piece I was waiting for" as I've worked with most of this stack in various combinations and I think it's a stack that's getting old and is not scaling or getting much better with time.
> Looks to me what it is: a "safe", as in common, meshed stack for new teams to develop mvps.
If you can get this out of the box, this seems like a very good value prop. 'Boring and not innovative' isn't a flaw unless you're looking for something exciting and innovative, and most applications don't need this.
My two cents testimonial: we've been building our startup's core app with RedwoodJS and launched live in October 2021. It's been working great, the DX really lets you focus on your business and a lot - a lot - of the usual things that make a project require a bigger team are solved out of the box.
I very reluctantly see myself starting any new project on anything different than RedwoodJS. I wouldn't, unless there really wasn't any other choice. You just get to the core of your project really fast, and don't lose touch of it, ever. RW is v1 so it's young but very satisfying, and having witnessed first hand how it's being built, I have faith and trust in its future releases. Looking forward to them actually.
I've used both and I can say some key differentiators are:
- The routing is quite different. RedwoodJS handles routing in a single file rather than doing file-based routing.
- Next.js is full-stack available while RedwoodJS is full-stack by design. A Next.js developer needs to make many decisions about how they will design their API (the DB, GraphQL vs REST, choosing an ORM, etc). RedwoodJS is more opinionated and provides Prisma, *SQL, and GraphQL out-of-the-box.
- RedwoodJS has code scaffolding out-of-the-box. You can easily scaffold out models across frontend and backend based on your Prisma/DB schema.
- Next.js is intentionally designed to have first-class support on Vercel whereas RedwoodJS is by design, more agnostic toward to the deploy target.
Would you recommend RedwoodJS for green field projects? How would you say an opinionated framework like this works in the medium to late maturity? Is it easy or even possible to switch out components with more "enterprisy" solutions?
> Would you recommend RedwoodJS for green field projects?
IMO if you want to run PostgreSQL, React and GraphQL with the least amount of friction and decision making, RedwoodJS is great choice.
> How would you say an opinionated framework like this works in the medium to late maturity?
If you run a frontend-heavy and/or TS/JS shop and don't mind the tradeoffs of something like Ruby on Rails, then I see no limitations to building whatever you want with it.
> Is it easy or even possible to switch out components with more "enterprisy" solutions?
Not sure what that would look like, so I can't comment.
Being able to more quickly bootstrap a project is about 0.01% of the value of a platform. If that's the pitch then I'm not buying. I'll choose the platform that's easiest to debug, maintain and expand.
RedwoodJS has been about long term maintainability from the very beginning. This is part of why we chose GraphQL as a core component. It's more complex at first, but in the long run it gives you multi-client capabilities without rewriting your backend, and provides excellent separation of concerns. We still try to make Redwood as easy to get started with as possible, but in the tradeoff between "quick bootstrapping" and "long term maintainability", we tend to choose the latter.
That's definitely a valid view, but I'd say it's not the only one.
For some usecases, quick bootsrapping is incredibly valuable - eg an early-stage startup.
That was the historical case for Rails: quick to get started and not too bad to maintain/expand as you grow (it got better about later stages in the later years as the ecosystem matured). That's a tradeoff that can make a ton of sense when you're starting a project that has a good chance of not existing in 6 months and where every day of initial productivity is incredibly valuable.
As far as I know Redwood has no server-side rendering solution. You can do both client-side rendering and static generation (although not as sophisticated as Next.js'), but not server-side rendering.
Next.js also has a pretty small API surface and is generally quite unopinionated when it comes to your apps structure, while Redwood chooses more of the stack for you and what tools you should use (Storybook, Jest, Prisma, GraphQL).
I would also like to point out that while there are a lot of people rooting for Redwood's success and they seem to have some active core contributors, there is actual financial backing for Next.js and they have large enterprise users.
There are some startups that use Redwood listed on the 1.0 update website, but at least I do not know any of them.
> As far as I know Redwood has no server-side rendering solution.
SSR is priority number one for v2. In the meantime, a number of users use Next.js as a client that talks GraphQL to the Redwood backend. It works very well!
> there is actual financial backing for Next.js
Today I announced I will be providing $1M of funding for future RedwoodJS framework development this year, so now we have funding too. =)
The truth is, we can both succeed at the same time, there are so many great app ideas waiting to be explored, and different tools will work better for different situations!
I'm the author of Svekyll (https://svekyll.com) a static blog tool which models the simplicity of Jekyll. Svekyll uses SvelteKit under the hood, but rendering to a static site feels like it is a second class experience in SvelteKit (they are more focused on rendering to cloudflare or netlify or vercel serverless platforms). I would love to experiment with using RedwoodJS as the backend if SSR is a priority; how do I get more information on that work?
Hi! Core team member here, right now we have our hands a little full with the launch week, but will be moving onto v2 very soon!
Best way to get more info is to create a post on the forums, or an issue! The discord contributing channel is a great place too. All the links on the main website https://redwoodjs.com
> while Redwood chooses more of the stack for you and what tools you should use (Storybook, Jest, Prisma, GraphQL)
Very true! Just know that the overall integration is modular and extensible.
- byo DB Client
- want to use REST, go for it!
- power Next via the multi-client API, lots of startups doing that already
> There are some startups that use Redwood listed on the 1.0 update website, but at least I do not know any of them
That makes sense because most of them are less than 1 year old. And the funding amount listed was raised in the previous 6 months.
The number that I'm really interested in, are last commits more than 28 days ago. With this number, you can guesstimate how popular Next.js is with non core contributors and in the case of Next.js, it really is staggering.
The basic idea is, if somebody last committed more than 28 days ago, it is likely that they are not a "core contributor" since you would expect "core contributors" to commit more frequently than every 28 days. Hope that makes sense.
For Next.js, the percentage of people that last committed more than 28 days ago accounts for 80% of all unique contributors, which is what makes their project quite staggering from a "popularity" standpoint. Assuming everybody that last committed more than 28 days ago are not "core contributors" (which may not be accurate of course) we can see that Next.js had 169 contributors that basically decided to create a pull request that was good enough to be merged. For Redwood they had 23, which is respectable but not on the same level as Next.js
Based on my analysis of very popular open source projects, most projects typically only have 50% of their contributors in the +28 days range, while Next.js has 80%. Looking at last commits more than 28 days ago is a very good indicator of community health/interest.
I've been living and breathing this project for over two years. From an "is the project healthy" perspective, your explanation of what you interpret from these analytics makes no sense to me. I suspect there's some pre-existing bias as well. (I.E. yes, Next is a very popular front-end React framework and it's been around for a few more years.)
Note: I love analytics. I just think this is, well, weird reasoning from the face of it.
I'll counter with this — here are the metrics I focus on as a measure of "is our open source project healthy"?
- How many unique contributors are there per release? && Is the number growing, steady, or decreasing?
- How many new contributors are there on a monthly basis && Is the number growing, steady, or decreasing?
I agree and I wrote "the project is quite healthy", so I don't quite know why others would interpret it in any other way. I also agree with the metrics that you laid out and those metrics will be surfaced in the future along with others, since numbers need to be put into context. For example, how are people contributing. Are they making simple spelling changes? Are they making changes to core languages (i.e. Typescript vs Markdown, etc.)? Are they adding a lot of new code and so forth.
Something worth noting is, the analysis is based on Pull Requests that were created in the last 4 months for both Next and Redwood and as it currently stands Redwood had 55 unique contributors and Next had 210. By all metrics, Redwood is quite healthy (as I stated in my comment), it is just that Next has a lot more contributors (4 times more and it something that can't be ignored), especially with the number of contributors in the +28 days range.
Thank you for the reply. This is an interesting topic. I think at the core a comparison to Next is still apples to oranges imho and unnecessary here. But that's probably a distraction from the concepts at hand.
> Are they making simple spelling changes? Are they making changes to core languages (i.e. Typescript vs Markdown, etc.)? Are they adding a lot of new code and so forth.
I think what you're trying to get at here is answering the question, "Is PR A of greater quality or value than PR B?" I've decided that doesn't matter as much as:
- How easy is it for anyone to open and merge a PR of any kind?
- Once someone opens a PR, do they open another?
- What's the preexisting skill level of someone opening a PR relative to the difficulty of the PR they're attempting?
Trends. Over time. I can't tell you how many contributors start with simple doc updates (which, by the way, are as important as code for the Redwood community) and then follow up with a monster PR. Momentum builds momomentum. Collaboration leads to more collaboration. For the most part, "is A better than B?" is a distraction.
Again, all from my experience and not demonstrable otherwise.
> 4 months for both Next and Redwood and as it currently stands Redwood had 55 unique contributors and Next had 210
One of the reasons this likely feels low to me (in the case of # of Redwood contribs) is that we separate concerns across repos. Is this for the org or the repo?
It would be impossible to find an accurate number, but I'd be much more interested in the ratio of (unique contributors) / (project installations or downloads) and how that ratio trends over time.
For a metric like that, how might the Redwood vs. Next comparison play out?
You are welcome and your response has been extremely helpful as well.
> I think at the core a comparison to Next is still apples to oranges imho and unnecessary here.
I agree it is probably an apples and oranges thing from a tech perspective, but clearly this isn't the case from a marketing one. I responded because somebody had concerns about the health of Redwood compared to Next.
> "Is PR A of greater quality or value than PR B?"
This isn't really want I want to do. Understanding how a PR affects a project isn't so much about quantifying value, but rather, it is about quantifying effort. A single line change can take takes days or months to get right and I want to better capture the effort required to make a change.
The questions/metrics that you raised are quite good and it is something that I will be working with Open Sauced (which you know I believe) to surface. The pattern that you've described is something that I wish to confirm as the goal is to find a way for maintainers to easily identify contributors worth nurturing and for contributors to find projects worth their time to contribute to.
> Is this for the org or the repo?
Below is a combination of all recently active repos from Redwood
Redwood had 79 unique contributors with one or more merged pull requests and Next had 214 unique contributors with one or more merged pull requests. If we ignore the merged criteria, Redwood had 96 unique contributors and Next had 350.
Congrats! It's nice to see that authentication and authorization are handled in the framework from day 1. This is often overlooked, but such a critical part of building new applications.
The auth package is a single interface that can be extended by 3rd party auth providers. When we originally created it we supported auth0 and magic.link, but now there are more 10!
So, imagine you want something quick, so you pick magic.link and you launch to a bunch of demo user's, but decide it doesn't scale for your *new* needs, you'll be able to switch out to Auth0 without having to change any client side code (other than initialization).
Of course you'll have to migrate your users.
Having the ability to pick an auth provider, or host your own to suit your needs/ risk requirement, is very important to us!
I love that design decision. How about authorization? :)
disclaimer: I am a co-founder of Aserto [0], an authorization platform for developers.
I think it would be awesome to explore how to grow the authorization model from a simple set of roles / permissions to a fine-grained model as the application matures.
I like Redwood, compared to Remix it has all the required opinionated boilerplate that is required for startups. It reminds me of using the whole battery included framework such as laravel or django as opposed to spring boot / aspnet.core
If you work in big tech companies probably you would never use it as they have enough resources to build different services and have enough developers for different purposes. However if you're a solo dev for startups that wants to build MVP, it definitely reduces the amount of work needed to setup FE, BE, infra, etc. The amount of work needed to ship MVP is greatly reduced.
Of course those are all in the expense of learning the framework itself.. but props to these guys with good docs! hopefully it will gain more and more traction!
Wow this is a really well done little marketing thing to make the 1.0 an entire week 'event'. I like how it ends only with, 'here try the tutorial' and not 'please let's sign you up for newsletters, alerts, etc. etc.'.
Glad you appreciate it! My number one goal for launch week and the new homepage and this event reminder site is to drive the "tutorials taken" number. For me, that is success.
Interesting, I find it exhausting instead. I'm intrigued by Redwood and glad to hear it hit 1.0 but I'd rather see everything they have to say now instead of having to "stay tuned" for more. I either remember to come back in a few days to see what it was or I forget about it and miss out on what could have helped convert me into a user.
I find the bundling of stack + startup success to be quite a peculiar sell. I wouldn't have considered the two that strongly linked - but I may not be the wrong audience for it.
It is unusual, perhaps, but as Redwood has evolved, it's been natural for us to really offer support for startups using our tools. Redwood is a more complex, more integrated, and more aligned with long term maintainability than most of the alternatives, which means our market focus is on projects that need that kind of tooling. And who needs that tooling most? Startups! Plus, I do a lot of angel investing and so helping startups is of great interest to me, so I can combine my great loves!
Many RedwoodJS contributors have startup experience and we applied much of that in delivering features that often get lost in the rapid MVP pace where you have a small team and iterate fast ... only to face those decisions later. And it's not a surprise that these feature get left out early on: they take time and money -- two things startups have to manage from the get go.
Testing, logging, webhook support, setting up authentication, involving your designers more with Storybook, seeding data, mocking data, deploying, GraphQL best practices.
These are all common solvable problems that RedwoodJS has already thought of so you can focus on building a product.
Engineers often build products that "scratch their own itch." What I've found is that this product tends to attract users that are almost exactly like them! (My data is anecdotal, but I have done several user interviews, and the similarities are uncanny!)
I think a large portion of the early creators and contributors of RedwoodJS are people that were interested in building startups.
I disagree, I've never heard of them so it doesn't give me that confidence. In fact it hurts the brand, it signals that this is not mature enough to be used by Fortune 500 and from the description of its underlying choises, it is a Rube Goldberg machine, one that pulls you in with perceived productivity hacks only to end up with navigating the dozen of libraries wired up in ways to get the developer to not think about them because the battle tested and mature paths are boring and lacking in novelty.
I've been down this path before, where claims of productivity gains to get you an MVP is true to a certain degree, only to have a giant web of wiring that creates implicit and explicit cognitive load, in my opinion, its like taking out a loan for an increasing cost of capital from rising interest and equity , where eventually, you can't hire, you can't debug, you can't reverse due to sunk cost since you've bet your horses on the shiny new trendy thing where you depend on other's opinions and their understanding of the problem which will offer no real benefits to your specific, specialized contexts. This is in fact the problem with many full stack or opinionated frameworks, it ignores the last mile problem.
As I grow older, I realize now the wisdom of choosing boring tech, when I was younger it was quite frustrating but now I see that PostgreSQL + Server side rendered language + Progressive interactivity is still strong for a reason and it is not Luddism or gerontocracy, it is stability from time tested collective experience of all minds. PHP is still going strong to this date.
At the end of the day, all tech stack, architectural decisions are economically constrained by time, capital and labor supply. An overly complex arrangement, especially one that focuses on novelty over what has worked and widely used, increases risks due to unknowns. Specific issues and challenges can be addressed in bite sizes, rarely do they require ripping out the established paths, instead of throwing in a dozen of new, complex dependency and opinion ridden web of tech that is highly novel & guarantees implicit volatile technical debt with false gains that require far more trouble than its worth.
Quite intrigued by this, and will definitely step through the tutorial. It will be interesting to compare it side-by-side with Adonis (and possibly Nest).
I am sincerely interested in what you learn. If you do a comparison and have some time to communicate the results, please look me up on the Redwood Forums or Twitter. This would be a helpful resource and discussion for our community and maintainers (because we are always learning and collaborating, to be clear): https://community.redwoodjs.com
No pressure at all.
(I'm one of the co-founders/leads of Redwood. Tag me @thedavidprice)
The readme goes into details more in depth than I will, but as a dev raised on javascript and cloud tech, I like redwood for probably the same reasons that devs raised on ruby like ruby on rails. I get to keep using all the tech i'm comfortable with but the tooling is all preconfigured and the dev experience is smooth and optimized.
My reading is that this is an all-in-one package of the current best practices stuffed into a jar. It saves you some decision-making but also ossifies your platform into a fixed point in the hype cycle. It's probably a solid platform and get you to market a bit quicker but that isn't really a bottleneck for anyone as far as I can tell.
IMO the main value of a framework like this isn't to save you time. That's what they advertise on the homepage, but I suspect that's just because it's an appealing concept to a lot of people. I think the real benefit is an increase in the chance that you build your app in a way that's sustainable. It's a pooling of experience and feedback on choices to create a whole that might not be flawlessly perfect for what you are building, but is likely worlds better than the disaster that usually occurs when you let the in house devs make too many choices.
> ossifies your platform into a fixed point in the hype cycle
Definitely true, but they have gone for some pretty established stuff here. The only ones I can see possibly being contentious in like 5 years or whatever timeline you want are Prisma and GraphQL, but even for those I'd bet on them still being sound choices for a long time. Also presumably the framework continues to develop (Rails 7 is a LOT different than Rails 1.), but that is a bit of a bet on it's adoption.
As a dev I get the appeal of something more flexible that lets you make your own choices, but I think that almost universally ends up being a curse rather than a blessing.
> I think the real benefit is an increase in the chance that you build your app in a way that's sustainable
Yes, indeed! We discuss "long-term maintainability" often in the project README and during interviews. This is one of the primary lessons Tom learned when building GitHub on Rails.
> ossifies your platform into a fixed point in the hype cycle
We are learning how to communicate these things better, but conventions, tight integration, and a "golden path" do not equate to lock-in of any kind.
If you read through other comments, you'll find a lot of examples where devs are using alternatives for the API as well as front-end libraries.
If your other option is "raw" React, Next.js: You'll do less yak-shaving and have to manage less engineering complexity versus using Next.js and rolling your own db/auth/testing/access control.
If your other option is Blitz: you get a larger core team, GraphQL if you like that, and fancier generators.
If your other option is Django/Rails/etc: it is like Rails, but integrates better with the frontend.
Django/Rails comparison is a bit short I would argue, Redwood lacks a lot of their backend capabilities (Active Storage, mailing solution, jobs, Action Cable).
Have you tried Unpoly? It's like htmx but more "high level". I've used it for several projects and it is one of the more underrated tools out there. On my latest project.im using it in combination with Alpine.js on a Laravel application and I'm loving it.
Further, what is it? Maybe I'm not a very good reader, but after looking at the website multiple times I'm not at all sure what RedwoodJS is. Comments here suggest it is some sort of React framework ...?
I didn't. Thank you! It would be nice if this information was on the link posted to HN though, or maybe the link should be changed to something more clear.
1. Redwood tightly integrates more of what you'll need as your app evolves: Storybook, Jest, Auth, Deploy, Logging, and a lot more.
2. A first class GraphQL experience so you can start from day one with the idea that you'll have multiple frontend clients (web, mobile, desktop, CLI, etc) so you only build your backend once.
3. Declarative data fetching with "cells" that make using that GraphQL backend super simple.
4. A community of builders and startup founders intent on helping each other succeed.
5. An amazing tutorial and set of documentation.
Speaking of the tutorial, that's the best way to get started if you're curious to see how Redwood feels in action!
I've kept half an eye on Redwood since the early days, but i'll have to give it a proper look.
My original understanding was that it was a static site generator, but this doesn't actually seem to be the case? In which case, i'm curious how the request waterfall problem is mitigated, given that the data loading is cell-oriented rather than interaction-oriented. My background with GraphQL comes from using Relay for 6+ years, so I'm used to there only being one query per interaction (pageview, click etc); whereas from the looks of Redwood, the nature of cells seems to indicate there can be multiple queries, potentially cascading ones involved in building a single screen.
You are correct, if you're not careful with your data fetching you can get into a waterfall situation. This is something we're keen to address in coming versions. Because we can get in the middle of your data fetching flow if you use cells, we should be able to do some optimizations without you having to do anything extra!
Wouldn't this just be a matter of adding a component at the page level which calls the Phoenix Socket function? This should be framework agnostic since the post you linked above just works with React.
It works with react because phoenix framework can send request response with websocket rather than api, I'm thinking of replacing Phoenix with RedwoodJS.
Rails also has websocket support but those are not as performant as Phoenix
Is it possible to do Redwood development completely on something like Github codespaces or CodeSandbox? Last time I checked (~6 months ago) this didn't play nicely with Docker but curious if things have changed since then.
Yes, indeed! First off, Redwood comes with a Fastify server. `yarn rw serve` is the command you're looking for. Check out the Deploy Docs and this repo thats coming along: http://github.com/redwoodjs/docker/
Secondly, we use Gitpod extensively — starting with a Dev environment for contributing. And as of a week ago we now how a Gitpod starter that spins up a new install @latest using Postgres. Check it out here: https://github.com/redwoodjs/gitpod-starter
Full Doc and being included at the intro to the Tutorial are coming soon!
I want to use an opinionated framework like this but with Angular on the frontend. Does anything like that exist? Closest thing I can think of is wiring together Nest.js + Prisma + Angular.
That would be very cool to look into. Is there any documentation for that somewhere? I tried googling "redwoodjs angular" and didn't see anything obvious. Thanks for response.
Hey, another core team member. You certainly can use whatever client you want with the Redwood API - you just might not get all the bells and whistles that are built into our web side!
The GraphQL api in Redwood is powerful, yet simple - so you would build your backend in Redwood, and have your angular front end make gql queries like you would with any other backend.
Not that I know of. But here are a few things that may be of interest.
Redwood's GraphQL API is built on Yoga (we collaborate tightly with The Guild) — https://www.graphql-yoga.com You just need a GraphQL Client, which The Guild already has an option ready for you https://apollo-angular.com (Note: Apollo or other clients fine as well.)
I'm a co-founder of Redwood and help lead the project so I can say as a matter of fact we a highly collaborative and enjoy (and support) exploratory projects. It's a priority for us to better demonstrate the power of Redwood's API through examples. If you'd be interested in digging in collaboratively with the community, I can help connect the dots. Just kick things off over here and tag me @thedavidprice: https://community.redwoodjs.com
No pressure at all! Just wanted you to know the invitation is open. Anytime.
Is Redwood's own site running Redwood? I remember asking about it sometime ago, and the answer was "no, it's a marketing website, we don't use Redwood on it".
Yes, the new website we launched today is built with Redwood (except docs are done with Docusaurus). We're still doing some optimizations, but you are indeed looking at a Redwood app!
Is there are part that does the rest? Deployment, Staging, CI, Backups & Restore, Rolling Upgrades with fallback, etc.... or is that still left as an exercise for the reader?
I found this[1] on the documentation. But in general staging environments, continuous integration and continuous delivery are not built into frameworks (Rails, Phoenix, etc).
Imagine if DHH was able to raise several millions of dollars for what is a front end and crud framework packaged from existing open source libraries… money is indeed cheap at the moment and I guess private equity / VC have to put excess liquidity somewhere.
Please, have landing pages & announcement pages explain up top what your thing is, or have the obvious click-targets (like the logo or project-name) take people to an introduction.
If you've gone through all the trouble of designing/promoting a big launch/milestone site ("v1launchsite"!), don't require people to compose a Google query in another tab to get the one-sentence overview.
Thanks, though what I'm looking for (and, I expect, many/most other developers too), is a simple statement of whether I can write my backend in Go, Java, python, node, etc.
My experience with many other frameworks is that they really help you get started quickly, and some of them truly cover a vast majority of common use cases. But when you reach a point of need or situation where they don't work the way you want, you must then learn how to work around them or enhance them.
That usually means doing a lot of digging and learning, essentially repaying that early time gift you received from all the nice built-ins.
This should be a pretty familiar scenario for many of us here, and perhaps some have experienced this with RedwoodJS. If so, how do you feel about the framework now? How was the workaround/change-behavior experience?