This group’s mission is to enable Frontend developers to build, deploy and manage externally facing, static websites using Jamstack architecture in a simple, configurable and scalable way.
Frontend engineers should be able to use GitLab as the primary place to manage Jamstack Frontends.
Technology supporting Jamstack is a fast-growing, highly innovating field with many startups competing for market shares.
GitLab’s solution is built on GitLab Pages and its solid CI/CD pipelines. This allows any client to grow seamlessly from a simple static site to complex, multi-faceted deployments without having to change the provider at any point. Competing in the Jamstack market potentially allows new Developers to have a shallow entry to GitLab’s CI/CD world. That is, if we get the User Experience right.
GitLab is not an infrastructure provider. This is an advantage for established clients that may already pay for their own infrastructure. GitLab can easily support a wide range of infrastructure using CI/CD pipelines, so our goal is to make this as simple as possible. It’s important that this scalability is conveyed from the very first onboarding steps to build trust with our users, even if most projects will stay small.
User survey
In January 2023 we conducted a User survey to provide data on the general direction around the Javascript runtime feature.
Jobs to be done
When I’m building a simple static site, I want to publish it without leaving the GitLab UI, so I can update faster and with fewer points of failure
When I’m building a server-side-rendered static site (SSR), I want to use GitLab to deploy, so that I don’t have to configure and pay other services to do so
When I’m deploying a Pages site, I want to have it distributed via a CDN so that the page is delivered faster
Maturity: 0% Status: planned
When I manage my own GitLab instance or group, I want to connect my own CDN account for Pages, so that developers can deploy static sites through a CDN without additional configuration
Maturity: 0% Status: planned
When I’m developing a Jamstack site, I want to create a simple CRUD API, so that I can save time on repetitive, boilerplate tasks
Maturity: 0% Status: planned
When I create a simple CRUD API through the GitLab UI, I want to export the API code into a repository so that I can continue development manually
These are the guiding principles that the Jamstack SEG optimizes its
implementations for.
Simplicity - It should be intuitive to use GitLab to deploy a static site. GitLab should be a great place to just get started with the confidence that deployments can be fine-tuned and scaled later.
Configurability - With the .gitlab-ci.yaml powering the solution, it should be straightforward to support a wide range of deployment strategies.
Scalability - GitLab should be able to support the entire page’s lifecycle. From a quick-and-dirty one-man project to powering the websites of high-traffic global organizations with complex infrastructure needs.
Backstory
The key to modern Jamstack Frontends are Websites built as Single Page Applications (SPA). Classic Javascript Frameworks like React or Vue.js build the entire HTML DOM on the client side, so to improve performance, they are supplemented by Rendering Engines (eg. Next.js, Nuxt.js) that use node.js to pre-render HTML before they are sent to the client’s browser. Frameworks like Eleventy, Gatsby.js or Hugo are both Framework and Rendering Engine.
All frameworks have in common that there are three main approaches as to when the rendering happens:
During Build time, also known as Static Site Generation (SSG), this is how GitLab Pages works now.
When a page is Requested, but instead of rendering in the client’s browser, the page is pre-rendered by the server, known as Server Side Rendering (SSR)
A mix of both, where pages are dynamically rendered once when requested for the first time, then cached, also known as Incremental Static Regeneration (ISR). This is usually supplemented with a step that pre-renders the most popular pages during build.
in January 2023 the Jamstack SEG conducted a user survey to identify the communities’ priorities around creating a Javascript runtime capability for GitLab.
This came at a time where I was making similar progress with both of the following work tracks:
a Cloudflare Workers Integration using the Cloudflare API
a V8 Javascript runtime integration into GitLab Pages directly
Both of these tracks will eventually result in users being able to run server-side Javascript functions without actually needing to deploy a server.
Both implementations come with large opportunities and risks, so I needed to factor in our user’s priorities. This is why many results are interpreted with that goal in mind.
Survey respondents
The survey was filled by 38 respondents, primarily Frontend- and Fullstack developers.
