DEV Community

Cover image for redwoodJS - the universal deployment machine

redwoodJS - the universal deployment machine

ajcwebdev profile image anthony-campolo Updated on ・8 min read

Fullstack web application development is the next evolution of Jamstack. That becomes a primary place that you would deploy a fullstack web application, and that’s what RedwoodJS is about.

Tom Preston-Werner - Redwood brings fullstack to the Jamstack (March 12, 2020)


RedwoodJS is a fullstack, serverless web application framework for building and deploying Jamstack applications. Imagine:

  • React frontend
  • Statically delivered by CDN
  • Talking via GraphQL to backend
  • Backend running on AWS Lambdas
  • All deployable with git push

Alt Text

Redwood Philosophies

  • There is power in standards about which tech to use, how to organize code into files, and how to name things
  • Relational databases like PostgreSQL and MySQL are still the workhorses of today's web apps
  • Operate in a serverless mindset and deploy to a generic computational grid
  • To deploy your application, you should only need to commit and push to your Git repository
  • Scaling from zero to thousands of users should not require your intervention
  • Useful for simple, toy applications and complex, mission-critical applications
  • JavaScript is the primary language on frontend and backend

Universal Deployment Machine

My dream of a future is for something I call a universal deployment machine, which means I write my code. It's all text. I just write text.

Then I commit to GitHub. Then it's picked up and it's deployed into reality. That's it. That's the whole thing. That's what I want. That's what I've been looking for.

Tom Preston Warner - RedwoodJS Shoptalk (May 11, 2020)

Fullstack React

There has recently been a sudden influx of different projects aiming to build a Full Stack React framework. What are people talking about when they say full stack react and why is it suddenly such a hot topic? A long running emphasis throughout the history of React has been its identification as a library instead of a framework. The one-liner for React has always been a JavaScript library for building user interfaces.

It unapologetically focused on the view layer and did not seek to provide strong conventions around routing, server rendering, static site generation, or database integration. Instead projects like React Router, Relay, and Redux were created to solve some of these problems while remaining their own separate codebases. In contrast Nextjs and Gatsby built conventions on top of React.

As React has continued to maintain its popularity in JavaScript development there has been an increasing sentiment among some developers that the need for a true full stack React solution was greater than ever. Developers that cut their teeth on projects like Rails, Ember, and Laravel are especially adamant that the tendency for React developers to create their own bespoke architectures is counterproductive and costly.

Adam Wathan and Michael Chan have been long time advocates of this perspective. I became interested in this topic in March when I listened to their conversation React Is Not a Rails Competitor on Full Stack Radio.


Jekyll is a simple, blog aware, static site generator.

Tom Preston-Werner - Blogging Like a Hacker (November 17, 2008)

In 2008, Tom Preston-Werner published a blog post titled “Blogging Like a Hacker,” which told his story of blogging, programming, and his eventual invention of Jekyll. Jekyll was a reaction against complicated blog engines like WordPress.

His constraints included the ability to style his own blog and host it on the domain of his choosing. This eliminated and He mentioned that some people use GitHub as a blog but he considered that an impedance mismatch.


He decided to approach blogging from a software developers perspective. His writing would be stored in a Git repository and published via a deploy script or post-commit hook. A static site would be preferable to a dynamic site to keep complexity at a minimum. The blog would need to be easily customizable.

Jekyll works by:

  1. Taking a template directory representing the raw form of a website
  2. Running it through Textile and Liquid converters
  3. Spiting out a complete, static website
  4. Serving with Apache or similar web server


I was tired of having my blog posts end up in a database off on some remote server. That is backwards. I’ve lost valuable posts that way. I want to author my posts locally in Textile or Markdown.

My blog should be easily stylable and customizable any way I please. It should take care of creating a feed for me. And most of all, my site should be stored on GitHub so that I never lose data again.

Tom Preston-Werner - tpw README (October 20, 2008)

Numerous projects influenced by Jekyll appeared in the following years.

  • Thomas Reynolds created Middleman, a static site generator utilizing Haml and Sass in 2009
  • Alexis Metaireau created Pelican, a Python project that converts static text files into html sites in 2010
  • Tommy Chen created Hexo, a blog framework powered by Node.js in 2012
  • Jeff Escalante created Roots, a static site compiler written in CoffeeScript, in 2012
  • Steve Francia created Hugo, a static site generator written in Go in 2013



