Hey Marius! Great walkthrough - sorry I missed this last November. I'm one of the co-founders of Redwood. You hit on a few things that are very common misconceptions about Redwood. Namely, tightly integrated != tightly coupled. Don't want to use Prisma, they byo DB client. Want to swap out Apollo Client? Go for it. Want to use Redwood API with *any* different front-end library or client (thus, GraphQL). Also, you hit on a really important aspect about why you'd want to start with something like Redwood even if you can "do it all yourself"? The answer is two-fold: 1) managing config and integration is overhead that becomes time-consuming, time that is better spent on features and business logic, and 2) that conventions are important for long-term maintainability. tl;dr: Just like Rails, Redwood offers a "golden-path" to help applications move quickly at the beginning and focus on end-to-end CI/CD and performance out of the box. As things grow, developers will need to swap out and customize - they'll exit the golden path but still find that Redwood is completely compatible.
Also, you should dig in further to Redwood's Auth and Security out of the box (including tests). You truly scratched the surface of what's been pre-integrated and how much power you get out of the box. To be fair, a lot has happened since November!
Thanks David!! I appreciate the thoughts and feedback. I think I definitely misunderstood/misspoke when I said towards the end that you might be “locked in”. I don’t fully remember what the state of the docs were like at the time, but I don’t remember seeing any docs or guidance for going out of the “golden-path”. If as you say it’s a common misconception then it maybe could be documented better. But thanks for chiming in, I’ll pin your comment so others can get that extra context, and I’ll definitely have to revisit the framework and docs when I get a chance!
@@mariusespejo Thanks so much! Greatly appreciate your reply and, most of all, the fact you took the time to record and share this video!! Also, we just recorded another meetup that covers all the categories of features included in Redwood 1.0, which we published the first week of April. I think you'll be interested to see how far things came from November '21 to April '22.
@David Price I've been exploring Redwood for a somewhat ambitious new personal project and have had a very positive first impression -- lacking motiviation early in a project is my Achilles' heel, so having so much boilerplate work handled for me out-of-box early in the cycle is huge. I appreciated and resonated w/ Marius' observations/concerns about "lock-in" however, so I'm wondering if you could point me to any articles, documentation, etc. that deals specifically with customization as devs opt to leave that "golden path"? For ex. how exactly *would* I swap out prisma or GraphQL for something else, where the integration *appears* to be so tightly coupled by default?
Yup, like adonisjs it has its place and purpose. As long as it aligns with exactly what you’re looking for then it’s a perfectly good option. But personally I like that with Nest I can pivot at any given moment
Great video, totally agree with your conclusion. Something I've been wrestling with lately on starting a new project is whether or not to use NXjs. In some ways its generators are great and it really helps running a monorepo, but I keep feeling like my project very quickly becomes daunting just in the number of folders and configs everywhere. Knowing when I need to use the NX generators, Nest generates, React stuff, storybook, e2e. I keep wondering if I should just use Nest and use its much simpler mono-repo structure for the UI and so on. I just want a nice clean full-stack monorepo that doesn't become a nightmare of configs everywhere. I mean NX does its job well, I just can't shake this feeling of clutter. Any opinion on this? Perhaps a video on using NXjs to build a full-stack Nestjd, Graphql, Prisma, React, Storybook etc. project and give your take on the overall complexity?
Thanks for your thoughts! Nx looks like it would be good to explore for another video. To be honest I haven’t had a ton of experience with monorepos, so take what I say with a grain of salt: My gut tells me to keep it simple and have one project per repo. The complexity of managing multiple projects in one repo is likely what forces you to rely on these build tools. If for example you’re trying to use react with Nestjs, what real reason is there to have them in the same repo? I’m not sure there is one unless your Nest server is also serving up the UI. Why couldn’t you just have two deployables? Your Nest is likely already exposing an API as the interface, why does it need to be coupled with your React app? Tools that generate specific structures I think are good if you’re in a big team that requires conventions so things don’t get messy (with each person’s own preferences). But for a small personal app? Just do it your way. I did have a recent video on Nest + Prisma + Graphql + React, but no nx.. maybe that might show you what it would like without it
ua-cam.com/video/lddaR8Y-gko/v-deo.html You’ll notice it’s maybe a little bit more upfront configuration, but once you get past it, the rest is fairly simple
I have a Redwoodjs sticker on my laptop I got in a virtual conference. But it was way back and the project seems in its early stage. I never got the time to try it. Thanks for the tutorial.
It does look like they’re getting close to their stable 1.0 release, maybe early 2022, so it has matured quite a bit but I’m sure will still see some changes prior to release
I would love to see the Redwood equivalent working as a Gatsby in the frontend. That would be revolutionary for small-mid business startups (positioning)
BlitzJS is a similar idea but one of their core ideas is “loose opinions”, so it’s not hard to use an alternative to prisma for example. They also are having talks about making blitz have a nest-like backend, and apparently people have already figured out how to set it up that way. It also defaults to typescript, maybe worth a video like this?
Not yet familiar with svelte so I can’t talk to that. But honestly for a new dev, you should stick to learning the fundamentals. Learn html, css and js well. Don’t jump to a framework immediately. Once you have that base, move up to something like react, svelete, vue, etc.
@@mariusespejo yeah I've got a patchwork of experiences stepping up through low-code to python and other things where it is starting to come together, but really trying to move faster/scrappy, where a no-code solution won't work for my startup.. Alternative is also in play, where I'm looking for potential hires or co founder -- anyone in Australia?!
@@mariusespejo Just got through to the end of your review - I really appreciate that final impression, having become more familiar with something like Svelte. Redwood feels quite disorientating (without knowing or being able to easily intuit what is happening where, each time you run a command line generator). I dunno if that resonates but just a feeling I'm getting because there seems to be a few different patterns in there as well to learn - just as you said - before you can be productive with the system that's been set up in this framework. *imo as a relative newcomer
Hey Marius! Great walkthrough - sorry I missed this last November. I'm one of the co-founders of Redwood. You hit on a few things that are very common misconceptions about Redwood. Namely, tightly integrated != tightly coupled. Don't want to use Prisma, they byo DB client. Want to swap out Apollo Client? Go for it. Want to use Redwood API with *any* different front-end library or client (thus, GraphQL). Also, you hit on a really important aspect about why you'd want to start with something like Redwood even if you can "do it all yourself"? The answer is two-fold: 1) managing config and integration is overhead that becomes time-consuming, time that is better spent on features and business logic, and 2) that conventions are important for long-term maintainability.
tl;dr: Just like Rails, Redwood offers a "golden-path" to help applications move quickly at the beginning and focus on end-to-end CI/CD and performance out of the box. As things grow, developers will need to swap out and customize - they'll exit the golden path but still find that Redwood is completely compatible.
Also, you should dig in further to Redwood's Auth and Security out of the box (including tests). You truly scratched the surface of what's been pre-integrated and how much power you get out of the box. To be fair, a lot has happened since November!
Thanks David!! I appreciate the thoughts and feedback. I think I definitely misunderstood/misspoke when I said towards the end that you might be “locked in”. I don’t fully remember what the state of the docs were like at the time, but I don’t remember seeing any docs or guidance for going out of the “golden-path”. If as you say it’s a common misconception then it maybe could be documented better.
But thanks for chiming in, I’ll pin your comment so others can get that extra context, and I’ll definitely have to revisit the framework and docs when I get a chance!
@@mariusespejo Thanks so much! Greatly appreciate your reply and, most of all, the fact you took the time to record and share this video!! Also, we just recorded another meetup that covers all the categories of features included in Redwood 1.0, which we published the first week of April. I think you'll be interested to see how far things came from November '21 to April '22.
Loved this! Thanks for sharing valuable insights David!
@David Price I've been exploring Redwood for a somewhat ambitious new personal project and have had a very positive first impression -- lacking motiviation early in a project is my Achilles' heel, so having so much boilerplate work handled for me out-of-box early in the cycle is huge. I appreciated and resonated w/ Marius' observations/concerns about "lock-in" however, so I'm wondering if you could point me to any articles, documentation, etc. that deals specifically with customization as devs opt to leave that "golden path"?
For ex. how exactly *would* I swap out prisma or GraphQL for something else, where the integration *appears* to be so tightly coupled by default?
I went straight to your "Overall impressions" first and that was very helpful. It does sound overly opinionated. Nest really is a more open solution.
Yup, like adonisjs it has its place and purpose. As long as it aligns with exactly what you’re looking for then it’s a perfectly good option. But personally I like that with Nest I can pivot at any given moment
This is cool, thank you for the review
Great video, totally agree with your conclusion.
Something I've been wrestling with lately on starting a new project is whether or not to use NXjs. In some ways its generators are great and it really helps running a monorepo, but I keep feeling like my project very quickly becomes daunting just in the number of folders and configs everywhere. Knowing when I need to use the NX generators, Nest generates, React stuff, storybook, e2e. I keep wondering if I should just use Nest and use its much simpler mono-repo structure for the UI and so on. I just want a nice clean full-stack monorepo that doesn't become a nightmare of configs everywhere. I mean NX does its job well, I just can't shake this feeling of clutter.
Any opinion on this? Perhaps a video on using NXjs to build a full-stack Nestjd, Graphql, Prisma, React, Storybook etc. project and give your take on the overall complexity?
Thanks for your thoughts! Nx looks like it would be good to explore for another video.
To be honest I haven’t had a ton of experience with monorepos, so take what I say with a grain of salt: My gut tells me to keep it simple and have one project per repo. The complexity of managing multiple projects in one repo is likely what forces you to rely on these build tools. If for example you’re trying to use react with Nestjs, what real reason is there to have them in the same repo? I’m not sure there is one unless your Nest server is also serving up the UI. Why couldn’t you just have two deployables? Your Nest is likely already exposing an API as the interface, why does it need to be coupled with your React app?
Tools that generate specific structures I think are good if you’re in a big team that requires conventions so things don’t get messy (with each person’s own preferences). But for a small personal app? Just do it your way. I did have a recent video on Nest + Prisma + Graphql + React, but no nx.. maybe that might show you what it would like without it
ua-cam.com/video/lddaR8Y-gko/v-deo.html
You’ll notice it’s maybe a little bit more upfront configuration, but once you get past it, the rest is fairly simple
What do you think of RedwoodJS? Would you use it? 🧐
I have a Redwoodjs sticker on my laptop I got in a virtual conference. But it was way back and the project seems in its early stage. I never got the time to try it. Thanks for the tutorial.
It does look like they’re getting close to their stable 1.0 release, maybe early 2022, so it has matured quite a bit but I’m sure will still see some changes prior to release
you convinced me, i will try it, wait for my blog
That look like ruby on rails in javascript.
Interesting tho.
Really enjoying your content!
🙌😄
I would love to see the Redwood equivalent working as a Gatsby in the frontend. That would be revolutionary for small-mid business startups (positioning)
Pretty much just pick any graphql/prisma based backend and have a gatsby ui make calls to it and that would be the equivalent
BlitzJS is a similar idea but one of their core ideas is “loose opinions”, so it’s not hard to use an alternative to prisma for example. They also are having talks about making blitz have a nest-like backend, and apparently people have already figured out how to set it up that way.
It also defaults to typescript, maybe worth a video like this?
Thanks for sharing! Will definitely check that out sounds interesting. I definitely to a degree prefer frameworks that defaults to typescript
I would like to see your take on blitzjs for sure! :)
Can you make some Golang videos please??
i’ll think about it but my channel is really more geared towards the JS ecosystem
@@mariusespejo
Thanks so much for your effort and this amazing content.
How about React Native course :D ?
What do you think between Redwood and Svelte? Would love to know if anyone has compared experience, especially for a new dev?
Not yet familiar with svelte so I can’t talk to that. But honestly for a new dev, you should stick to learning the fundamentals. Learn html, css and js well. Don’t jump to a framework immediately. Once you have that base, move up to something like react, svelete, vue, etc.
@@mariusespejo yeah I've got a patchwork of experiences stepping up through low-code to python and other things where it is starting to come together, but really trying to move faster/scrappy, where a no-code solution won't work for my startup.. Alternative is also in play, where I'm looking for potential hires or co founder -- anyone in Australia?!
@@mariusespejo Just got through to the end of your review - I really appreciate that final impression, having become more familiar with something like Svelte. Redwood feels quite disorientating (without knowing or being able to easily intuit what is happening where, each time you run a command line generator). I dunno if that resonates but just a feeling I'm getting because there seems to be a few different patterns in there as well to learn - just as you said - before you can be productive with the system that's been set up in this framework.
*imo as a relative newcomer
maybe it's my crappy computer, or webpack, but Redwood is very slow...
new theme who dis? xD
😂
reminds me of laravel