Stackery Serverless Platform Adds JAMstack Support – InApps 2022

Serverless development platform provider Stackery has introduced support for the JAMstack web development pattern, which relies primarily on JavaScript, APIs, and Markdown (JAM) to deliver scalable web content at a greater speed via content delivery networks (CDNs).

Technically, there is nothing strictly limiting developers from using serverless functions in the place of JavaScript. For Stackery, the idea of serverless here not only includes the idea of functions as a service, but also the ability to pull together managed services via APIs, much as JAMstack does. In this context, those functions are simply yet another managed service that can be accessed via an HTTP API, and keeping with the JAMstack approach in spirit — the developer has no backend, no web server, no traditional LAMP stack to manage.

In a blog post introducing the new functionality, Ryan Coleman, vice president of engineering at Stackery, notes that “this style of web development fits well with serverless architectures,” a point which he expanded upon in an interview with InApps.

“We’re seeing people reaching for serverless for all those speed and security and pay-by-consumption benefits that serverless provides, and I’m seeing people pulling into JAMstack for those same reasons. It’s a very complimentary mindset in terms of the architecture for how you’re building these apps,” said Coleman. “I see this space, this convergence of serverless style managed services and the JAMstack style of web architecture, as being a huge tool for the enterprise to dramatically rethink, ‘How are we going to win this race? How are we going to protect our customers’ data, provide good user experiences, do that in a way that engages our developers and allows them to be more productive than ever?’ My bet is that this intersection is where that’s going to go.”

Some of the essential aspects of the JAMstack pattern include the decoupling of client and server, and the pre-building of content before runtime and delivery. Stackery’s approach to serverless, wherein it provides an abstraction layer on top of Amazon Web Services, makes the services easier to connect and treat as discrete services. Coleman said it was when they saw some users going toward combining AWS’ backend services with its CDN CloudFront that they started to wonder what was going on.

“These customers were building JAMstacks. They weren’t really calling them that, but that’s what they were doing,” said Coleman. “They were building these rich web experiences, but they were expressing most of the hard infrastructure in Stackery and then they were trying to link out to Netlify or these other services, who would do that last mile of building their web application, delivering it to a CDN, and maybe connecting it to some lambda functions.”

With this update, Stackery helps integrate a user’s various AWS services directly into their CI/CD pipeline, which then assists with the integration with the static-site generator for build. For users interested in testing out JAMstack support, Stackery has created a tutorial that will “guide you through the process of deploying and hosting a Ghost CMS with Gatsby frontend using the serverless approach.” Stackery’s support for JAMstack includes the addition of the website resource, which helps to simplify the build process for static site generators like Gatsby, and the addition of this to its virtual whiteboard.

Currently, and as Coleman notes in his blog post, with the JAMstack methodology, “the static app is continuously built and delivered to a CDN origin like an S3 bucket on every commit.” While the automation here is desirable, he sees this as the point where the next level of innovation will come, with these static site generators offering a way to reduce inevitably long build times.

“When it comes to each of these individual frameworks, how do you get to a point where you can build an enterprise web application, where you get all the benefits that we just talked about, but without the long build times?” said Coleman. “One of the big downsides of this sort of architectural approach is that every time you make a change to your website, every one of these frameworks goes through the whole process from scratch; it pulls in your source code, it interacts with all these third party APIs, and then it builds every single web page and then delivers those. There’s a lot of work going on in this space where each of these frameworks is building in tools to understand which content changed from the back end perspective, and then offer the ability for platforms like us to use that information to do a much faster build cycle.”

Amazon Web Services is a sponsor of InApps.

Feature image by mac231 from Pixabay