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.
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!
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.
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!
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'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.
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!
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!
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.
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.
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.
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.
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!
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
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!
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 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.
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.
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.
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.
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)
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
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.
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.
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.
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 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.
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!
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.
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.
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.
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.
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.
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.
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.
195 comments
[ 0.24 ms ] story [ 161 ms ] threadThe 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.
> 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.
“Redwood is the full-stack web framework designed to help you grow from side project to startup.”
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!
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.
And worse with the backend.
Let's not pretend running code in the server are issuing queries to a database is all you do in the backend.
It is indeed a web app framework, based on React, GraphQL, Prisma, Storybook, Jest, and with many integrations for auth, logging, etc.
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.
- 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.
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.
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.
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.
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. =)
https://tom.preston-werner.com/2022/04/04/redwood-v1-and-fun...
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!
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
Speak to you over there!
We haven't communicate this very well until today. Redwood is funded and will continue to be funded. Just not in a typical "for-profit" business model. See: https://tom.preston-werner.com/2022/04/04/redwood-v1-and-fun...
> 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.
Looking at merged pull requests, the project is quite healthy as the following shows:
https://oss.gitsense.com/insights/github?q=merged%3Atrue%2Bp...
Next.js is on a whole new level though
https://oss.gitsense.com/insights/github?q=merged%3Atrue%2Bp...
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.
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.
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?
tl;dr:
Redwood is healthy
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.
> 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
https://oss.gitsense.com/insights/github?q=merged%3Atrue%2Bp...
Below are recently active repos for Next
https://oss.gitsense.com/insights/github?q=pull-age%3A%3C%3D...
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.
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.
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.
Join the Redwood Community: https://redwoodjs.com/community
So very excited to see what people with Redwood
Although it's not a typical for-profit business model, we are sustainable and will enthusiastically continue building Redwood to v2 and well beyond.
You can read more about all of that in today's blog post from Tom (aka mojombo): https://tom.preston-werner.com/2022/04/04/redwood-v1-and-fun...
> 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.
> Although it's not a typical for-profit business model, we are sustainable
If it’s sustainable, there's clearly something other than a one-off donation. What is it?
Congrats, it looks damn awesome.
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.
Can't help but giggle at the downvotes.
/s
Hacker News logic 101.
Man, this field really does move quickly.
Could you maybe provide a better argument for why you think we’d all have moved on by now? Aside from ‘wow its not as new as the new thing’?
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
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!
Thank you and good night.
:)
What would you recommend instead o yarn and webpack?
I have been using vite and npm in my small frontend projects.
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.
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.
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.
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.
[1] https://redwoodjs.com/docs/graphql#query-depth-limit
You can also join additional data to reference in deeper resolvers, but that's an antipattern AFAIK.
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.
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.
Redwood Forums: https://community.redwoodjs.com
Redwood Discord: http://discord.gg/redwoodjs
?
Thanks!
I am thinking of implementing something like: https://www.viget.com/articles/phoenix-and-react-a-killer-co...
Would it be feasible in RedwoodJS with or without websockets ?
Rails also has websocket support but those are not as performant as Phoenix
Redwood: An integrated, full-stack, JavaScript web framework for the JAMstack - https://news.ycombinator.com/item?id=22537944 - March 2020 (167 comments)
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.
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.)
Here's an example "How To" about connecting Next (React) with Redwood: https://community.redwoodjs.com/t/how-to-connect-a-next-js-f...
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.
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.
[1] https://www.snaplet.dev
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!
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.
[0] https://www.aserto.com
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.
I think a large portion of the early creators and contributors of RedwoodJS are people that were interested in building startups.
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.
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.
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 :)
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.
> Redwood is an opinionated, full-stack, JavaScript/TypeScript web application framework
> A Redwood application is split into two parts: a frontend and a backend. This is represented as two JS/TS projects within a single monorepo.
> The api side is an implementation of a GraphQL API.
Not sure you'd want to choose this if you want to roll your own API (without taking advantage of the framework/integration).
https://redwoodjs.com/
Is this primarily meant to show business people, after telling them what it is verbally?
It would be much less frustrating if it had a link to the homepage, which does describe the product: https://redwoodjs.com
v1 Launch Week Schedule (this HN Post): https://v1launchweek.redwoodjs.com
RedwoodJS Website: https://redwoodjs.com
GitHub Repo and README: https://github.com/redwoodjs/redwood/
All the conversation was happening here already, so we just jumped in! Apologies for the confusion. We could have caught that earlier.