My experience with many other frameworks is that they really help you get started quickly, and some of them truly cover a vast majority of common use cases. But when you reach a point of need or situation where they don't work the way you want, you must then learn how to work around them or enhance them.
That usually means doing a lot of digging and learning, essentially repaying that early time gift you received from all the nice built-ins.
This should be a pretty familiar scenario for many of us here, and perhaps some have experienced this with RedwoodJS. If so, how do you feel about the framework now? How was the workaround/change-behavior experience?
I like the concept of innovation budgets for startups. You can only innovate on so many vectors because time is typically your most limited resource. Very few startups have a good reason to spend any of that budget on innovations that are not core to their product differentiation. These things include web frameworks, corporate structure, credit card processing, low-level hosting. Just pick a pretty standard solution that fits your use-case and move on. I don't think it's a coincidence that so many of the big startups over that past 10 years were built with big batteries-included frameworks (would be so curious about a larger study of this, I just have cloudy anecdotes).
Don't get me wrong, I love bleeding edge web stuff and playing with new frameworks. But if my priority is making a new company succeed I'm going to look for a framework that minimizes time spent picking libraries and gluing them together nicely and maximizes time I have to iterate on the product and tweak user-facing business logic.
There will be a point in the product lifetime when you will outgrow the framework and you will need to rewrite large portions of it and pay off the tech debt. Most projects don't get to that point. Once there, it is also the right time to make those decisions that were classified as premature optimization. Now they are merely tech decisions with one crucial difference: at this point you have much more information about the product, the market, the customers, and your team than you had initially, so now you can take the best decisions about what will really increase your velocity.
If speed to market is not essential (such as a side project for fun) then by all means, it's you now, and it's you later, so take the time to enjoy your craft and become proficient at combining the best tools to make your project shine, instead of opting for the cookie cutter frameworks.
(random mixing of past and present tense because it's still around and presumably still good but I don't use it)
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
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.
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.
You can also join additional data to reference in deeper resolvers, but that's an antipattern AFAIK.
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.
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)Redwood Forums: https://community.redwoodjs.com
Redwood Discord: http://discord.gg/redwoodjs
?
[::] -> [::1]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...
What would you recommend instead o yarn and webpack?
I have been using vite and npm in my small frontend projects.
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.
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.
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.
I'm in an architect role for work now and I get to code less and less during the day. RedwoodJS has enabled me to actually build something in my own time and (hopefully) launch it.
I didn't know GraphQL or Prisma before starting to use it but between the Redwood docs, Prisma docs and with some RW community help I've made good progress.
And please do show off what you've built! I'd love to see it.
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.
Redwood: An integrated, full-stack, JavaScript web framework for the JAMstack - https://news.ycombinator.com/item?id=22537944 - March 2020 (167 comments)
Why does the JavaScript rendering require so many abstractions layers ?.
I understand the promise that frameworks sort of do the heavy lifting for you, but after 2 years into the app, you are stuck with the framework, and the work hours to fix problems are going up, cause most of your code is hidden inside the framework.
I use Web Components and some minor libraries, having so much easier time going this way.
Not to kick down the hard work on developing of Redwood, but I'm just tired of being forced to use these frameworks on jobs.
At startup stage the team picks a monolithic framework, after 2 years the developers are depressed building with it and leave, then new developers that come are met with a mess and fixing even easy bugs, is practically rewriting 5000 lines of code of the app, because everything is so entangled.
For the most part, i'd say that frameworks being largely standardized and having ecosystems around them is a really good thing: people who are familiar with Vue/Angular/React (front end) and with Spring Boot/Express.js/Django/Rails (back end) can start working with your application more quickly than if it uses your custom "sort-of-like-jQuery-but-not-really" set of libraries/framework for the front end or your own thing for back end, which obviously will fall short in regards to documentation, consistency or ready made components.
You can hire for Vue/Angular/React and Spring Boot/Express.js/Django/Rails, you cannot hire for your bespoke in-house solution.
Also, the devs behind those solutions can spend more time and resources on making them better than your entire app will have put into it.
That's why i largely avoid projects which have bespoke solutions like that, especially for back end frameworks, which typically are a minefield of badly written and badly tested code, as well as present numerous security related challenges. That stance was truly cemented when in one project i was stuck with an untested framework that stored half of the functionality in the DB, used JDBC directly through numerous abstractions, had commented out sections of code strewn about the codebase and had comments in Lithuanian, a language that i don't speak and had no documentation whatsoever.
Of course, i've also seen things go into the opposite direction too far: instead of something like Bootstrap or its integration with any of the aforementioned popular frameworks/libraries being used, picking Tailwind CSS and spending weeks if not months mucking about with custom components without actually shipping features and solutions to business problems.
If you are lucky enough to have front ends simple enough to be adequately handled by a few hundred/thousand lines of JS then by all means go ahead (right tool for the problem and all that), but that has never been my experience in any of the enterprise projects that i've worked on.
Admittedly, however, i do feel these standard frameworks/libraries also getting more and more complicated as time goes on, because their eventual transformation into something that tries to do "everything" (and thus downfall) feels almost inevitable.
Looks to me what it is: a "safe", as in common, meshed stack for new teams to develop mvps.
But nothing of Redwood makes me think, "this is the missing piece I was waiting for" as I've worked with most of this stack in various combinations and I think it's a stack that's getting old and is not scaling or getting much better with time.
If you can get this out of the box, this seems like a very good value prop. 'Boring and not innovative' isn't a flaw unless you're looking for something exciting and innovative, and most applications don't need this.
- 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.
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!
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.
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.
If you work in big tech companies probably you would never use it as they have enough resources to build different services and have enough developers for different purposes. However if you're a solo dev for startups that wants to build MVP, it definitely reduces the amount of work needed to setup FE, BE, infra, etc. The amount of work needed to ship MVP is greatly reduced.
Of course those are all in the expense of learning the framework itself.. but props to these guys with good docs! hopefully it will gain more and more traction!
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 think a large portion of the early creators and contributors of RedwoodJS are people that were interested in building startups.
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.
No pressure at all.
(I'm one of the co-founders/leads of Redwood. Tag me @thedavidprice)
The readme goes into details more in depth than I will, but as a dev raised on javascript and cloud tech, I like redwood for probably the same reasons that devs raised on ruby like ruby on rails. I get to keep using all the tech i'm comfortable with but the tooling is all preconfigured and the dev experience is smooth and optimized.
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.
“Redwood is the full-stack web framework designed to help you grow from side project to startup.”
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.
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
Is it possible to do Redwood development completely on something like Github codespaces or CodeSandbox? Last time I checked (~6 months ago) this didn't play nicely with Docker but curious if things have changed since then.
Secondly, we use Gitpod extensively — starting with a Dev environment for contributing. And as of a week ago we now how a Gitpod starter that spins up a new install @latest using Postgres. Check it out here: https://github.com/redwoodjs/gitpod-starter
Full Doc and being included at the intro to the Tutorial are coming soon!
GraphQL is a multi-client solution. Is there something more you're specifically looking for?
If you've gone through all the trouble of designing/promoting a big launch/milestone site ("v1launchsite"!), don't require people to compose a Google query in another tab to get the one-sentence overview.
> 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).