There are those who describe Netlify as “GitHub Pages on Steroids”. If that’s the case then Hugo on Netlify must be digging into Lance Armstrong’s stash.

Mathias Biilmann - Hosting Hugo on Netlify (July 30, 2015)

In 2014, Mathias Biilmann Christensen created, a leaderboard of top open-source static site generators. It uses a variety of metrics including GitHub stars, forks, and twitter followers to rank different static site generators.

Around that time Mathias was running MakerLoop, a content management startup based in San Francisco. He believed that Git-centered workflows with static site generators like Jekyll represented a massive change in the web development space. This lead to Mathias co-founding Netlify with his childhood friend Christian Bach. Tom Preston-Werner was an early investor in Netlify.


Gatsby was created by Kyle Mathews in 2015. It started as a static site generator built with React, but as the project grew it no longer functioned as simply a static site generator, and Kyle found the term to be ill fitting to the project.

Gatsby incorporated GraphQL and increasingly used sophisticated 3rd party APIs to perform various dynamic tasks that could not be achieved with older static site generators. Other projects appeared that were influenced by Gatsby including Gridsome and Scully.

This new paradigm started to be referred to as the JAMstack, as in JavaScript, APIs, and Markup. Mathias credits Andreas Sæbjørnsen with first coining the term. Recently there has been a push to refer to it simply as Jamstack in an attempt to distance itself from the original acronym (see JAMstack vs. Jamstack by Chris Coyier). The Jam has been slowly spreading ever since.



It's 2012, I get hired into AWS and it's my first day there. And my boss Alyssa Henry, who at that time is running all of storage, so S3, EBS, like the whole storage division for AWS sits me down at lunch and says,

"Okay, Tim, so here's the deal. We heard from customers that they love S3. It's simple, it's easy to use. It's a different kind of way of thinking about the cloud. They love all of that, but it's just a storage solution, right? There's no way to ... Let's say you store an image, there is no way to make a thumbnail of it.

You pull out a compressed file, there's no easy way to decompress it on the fly, plus the other million things developers might want to do with the stuff they're storing in here. They've told us this in customer advisory meetings and one on ones, see if he can do something with that. Okay. I'm busy, got to run. Good luck!"

This is day one for me at AWS. This is literally my very first conversation coming out of the sort of onboarding and signing all the paperwork. So I'm like, okay:

  • Grow a business in the cloud
  • Make it easy
  • Think about S3 as a kind of inspiration.

We had to make the cloud as easy for someone who does applications and business logic as it is for someone with a PhD in distributed systems. And that's when we realized there was some there, there. And we got excited about that. We came up with this idea for event hookup and we were kind of off to the races.

Tim Wagner - The Past, Present, and Future of Serverless (June 8, 2020)

Serverless is a made up buzz word that is also commonly used to refer to Functions-as-a-Service cloud products like AWS Lambda, Azure Functions, and Google Cloud Functions.

The basic premise is that instead of paying for a server to always be running and ready to respond to incoming requests, you pay based on the specific number of function calls invoked in your app from those events.


It was pioneered by Tim Wagner’s team at Amazon Web Services in 2012 and has become a popular paradigm for “cloud native” applications, which are applications designed specifically to run on a platform such as AWS, Azure, GCP, Digital Ocean, Render, or Begin.





Log Output


Tim Wagner served as general manager for Lambda, API Gateway, and the Serverless Application Repository.

The computers would handle a number of problems concurrently. Organizations would have input-output equipment installed on their own premises and would buy time on the computer much the same way that the average household buys power and water from utility companies.

W. F. Bauer - Computer design from the programmer's viewpoint (1958)

It has much in common philosophically with Multics and other time-sharing systems of the 1960s.


In 2015 the Serverless Framework open source project was released, and eventually lead to the creation of a company called Serverless, Inc. This successfully confused everyone about the meaning of the term serverless to an even greater degree than before.


In reference to the term, Serverless founder Austen Collins claimed it was, "not technically accurate."

Discussion (0)

Forem Open with the Forem app