Congrats on the release. This feels like Rails for the javascript age. Moving from: REST => GraphQL, Sprockets => Babel/webpack, VM => Lambda, Caching => Static site, ERb => React, Active Record => Prisma, Rspec => Jest, routes.rb => Routes.js
I agree this is super exciting but those things come with a significant operational overhead that your traditional full stacks don't have.
one vm => many lambdas/microservices
react => server side rendering and state hydration, throw redux in there too
prisma => you can't beat the DB with code. Learn SQL and remove the middleman.
Jest => fair enough I guess, but I wouldn't use rspec when Ruby had minitest out of the box
Caching/Static site => wut? ... wut? there's much more to caching than HTML.
routes.js => probably great on the server, not so much on the browser.
And the best for last...
graphql => not a replacement for REST. You can do more with less by just making your client do the work or going with backend-for-frontends. If you don't understand your network then graphql is an easy vector for DOS (speaking from experience).
Meanwhile I can spin up Laravel, Rails, Spring or Django up and get a solid application running in a fraction of the time while in JS land, client server arch is a seemingly unsolved problem.
I sound bitter but I'm more incredulous. I don't actually enjoy writing for the browser any more, there are too many divergent trends.
Meanwhile I can spin up Laravel, Rails, Spring or Django up and get a solid application running in a fraction of the time while in JS land, client server arch is a seemingly unsolved problem.
This might be a slightly controversial opinion, but I don't think the time it takes to get an application running with a framework is a relevant metric. Being able to get an application up and running fast is only a useful benefit when you're first starting out and trying things. If you're choosing a tech stack and you're going to be working on something for months or years, the fact that you can see something on a screen after an hour or after 3 days is completely insignificant compared to how good it is to work with in the long term.
Choosing a technology because you can start working on a new application quickly is the wrong way of thinking about your tech stack.
I think your post summarizes a major reason why so many people ended up using small frameworks and appreciating glue code after using Rails/Django.
My noob a-ha example is `rails generate devise:install` where I first thought, wow, what a time saver. Eventually I learned lessons like, perhaps authentication is too important to be hiding from your source code. In fact, maybe almost everything is.
I think it's important to learn and understand, absolutely. But a default installation/configuration which both works correctly and is easy to set up is pretty damn valuable.
But a default installation/configuration which both works correctly and is easy to set up is pretty damn valuable.
It can be, especially when you're learning or putting together lots of small projects, but my point is that people over-emphasis the benefit of that feature on a long term project. It might be fine that a framework takes a lot of time and effort to set up before you see any results, and it could actually be a good thing if that initial time means other things about the framework are better.
All other things being equal it'd great to be able to spin up quickly, but things are never really equal between frameworks. So, to me, choosing a tech stack because it's quick to initialise a new project feels like you're optimizing for the wrong thing, and potentially you're making a less optimal choice because of that.
There are a couple of reasons you want a “quickly spun up” framework. First it shows the API is thought through / not complicated. If it takes hours for you to add a basic route the framework was overengineered. The second is hiring. Rarely will you find devs with all the experience you require, so you’ll have to train. Making things overly complicated increases the cost of your devs, increases training time, and generally just slows you down.
So I completely and wholeheartedly disagree. Frameworks should be as simple as they can be.
Or you don't really know the problem space quit yet and an application that helps you get up and running quickly allows you to figure it out in a short amount of time. Maybe you find out that your preferred tech stack is not adequate, at which time you can change it.
> My noob a-ha example is `rails generate devise:install` where I first thought, wow, what a time saver. Eventually I learned lessons like, perhaps authentication is too important to be hiding from your source code. In fact, maybe almost everything is.
You can view the source code of Devise any time you want on its github repo - it's not hiding anywhere.
I think that having authentication code vetted by 100s, if not 1000s of different developers is much better than rolling your own authentication code.
For me it's more nuanced, and I wish I saw more of it.
You make your prototype or fit your product with a rapid dev framework, Rails is pretty much built for that, it doesn't intend to scale beyond it (see Basecamp: they don't pile onto a monolith, they make fresh new versions).
One you get that product fit, your codebase should still be small enough to rebuild it quickly in a more stable language. Java, C#, Go, Rust, whatever... something that gives you better runtime guarantees without requiring bonkers amounts of language hacks so you can spend less time writing unit tests and stubs and mocks.
I’m inclined to agree, but it seems fair to admit that there’s a survivorship bias going on here. My hypothesis is that projects that go on to require years of enhancement and maintenance have survived an initial window of people losing interest or getting distracted by another idea. Projects that demonstrate value within a very short time of their conception are likely to survive this early period.
Im not saying it’s rational to skip three days of early development for months of effort down the line, just that it happens.
> Choosing a technology because you can start working on a new application quickly is the wrong way of thinking about your tech stack.
I think being able to have a default toolbox that will allow you to get up and running quickly so you can find a proof of concept or really start to formalize the problem your app addresses and the solution it provides, along with a quick feedback loop, is very valuable.
> If you don't understand your network then graphql is an easy vector for DOS (speaking from experience).
When GraphQL came out I was quite honestly shocked that this didn’t get more attention. It’s essentially trivial to not notice that a query could cause the server to loop heavily. User > Friends > Friends = easily 10000 results, and that’s the simplest top-of-the-head example I can think of. When an object has even 3 or 4 possible relationships, there are exponentially more attack vectors.
And on a minor note: the fact that objects are returned inline makes a query for duplicates that much larger in KB.
When you would’ve worked with GraphQL, which I assume you didn’t given your comment, you’d know that the design stage of a schema is one of the most important ones. In this case getting friends of friends, one can easily enforce pagination on the results and force a maximum of x friends. Furthermore, it’s not like REST or any other tech is immune to this way of DOSsing the server, however with REST this is just pushed to the client to perform 1+n+n*n queries. So either way, you’ll have to fix that problem.
Now, what does GraphQL _actually_ solve? For one, it gives proper documentation and ability to know what the client(s) are consuming. In turn allows client devs to develop their side much faster and independently from the backend. Where we used to have a lot of back and forth about the design of the api we can now model our interface according to the Business model and not have to accommodate for the limitations of a flatten structure. There are more advantages to GraphQL but it goes too far to elaborate in this comment
Super exciting, I've always believed a Rails-like philosophy of convention-over-configuration and the Javascript ideal of perfectly-tailored customization could supplement rather than compete each other. Redwood looks like a big step toward that, and I think it speaks to the overall growth of the Javascript ecosystem as a whole.
Yeah, almost. That's essentially my current preferred stack already. But "almost" is the key word: sometimes there seems to be some overlapping duplication of functionality, if not necessarily code, and the handoff between Rails-world and Vue-land is still a kind of purgatory which can be solved and navigated with experience and knowledge of the ins-ands-outs of both frameworks / webpack / package management / etc., but it'd be _nice_ if all those options were solved in the first place, rather than having to work to cleanly and sustainably get two frameworks to talk to each other nicely.
Rails didn't load 286 KB of Javascript to display static text and sidebar though.
If you go to https://redwoodjs.com/ right now and disable Javascript on the page, you will get the same amazing fast experience at literally 5-10x less size. The only difference? The sidebar in the tutorial will not display properly.
I'm still not sure that those entry-level frameworks using GraphQL aren't repeating Rails' ActiveRecord issues when it comes to more complex data relationships. Both work alright for "blog post" and "user" entities, but become a bit awkward when it comes to even basic CRM-type examples (contact/company/address/junctions).
I know that Facebook is using this at scale, but that's a whole different issue, with lots of custom optimizations and special backends.
I've heard GraphQL proponents call joins "premature optimization", and I don't even know how to respond to that…
Same, am I the only person that uses inner/right joins? A lot of times I'm not doing it in order to minimize subsequent calls, but rather because the logic of my query depends on being able to do a join.
Obviously my understanding is that at Facebook-scale you're not really able to have the luxury of joins, and have to accomplish your query logic in other ways...but that strikes me as joins being something you have to relinquish if necessary, rather than being a premature optimization.
> I've heard GraphQL proponents call joins "premature optimization", and I don't even know how to respond to that…
These are the same people that build something complaining about 'overengineering' and when they get stuck just end up shutting down and rewriting stuff.
Prisma is definitely limited when it comes to advanced use cases. I have been using it for two years and we are now moving to postgraphile because of this. And Prisma 2 doesn’t help, it makes it worse.
Yes, Prisma allows you to run hand crafted SQL queries. That’s is the bare minimum I would expect from it. Graphile on the other hand allows you to do this AND to systematically generate whole classes of such requests, through plugins.
Hi! One of the Redwood authors here. I'm really excited to launch Redwood today and happy to answer any questions you have about the framework and what makes it special!
This is awesome, congrats! I love Rails but it does seem like nextjs has left it in the dust in terms of making it easy to build simple, performant front-ends in react and there's no official Rails graphql solution yet either. What next is missing is a blessed omakase way to deploy it with a DB.
Can you talk about or point me to docs on the different philosophies between this and nextjs? In particular next already makes bundle optimization, splitting, lazy-fetching and serverless deploys pretty automatic. Why not start with next and work on incorporating the DB/business logic functionality? Related: why Prisma?
Next.js is really great, and has definitely helped push the industry forward. I'm not a fan of the way they handle routing, though, and we need to be able to evolve Redwood without fighting against our dependencies. If I had to guess, we may end up writing our own versions of other things as time goes on. We're all about integration, and sometimes you have to own things yourself to make it all work as seamlessly as possible.
FWIW we use Next.js without the pages folder convention, we use a routes.js and just have the pages folder as a build artefact, then we have relatively seamless integration with Relay to make data management super straightforward.
This is amazing - I'm very much in Django land right now, but I'd love to see a successor that combines all its productivity strengths with the modern world of JS/Typescript-all-the-way-down.
A few questions:
- Do you intend to have strong typing (Typescript) all the way through? Most of the examples seem to be in plain JS. Not that that's a bad place to start, but I have a dream of typing a schema for a new model once and having it immediately typecheck all the way to the frontend code.
- Will there be an ability to automatically generate admin interfaces, form and all, from database schema? Django's ModelAdmin is annoying to customize, but it's unparalleled in getting a GUI together in minutes for a trusted operational team. And React-Hook-Form's support for dynamically generated fields could be really powerful in this regard.
- Both Rails and Django have patterns of "as long as this file is in the right place and/or has the right inheritance hierarchy, I won't need to write boilerplate." Is this a goal of this project as well? For instance, for the service file in https://redwoodjs.com/tutorial/side-quest-how-redwood-works-... seems to be something that would be nearly identical, save for the name of the model, across a number of things. Rather than scaffolding, could there be a way to inherit from a generic superclass (or the functional equivalent), fully overrideable, similar to how https://docs.djangoproject.com/en/3.0/topics/class-based-vie... allows any view to inherit from a ListView or DetailView?
Thanks for the kind words and questions! Others from the team can go into more detail, but here's some high-level for now:
- Typescript is definitely a priority for us. But implementation so far is starting with the backend (see https://github.com/redwoodjs/redwood for current), which isn't inclusive as of yet. We are looking for community involvement here as well.
- Admin interface: ah, very interesting. Could definitely be on the roadmap in the future. We're off to a great start with the Scaffold generator, which uses the schema to create all the pages necessary to run end-to-end CRUD operations on a database table. See https://redwoodjs.com/tutorial/getting-dynamic
- Boilerplate: The short answer is "yes indeed"! It's not 1-to-1 with your example, but there are lots of cases where you'll find this thinking+implementation. Again, the tutorial walkthrough is the best place to see some of this in action.
I really hope your (or a similar) project takes off.
Modern web development desperately needs a framework that integrates well with technologies like SSG, Graphql and Nodejs in general, that ships with sane configuration defaults for all the involved layers.
This is important, since SSG/SPA hybrids solve a lot of frontend issues by default and Graphql is a very expressive protocol which helps to avoid tightly coupled data transformation logic on the frontend.
I'm currently very interested in Nodejs specifically since JS is a transpilation target for a lot of languages and WASM.
I'll keep my fingers crossed, that you find a solution for integrating the persistence layer nicely as well. A simple and reliable DB like SQLite could be a very good default, since now you are essentially just dealing with files.
I think database and ORM integration in a framework like yours is very tricky in general. It has to be flexible enough to serve different needs but also well integrated and easily deployable. Good luck with that!
Looking forward to try this stuff out and possibly provide further feedback.
What level of site complexity do you think would justify using your framework versus a simpler approach? (wordpress with wp2static, for example) Is there a concrete level of interactivity or architecture at which you think a framework like this starts to shine?
We're looking to be a modern replacement for something like Ruby on Rails, so think full-on web application vs a blog or simple eCommerce site. Another way to think about is: do you have a lot of custom business logic you need to implement in order to drive your application? If so, then Redwood is set up really well do deal with that.
Do you intend to have built-in support for user management?
Setting up stuff like Oauth / Okta / etc and handling things like who can access admin screens seems to consume a lot of time on new projects - it'd make for an awesome app platform if some of that was well-supported out of the box.
Totally! We wanted to have a way of doing auth included in the launch but we ran out of time. It's definitely on the roadmap. Our goal is to make it "just work!"
This looks really interesting, I like the focus on developer ergonomics, launching with a fleshed-out tutorial is a nice touch. The deployment story, however, seems to be tied to using Netlify as a hosting platform, which could affect adoption. I understand that that's where the roots of this project lie, are there any plans to decouple Redwood from Netlify to enable the framework to be self-hosted or used with other CI/CDN/FaaS services?
I think it's a natural consequence of new possibilities existing in the JS world. Build tools like webpack, transpilers like Babel, type systems like TypeScript; deployment architectures like JAMstack; all these things mean we can do new and interesting things with code, and developers are excited to explore them. It's a good thing! We want to explore the domain as much as possible to find the best solutions. Eventually you'll see consolidation around a smaller number of the best projects.
Because JS has no standard library and was originally a very light scripting language designed in a few days and used for browser coding.
It has evolved very rapidly as the web grew and these frameworks are a natural outcome of everyone trying to create some order from the chaos and figure out a proper architecture and way to do things.
The good news is you have lots of choices and it runs everywhere. Bad news is the sprawling mess you have to go through to find the good stuff.
If you asked me a few years ago if I could imagine building a framework, let alone a JS one, my answer would've been "hell no!"
But here I am... There was a lot of time spent trying to figure out how to use these technologies, and we're glueing those technologies together with our personal taste.
I'm working on something similar. I hope to pick up some ideas ;)
My project is about helping create more traditional JavaScript applications, not necessarily JAMstack. It is inspired by the Self programming environment created at Sun Microsystems in '95, so it's not a framework per-se, but a combination of a framework, an editor (VS Code plugin) and (in the future) infrastructure.
* it supports TypeScript out of the box
* it provides background processing (via Postgraphile Worker)
* it aims to support only PostgreSQL, so that we could conveniently use all those beautiful PostgreSQL features that are usually «hidden» by ORMs
* I'd also like to make SQL more popular ;)
* there is a bit of inspiration from Clojure
* it favors the function composition, e.g. for handlers
* it comes with a built-in authentication/authorization, which you shouldn't probably use in production just yet
* it is still very alpha
* for the front-end you can use React, but also Vue.js and possibly Angular or Svelte
* and many other things which I haven't yet described in the README as I work on this on the side, mostly alone
There is also fantastic Dark Lang (https://darklang.com/) in the same, quite similar yet different.
The latest update from Next.js [1] seems to cover all that redwoodjs does. In particular, the Static Site Generation portion. Next.js already supports API's in the same monorepo.
Like David said, we currently only help you build a web frontend, but we intend to eventually make it super nice to build a mobile app, desktop client, CLI, etc. All under the redwood umbrella (canopy?).
The difference is that Next.js is very unopinionated. GraphQL, Prisma, SQL – these are opinionated choices from Redwood and largely the point of the framework.
I like rails, but in js world may be not so good idea to reimplement or integrate everything related to ui, routing etc. Meteor.js was not very successful with this model. I think routing or UI on react-native/web/blessed/VR is too different to be part of one framework.
But I see the usefulness of framework with functionality related to data fetching and business logic.
I consider perfect stack for this things is Postgress->Hasura (or also Prisma)->mst-gql->mobx-state-tree. You create database schema and everything up to models on client is autogenerated and each part of this stack could be updated, customized or completely rewritten. This stack could be used on react-native or web or any other js platform.
If I remember correctly, React was only part of it. Lack of support for relational databases was a big issue as well. On top of that, people realized that they didn't need real time functionality and the overhead (and scaling) of mini-mongo et al was a difficult venture. Take with a grain of salt. This was all very long ago so my memory may not be accurate.
At first I thought "oh great, this looks very nice but why does it exist when Next.js, Gatsby, etc. are already a thing?"
Then I saw Tom Preston-Werner's involvement and my interest level raised considerably. I'm still not sure if there's a market for this per se, but the bone-fides of the dev team is certainly a good sign.
Redwood started as an experiment, and we'll see where it goes, but my intuition is that it will fill a need that many React developers currently have (namely: the lack of integrated solutions to all the technologies available in the ecosystem). It's certainly something that I want!
Quite tightly at this point, as really nice integration is a primary goal. That said, it’s not impossible that another rendering layer could be used, but it’s not our focus right now.
I appreciate the focus. React might not be everyone’s choice but what the JS world is missing is super tight integration between multiple tools. We forgot everything Rails taught us. People who want to pick their own technologies already have the ability to do so today, what’s missing is one off-the-shelf convention-over-configuration solution to be the Rails of JavaScript.
This was my first thought too. I much prefer Vue so would love it if you could choose the client side layer.
Not taking anything at all away from this, it looks awesome and I can’t wait to give it a try. I get that this is an opinionated framework and the effort to achieve multi client side options is likely pretty high. I’m also conscious that releasing something and have people say “I want it to be different” straight away is annoying so really trying not to be ‘that guy’.
Knowing the js community, someone is probably already working on it anyway.
Loving the innovation in this space!
> At first I thought "oh great, this looks very nice but why does it exist when Next.js, Gatsby, etc. are already a thing?"
I honestly will never understand why people say things like this. As though there's no room for progress. As though there aren't alternatives that may or may not be better. Imagine if the folks building React thought "ya know, we got Angular, so why are we doing this?"... Or any of the many, many other similar scenarios. It's how we make progress.
> Then I saw Tom Preston-Werner's involvement and my interest level raised considerably.
I would have agreed with you already until I read the above sentence. Having a famous programmer isn't really a great reason or argument to adopt yet another N + 1 web frameworks. Sure, some have reasons to exist but appealing to authority is hardly any valid reason here.
Even that aside, if everyone were to adopt this by the time it reaches v1.0, someone will complain via writing a Medium blog-post and introduce another web framework on top of Redwood or introduce some other improvement for Redwood but as a fork of the project rather than a contribution back to Redwood.
> appealing to authority is hardly any valid reason here
It's about competence.
Would you not have increased confidence in an NBA team after hearing Stephen Curry had joined it after the previous season? I think you'd be highly irrational not to.
For better or worse (or better in this case, I believe), I don’t know the famous dude. I won’t tell you my bonafides, either.
If you’ve got someone with a particular skill set joining your project, that’s great that you’ve got strong, additional perspective in that domain. However, this isn’t a sixty minute game, and no one is getting paid millions to hit a game winning shot. This is open source software.
I hope as an industry we learn to drop the theatrics and recognize our unique way of bringing value to whichever projects we contribute to.
Well, he made Gravatar, Jekyll, TOML and quite a few other open source things I've used.
Accuse me of "theatrics" if you like, but I am in fact inclined to check out projects made by people who have made other things I like. I also read books written by people who have written other books I like. I watch movies with directors and actors from other movies I like, too!
It's not a sure-fire guarantee I'll like the next thing but odds are considerably improved. Not updating my priors when learning of their involvement would be ridiculous.
Just want to chime in that I think this looks very promising but I would really want to see full TypeScript support before I picked it up. In particular what would be a killer feature for me would be sharing model types between api and web sides. This is something currently possible (using e.g. lerna) but not trivial to setup for my smaller projects, and if it was a feature of Redwood I'd seriously considering switching my tech stack for future and possibly current projects.
Will be watching it with great interest. Good luck!
While prisma2 is probably the best node ORM, it still has a lot of issues. It seems to take a lot of inspiration from the mongo api, which is a good idea, as that is the one thing mongo got right. There are a bunch of issues with it though:
It should be closer to the mongo api.
await prisma.users.findOne({ where: { id: 1 } })
should just be
await prisma.users.findOne({ id: 1 })
for example.
It is trying to do too much. There is a hard limit of where ORMs try to take over too many of the things you do in SQL and become slow and complex and a big black hole. prisma tries to do migrations, table creation, etc, etc. These things rarely work properly.
Lazy loading never works. Somewhere litered in your code you access a field that is outside the scope of the pulled in data and it is in a loop and suddenly you have 100 requests. You have to look through your entire function to understand which fields are inside and outside of the scope of the query, and add more includes or whatever.
There are security issues with ORMs that traverse and save relationships, as github itself found out. You add user__roles form field maliciously on the client side to a form that was just supposed to update the user and not the roles, then suddenly you find your user.save() method on the server-side has traversed and added new roles to a user.
I am writing a kind of orm today based on the mongo api without all the $ signs, much like prisma, but closer and without all the additional things. github username is thebinarysearchtree.
ORMS should just be for fairly simple, single table tasks. That way they get out of the road and don't become some big complex thing that ruins performance and adds its own complexity.
You should check out the .NET platform with ASP.NET framework and Entity Framework ORM. It's the gold standard when it comes to these tools and has none of the issues you mentioned. There's even Blazor now to for frontend UI powered by WebAssembly or server-side websocket connection.
> It seems to take a lot of inspiration from the mongo api
That's an interesting comment but I'm not sure it's quite accurate. I think where we're taking quite a bit of inspiration from MongoDB is the idea of "thinking in objects" because this is much closer to the mental model developers have when they work with data. We are currently already working on an improved API of Prisma Client [1] that looks less like MongoDB but should feel a lot more ergonomic.
Regarding your example of removing the `where` from a `findOne` call. In this case it's needed because you can also select/include [2] fields and/or relations:
> There is a hard limit of where ORMs try to take over too many of the things you do in SQL and become slow and complex and a big black hole.
I just want to stress that Prisma is not an ORM! ORMs are characterized by the fact that classes are mapped to tables and you have complex model instances that carry logic for storage, retrieval, serialization, deserialization and often custom business logic. Prisma does none of that! It provides an auto-generated and fully type-safe database client that's tailored to your database schema. Any data you'll ever retrieve is fully typed and comes in the form of plain old JS objects that a are easy to reason about.
> prisma tries to do migrations, table creation, etc, etc. These things rarely work properly.
I'd love to learn more about where you think Prisma's migrations approach falls short! IMHO moving towards a dclarative migration system based on an intuitive data modelling language is much closer to how developers are thinking about their data than using SQL migrations. One of our users once described it like this:
"What Prisma does for migrations is essentially what React does for rendering. A user need only describe the current state, but not the operations to get to that state. So, thank you for doing this to databases as React (and others) has for UIs!"
> Lazy loading never works. Somewhere litered in your code you access a field that is outside the scope of the pulled in data and it is in a loop and suddenly you have 100 requests.
Do you mind elaborating how/where you see this problem happening in Prisma?
> There are security issues with ORMs that traverse and save relationships, as github itself found out.
Again, Prisma is not an ORM and I have a hard time seeing how this applies to it.
> ORMS should just be for fairly simple, single table tasks. That way they get out of the road and don't become some big complex thing that ruins performance and adds its own complexity.
I fully agree with this poinit and it's one of the core desiign goals of Prisma. If you feel Prisma doesn't achieve this, we're doing something wrong...
All that being said, I really appreciate your thoughts and feedback and would love to see you in the Prisma Slack [3] and sharing your thoughts in our GitHub issues.
Reading about it, I realized I've built stuff like this for a long time. I built websites with Hugo and other static HTML generators before that, adding React components to make some pages dynamic and calling into an API for some of the user interaction. The simplest case of this was a contact form in React which posted to /api/contact, a simple Ruby server which sent emails.
Some "dynamic" server side content was also easily included in a cronjob. That way I fetched the Twitter feed of a few accounts and rendered this into the static HTML.
I did it, because it was really fast to build, could scale, development and deployment was easy for the HTML, etc.
What I didn't had at the time was FaaS and I think the architecture could benefit from this. I had Docker containers running the API and the reverse proxy needed to do some routing, so I still had a server running, but I didn't need a database. I had to teach the marketing department how to write Markdown in GitLab editors, though.
congrats on the launch! I've been hoping for someone to make a "Rails for JS" for a long time, with the performance capabilities of JAMstack apps (prebuilt, served from CDN). This is a peek into the future!
as a React dev as well, I particularly like the integration of GraphQL into the Cell format. This will work especially well with render-as-you-fetch React Suspense. I think if you throw in scoped css you'll have the ultimate vision of the React Single File Component format.[1]
Thanks! I was very nervous about how people would receive the concept of Cells, but people seem to like it, and we'll improve the implementation!
I personally love styled-components and I had tighter integration with it in the start, but we decided to not be opinionated about CSS frameworks... That may change ;)
Is there a plan for how backend jobs would work in this "Rails for the Javascript age"?
I find that JAMstack is great until the need for recurring or out-of-band processes comes up. In Rails of course there are jobs that can be backed by Sidekiq or what have you, and additionally on a VM one can always set up a cron job to invoke some Rails tasks.
For JAMstack there is no clear alternative, as far as I can see. Manually setting up a recurring lambda function (granted, I have not yet done it) seems to be annoying enough that I would rather just deal with a VM instead.
This link will set up an automatically scheduled script / endpoint you can deploy in a click. Disclaimer; I built a lot of it. (Founder.) Warning is that there's a signup wall right now but it is free to use. Based on feedback we might be removing the signup wall at some point just so more people can check it out.
I'm previously the author of Nodal [1], a Node.js API framework that had quite a bit of early popularity -- we transitioned to building Standard Library [2] to focus on easily building APIs and combining them for simple backend workflows / integrations. Fits with JAMStack pretty well, generally, and our users aren't just developers; it's accessible to business users as well, provided they don't mind learning a little code. :)
Not using JAMstack, but I did set up recurring lambda functions and it's dead simple. It's a few clicks in the web console, of course you'll want some provisioning/deployment that's more solid than "click in the web console", but it's still probably way easier (and exposes way surface for bugs) than managing an entire server
My understanding is JAM stack refers to mostly the frontend, being a statically generated site, and talks to server via API, but doesn't dictate anything about your API server or server side jobs, etc. You can still run serverless/lambdas, or actual backend API servers, or whatever else you want to do.
I guess Redwood's model is a little more than JAM stack, since "Rails" for JS would imply it does a lot more than the JAM part, and that's what it looks like on the site.
We are stretching the definition of "JAMstack" here. But the primarily intended emphasis is not just React+API -- it's making structure+design choices that target serverless infrastructure out of the box. It's not perfect and we have a ways to go, but being able to deploy fully serverless is what RedwoodJS is all about.
Your understanding is accurate. We do plan to support pre-rendering on a route-by-route basis, which will perhaps be more inline with what JAMstack tends to mean today. But Redwood is still all about JavaScript (client) and APIs (backend), with markup to follow, as I just mentioned. But more than that, it's about the development and deployment philosophy of JAMstack that we fully embrace.
> "We are working on full end-to-end TypeScript support for Redwood, all they way from the DB schema definition to the frontend and back via GraphQL. It's in the works!" - Tom Preston-Werner (https://twitter.com/mojombo/status/1237474978825564162)
Yes! Our intention is to support TypeScript as a first-class citizen in Redwood apps (while still supporting JavaScript as well). We're currently working to make sure all of the framework code is written in TypeScript.
I think this looks interesting, and I applaud the team.
That said... am I the only one that thinks that anything that is JS based seems ridiculously complicated to use? I don’t do much UI work, but any time I look at using react or similar it feels like there are a lot of moving parts and a lot of steps to perform before you can even get started on something useful.
Eh, I feel like that's any web framework in any language. Take Django for instance. If you're doing a very boilerplate project, then it's pretty slick. But as soon as you start trying to do any customization you go down a rabbithole of subclasses and mixins, where looking at the source is usually more helpful than the documentation.
I think the reality is web applications stand on the shoulders of lots of giants. We're only able to get anything done thanks to abstraction that someone else did for us. We still have a need to see below the surface occasionally, though, and finding the balance between readability and customizability is an eternal struggle. Plus, everyone has their preferences: I hated Angular at first because of its steep learning curve, and now love it for its strictness.
I guess my feeling comes from spending time with opinionated frameworks like Rails. There are sane defaults and you’re up and running quickly. Any time I look at something like React or similar, the instructions for getting started are written like “If you’re using yarn, do this. If you’re using grunt, do this other thing”. I don’t have either, so now I have to choose one before I can proceed. Instead, I just close the browser tab and go on to something else.
I currently work on a codebase that is in part React based, and I have no idea how to get it running from scratch or how data flows through. It seems asinine.
hi, just reading through the tutorial and want to say, it's quite enjoyable and beautiful to read. Personally I feel and many would agree that docs and tutorials deserve equal if not more effort for tools that are aimed at making our lives easier. Please keep making the docs stronger.
Thanks for noticing our hard work! We spent a LOT of time making sure the tutorial was rock solid and very clear. We will continue investing time into making the tutorial and our docs even better!
> For now, you need to set up your own database, but we are working with various infrastructure providers to make this process simpler and more JAMstacky.
I recently stepped through this tutorial, which does somthing similar, and uses FaunaDB - turned out pretty nicely.
Glad to see more batteries-included solutions to frontend development. In particular, I'm glad to see you've addressed a lot of the pain points with building a fullstack application with React: Forms, lack of "laravel artisan-like" CLI generators, integrating GraphQL (and picking between one of the many server and client-side libraries/frameworks).
I only had time for a brief look through it but searching for "redux" and "state" didn't bring up anything; do you have an opinionated approach to global state management?
Keen to check this out when I have more time this week!
Nice work! And a good project page. One thing: there's a concept used but not introduced, which, at least to me, does not ring a bell... What's "SDL" in the context of Redwood?
Ah. Thanks for clarifying, maybe im not the only one a little confused. I'd call 'm "GraphQL schemas (SDL)" on the landing page to avoid confusion for some visitors.
Congrats on the release, you've certainly done a great job documenting it and creating a great webpage. Hope I will put my hands on it soon.
One question, is the React app being pre-rendered at all before being stored on the CDN? If not, how does it qualifies as a JAMstack project? If the React app is being completely rendered on client side, then I don't see any difference with a regular Next.js (without generating a static site) project but I certainly see lots of differences with Gatsby for example.
We are currently not doing any pre-rendering, but it's on the roadmap to enable pre-rendering on a route-by-route basis. Even so, Redwood is still JAMstack because it's JavaScript, APIs, and Markup; it's just that we're delivering the entire client via JavaScript, and the API is our entire backend. Our goal is to let you build a full-stack web app but still deploy in the JAMstack style. We're pushing the boundaries of JAMstack intentionally!
This is incredibly ambitious: every subheading on the landing page, such as form validation & handling, routing, service logic, is enough to have many big libraries already working on the problem. Yet here's this thing that says here it's all wrapped up in one solution. Historically, Vue has more than demonstrated that well opinionated whole solutions can be very popular on the frontend too so it's interesting to follow where Redwood will end up.
I'm on the opposite side - maybe thanks to Docker I got lazy or something but when I don't see docker (or even better - ready to use docker-compose file with whole required stack prepared) then I think I'm like 10 times less eager to give it try.
While this looks great I'm having trouble fitting it to any of the projects I'm already working on.
We already have all those pieces in place, along with the ability of swapping any one piece with a different one; say, if we wanted to go RESTful we only need to swap one block.
It does look gorgeous tho; how would one go about gradually adopting it?
As a fully integrated framework solution, it may be hard to gradually adopt Redwood, and that's ok. If you already have a setup you like, and it gives you the flexibility that you need, then that's awesome! I want Redwood to be around for the majority of devs that don't already have a sweet setup going, and are lamenting the endless hours of choosing, setup, and integration ahead of them just to get something started.
First things first, thank you very much for the fast response!
It's very true that all the prepwork is pretty costly, hence my eagerness to try and adopt random bits and pieces even at this stage; it might end up saving us time down the line haha
While I have you around... what would be a good toy to build with this? Our megalithic, business rules heavy app sounds like a potential good fit for the Redwood, but it's entirely too large a bite to tease our engineering leads with.
The further from the metal you are the harder it will become to do even the most simple of things. In this case, the code will be "compiled" up to ten times before it hits the metal. And every time some information will be lost, and unnecessary extra instructions will be added. / Debbie Downer
Nice to see the JS ecosystem taking this route: fullstack frameworks.
Just like Next.js was built for zeit/now, redwood was built for Netlify.
Since Top Prester-Werner (Author) is in the board of Netlify this makes sense. But is it a good idea for frameworks to be tied to specific deployment platforms? Unsure, we’ll see!
While Redwood is currently optimized for deployment on Netlify, it is by no means restricted to that environment. Our intention is for Redwood apps to be deployable to a variety of JAMstack providers in addition to traditional serverful setups. My main interest is in providing an integrated, joy-inducing experience for app developers that want to leverage the full awesomeness of modern JavaScript and friends. It's true that if Netlify wins, I win too, but I'd rather DEVELOPERS win, and that's what keeps me motivated.
Really big fan of everything in this stack; I've been building my product on React/Apollo/Prisma/Postgres and it's been a pleasure. It's nice to see a well-thought-out architecture added to the process. Great work.
Interesting the documentation uses the term "generators" to refer to scaffolding tools. I read that word and got excited that they had python-esque generators.
I'm personally in the same boat (and use a philosophically similar JS-based framework called SailsJS instead, right now)
For me: I need services that support the UI, as well as a public-facing API with basically the same data. I don't have the time/resources to build/maintain them separately, and my perception is that GraphQL and the wider ecosystem around it haven't yet reached the same level of ubiquity/maturity as plain-old REST.
A single, well-designed REST API that can be consumed by my own UI as well as public clients is how I'd prefer to handle it right now.
Would have to agree. GraphQL is kind of a non-starter for every project I've worked on in the past few years, and a GraphQL ONLY framework is right out.
Unfortunately, no. Cloudflare workers are heavily restricted in what they can do, both from an outbound request and compute time perspective. If those restrictions are reduced, it’s possible we could make it work someday. It sure would be awesome!
next is primarily focused on the rendering layer, capable over static, server, and serverless rendering. it makes it easy to set up api routes but doesnt have any opinions whatsoever on data layer.
redwood is full-stack, has an opinion on graphql/prisma as part of your data layer, integrated into Cells for declarative loading states. its still super early days but you can feasibly view it as doing the same thing Rails does in terms of organizing and picking techs for you for all parts of a stack, including setting up scaffolding for you.
Edit: The twitter thread from the author is a great summary of Redwood and its benefits https://twitter.com/mojombo/status/1237441122097487873