Redwood: An integrated, full-stack, JavaScript web framework for the JAMstack

[sytse]

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

Edit: The twitter thread from the author is a great summary of Redwood and its benefits https://twitter.com/mojombo/status/1237441122097487873

[mhd]

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…

[ralusek]

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.

[WrtCdEvrydy]

> 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.

[crubier]

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.

[mojombo]

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!

[zaiste]

Congrats on the launch, Tom & the team!

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.

The project is called Huncwot: https://github.com/huncwotjs/huncwot

* 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.

[mojombo]

Cool! I'll take a look and see if there are any ideas we can pick up from YOU! I love that so much area is being explored in the JS world right now.

[techpeace]

Just checked Huncwot out - looks like a great project, thanks!

And congrats to mojombo and team! You probably already use something Tom wrote without realizing it.

[Zaheer]

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.

[1] https://nextjs.org/blog/next-9-3

[yatsyk]

Next is limited to browsers and doesn't prescribe how you access data. I would compare redwood to meteor.js but not next.js.

[leerob]

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.

[yatsyk]

Congratulation on launching!

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.

[dpacmittal]

Because react killed it and by the time meteor switched to react from blaze lot of people had moved on.

[jaredcwhite]

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.

[mojombo]

Thanks for the kind words!

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!

[joekrill]

> 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.

[rvz]

> 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.

Here we go again.

[davedx]

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!

[pistoriusp]

Thanks!

We'll definitely support Typescript, we're almost there and will make the experience feel amazing.

The boundary between the API and WEB sides is GraphQL and we're looking at making the schema typing available on the WEB side.

We're using yarn workspaces!

[rienbdj]

This is pretty easy to do with yarn workspaces

[tehin]

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.

[manigandham]

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.

[sbr464]

I didn't see your project on the github user profile you mentioned? Was curious.

[nikolasburk]

Nikolas from the Prisma team here!

> 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:

    await prisma.users.findOne({ 
      where: { id: 1 },
      include: { posts: true }
    })

But we're aware that the API is quite verbose at times, so we're already working on slimming it down. Here's the proposal from the new API spec:

    await prisma.users.findOne(1).load({ include: { posts: true } })

> 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.

[1] https://github.com/prisma/specs/issues/356

[2] https://github.com/prisma/prisma2/blob/master/docs/prisma-cl...

[3] https://slack.prisma.io

[rmetzler]

Please excuse my ignorance, what is JAMstack? I couldn't find an explanation on the landing page or the README.md.

[undefined-1]

JavaScript, APIs, and Markup.

https://jamstack.org/

[bryanrasmussen]

When I go to https://jamstack.org/ the title element is <title>Jamstack | JavaScript, APIs, and Markup</title>

so, I guess that's good. I was afraid the M was going to be Meteor.

[swyx]

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]

1: https://www.swyx.io/writing/react-distros/#what-other-react-...

[pistoriusp]

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 ;)

[gnalck]

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.

[keithwhor]

If you're interested in setting up easy scheduled functions, I can recommend checking out Autocode:

https://autocode.stdlib.com/new/?event=scheduler.daily&event...

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. :)

[1] https://github.com/keithwhor/nodal

[2] https://stdlib.com/

[williamdclt]

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

[godot]

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.

[k__]

As far as I know, at least GitHub actions can be triggered with a interval/cron.

[pistoriusp]

My personal hope is that your hosting provider would offer a solution that's configurable during deployment.

Then we could undoubtedly abstract this into something and deal with it at deploy time.

[chvid]

Great presentation.

I took a look at the example:

https://github.com/redwoodjs/example-blog

As I understand "JAM Stack" the point of the M is to have large chunks of your application pre-rendered.

However in this example; the blog pages are client-side rendered based on a graphql query that goes into postgres database.

Am I missing the point of this? It looks like a standard rich-client with API backend architecture.

[mojombo]

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.

[miguelmota]

Surprised to see it not written in TypeScript since TS helps immensely with large projects

https://github.com/redwoodjs/redwood

[mtm7]

> "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)

[chaostheory]

Typescript support? Javascript is just too hard for larger projects.

[mojombo]

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.

[sandGorgon]

this is very interesting. nextjs gives a lot of this : for example

- frontend and backend in the same code https://nextjs.org/docs/api-routes/introduction

- graphql based - https://github.com/zeit/next.js/tree/canary/examples/api-rou...

- hybrid static page support - https://nextjs.org/blog/next-9-3#next-gen-static-site-genera...

- jest - https://github.com/zeit/next.js/tree/canary/examples/with-je...

- CMS providers - https://nextjs.org/blog/next-9-3#collaboration-with-cms-prov...

- pretty url routing - https://github.com/zeit/next.js/tree/canary/examples/with-pr...

[larrywright]

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.

[robertakarobin]

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.

[brailsafe]

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.

[beardedman]

Nice!

Building any "Rails for JS" idea is a huge undertaking, purely from the sheer scope of the Javascript (inc. NodeJS) ecosystem.

[spamalot159]

Congrats on the launch. Looks interesting coming from rails stack. I hope you guys can develop a good community around this.

[frequentnapper]

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.

[mojombo]

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!