I am trying to solve a few platform problems with our app that are more of the “running a boring business” variety versus pushing the envelope with innovation.
A few things that would really help us are:
ES Module Support - injecting modules feels bad and ESM came out 10 years ago
Yarn PNP Support - the whole, verdaccio proxy, packages via internet thing feels like it’s not the right thing for a large business and we’d like to vendor deps so it’s just fast and version controlled
Additionally, there are a lot of pieces of functionality in Redwood that are not relevant to us.
What we actually use:
Prisma
Cells
A single auth provider integration
Pino / logging
GraphQL server (no realtime, no multi-resolver requests)
Here are some things we don’t use:
Most of the PaaS partnership modules
“Deploys made easy” CLI functionality
Lambdas / serverless
Wrapper that mostly just call the underlying library (toast, etc.)
Sponsor redwood projects so people are incentivized to work on the boring stuff
Hire someone to fork redwood and remove everything we don’t use (effectively turn it into an internal framework and modify it over time to meet our exact needs)
Ignore it / wait for Redwood devs / bump Github issues
I’m wondering what the community thinks of each of these ways forward, and whether they’ve encountered the same problems when scaling from small startup to a larger business
Thank you for starting the conversation about these concerns, we at LeftLane have similar challenges, but I don’t think it’s a question of “running a boring business variety versus pushing the envelope with innovation”, but more of starting with Redwood vs growing with it.
For the Redwood team, I think it’s also a question of making the framework interesting for newcomers that want to hack something on the weekend, and making it possible for businesses to stick with it for the long term.
I mean, it was always been the goal to be “designed to keep you moving fast as your app grows from side project to startup.”, however, it’s not an easy goal, and they will always been more feedback from side project than startup. That’s why I’m happy that you started the conversation around that.
Making Redwood more modular is, in my opinion, the way to go. The effort is already started, you will notice most new features or upgrade come into their package, like Storybook, if you don’t need it, you can remove the @redwoodjs/cli-storybook dependency. It’s still not perfect yet, some need huge refactoring to be decouple, but some can be easily removed, like those “wrappers that mostly just call the underlying library”.
For us, the principal challenge with Redwood it’s not to keep our bundle small or our build fast, but to be able to take some different choice than the redwood way to it, and still be able to upgrade RedwoodJS, ideally, progressively. And by progressively, I mean, be able to upgrade one package of redwood at the time. It’s maybe possible with some, but it appears that these packages are not meant to be upgraded individually. We cannot expect that Redwood to think about all possible path for project to make upgrade easy. We build custom things on the assumption of certain behaviour in Redwood, and they make changes with the assumption that we build apps the RW way. That’s fine, but some upgrades could take weeks of refactoring, I always vouch to build as much as we can this way and take in consideration this potential cost in factor. However, if we can upgrade progressively, it’s easier to allocate time for things that break our custom configuration or functionality.
Back to your problem, starting with things that you don’t use. I don’t think it’s actually an issue, those or mostly dev dependencies that have no impact on build time, bundle size or maintainability. Excepted those wrappers that mostly just call the underlying library that, I would be happy to open a PR to remove those and update the doc/tuto to reflect the change if it’s something the RW team are ok with.
For those things that would help you, and definitely everyone direct or indirectly, it seems to already have some progress around it.
About Yarn PnP, @pi0neerpat already wrote its solution for challenge he got from changing the config.
I am uncertain if it’s something that everyone would want and should be the default in RW, but it’s certainly possible to make the change in your own project. Our yarn config is far from being the same as the default.
And for ES Module Support, that I know was a priority for the RW team for a long time, not sure where it’s now, last blocker I remember was Jest, and they tried to move to Vitest for that, but I don’t know if it’s still the case and when it would be release. Even ESM came out 10 years ago, not every package a made the move because of dependency of dependencies, and Redwood has a lot of them for good reason. That makes the task way harder than it seems.
I’m curious about what you mean by
Sponsor redwood projects so people are incentivized to work on the boring stuff
If you have more detail about the kind of projects that you would like to sponsor. I know some open-source projects have bounty that multiple people and organizations can bid on it, that could be an idea.
Hire someone to fork redwood and remove everything we don’t use (effectively turn it into an internal framework and modify it over time to meet our exact needs)
I don’t think it will be effective if RW can be fully modular. Most organizations that do this end up regretting because it’s always way more costly than expected and usually exponential over time.
Ignore it / wait for Redwood devs / bump Github issues
You forgot publishing PRs
I wanted to say, after using RedwoodJS for more than 4 years () already, staring as a solo-dev for a small falling start-up to working with an incredible team building a complex B2B SaaS, it’s been a journey. Making the decision around how to continue building with RW over time is unique for each project, it’s about your need and the more you advance, the more the decision will be unique to your case.
Here’s a quote that I find very relevant about this
The vast majority of instructional content found online is designed for beginners because that’s what the vast majority of people are. Most books are written for beginners, as well as most how-to guides, articles and essays, and podcasts and YouTube videos. Most courses are designed for beginners since those are the people who take courses in the first place; experts are far more likely to pursue self-directed learning.
Beginner advice is what’s popular, mainstream, and “viral,” because it’s easy to understand and consume without much thought. There’s no problem with that, as we’ve already seen, because “easy” is what beginners need.
But if and when you find yourself at the precipice of true expertise,a different approach will be needed . You’ll need to consciously ignore most mainstream advice, turn away the most popular books, and filter out the sources of information that other people rave about. You have to go deep, to intentionally seek out the more nuanced, hidden sources of knowledge designed for the already adept
– From [The Crucial Difference Between Beginner and Advanced Advice By Forte Labs]
(https://fortelabs.com/blog/the-crucial-difference-between-beginner-and-advanced-advice/)
Lastly, I’m curious about how the core team see the future for current growing projects with the upcoming Bighorn Epoch and if they have anything to add about modularity, ESM and PnP.
I think your observations for making RedwoodJS modular is great suggestion for making long-term Redwood projects more maintainable.
As a first step, we’ll be moving the 3rd party auth dependencies/ packages outside of the main repo, and seeking community/ owners for those.
Secondly we could remove Storybook as a dependency, and only explicitly request that it’s installed if the functionality.
This would already significantly reduce the amount of packages installed by a large magnitude. I’m going to ask @Tobbe to audit the current installed packages, and list out the most complicated examples. Secondly, we’re going to ask people to indicate which parts of Redwood they are using, and making future decisions based off that.
) already, staring as a solo-dev for a small falling start-up to working with an incredible team building a complex B2B SaaS, it’s been a journey. Making the decision around how to continue building with RW over time is unique for each project, it’s about your need and the more you advance, the more the decision will be unique to your case.