Software generated entirely by AI is not an hypothetical future — it's a reality today. I don't think it's an overstatement to say that this is the largest shift in the history of this industry, unravelling before our eyes at an astonishing pace.

As a professional software engineer, I've been closely watching this change and taking my time to gather my thoughts on what this means for my profession and for the world. This is my first shot at putting those into words.

¶ A question of identity

Over 20 years ago, before my personality and view of the world were even fully formed, I came across something that would change my life forever: I started writing code. For the 13-year old me, programming had absolutely nothing to do with career aspirations or entrepreneurship — it was the raw joy of solving a puzzle, of pushing myself to learn something new, of bending a machine to my will and make it materialise an idea that didn't exist anywhere in the universe other than in my own imagination.

Since that day, I've been on an incessant journey to master this thing that feels equal parts science, art and witchcraft. I went to school and university for it; I made it my profession; I travelled the world and moved countries because of it; it gave me countless friends and memories that I cherish.

More than something I do, writing code is a big part of who I am.

¶ Preemptive nostalgia

I take joy from different aspects of writing code on a daily basis: writing some tests and seeing them pass for the first time, dissecting the root cause of a gnarly bug, or coming up with an elegant solution for a seemingly impossible problem (and always patting myself on the back for it).

The realisation that computers can now perform these tasks in a fraction of the time it takes me is unsettling. It's impossible not to ask: will AI replace me?

Unlike the 13-year-old me, I no longer view programming as just a puzzle. As I honed the craft of being a software engineer, I developed other skills. I learned how to connect with people from different disciplines and translate their needs into technical requirements; how to solve problems in alignment with the vision and strategy of an organisation; how to balance competing priorities and adapt plans accordingly; and how to coach team members while promoting a culture of growth and knowledge sharing.

The emotional part of me feels a deep sense of preemptive nostalgia about something dear that is about to change forever

My work reflects the sum of every problem I've solved as a human throughout my life, and I don't think AI will replace that just yet.

But there are aspects of my job that will likely change forever. As computers start writing more of the code, I expect the moments of joy I mentioned earlier to become few and far between.

The emotional part of me feels a deep sense of preemptive nostalgia about something dear that is about to change forever, whereas my rational side sees this shift as a normal cycle of evolution and adaptation — and trusts that I'll be able to find that joy in new places.

¶ Looking at the bigger picture

As I let those feelings simmer, I wanted to take a step back and look at software as more than just something that I enjoy creating; it can also be a force for good with a profound impact on people’s lives.

Case in point: software that helps patients with chronic diseases. Healthy bodies have an incredibly powerful device — the pancreas — that takes care of continuously producing the right amount of a hormone called insulin, which converts sugars from food into the energy that powers the body. It’s a vital process.

People with type 1 diabetes saw their pancreas failing abruptly and unexpectedly at some point in their lives. To stay alive, they must take on the role that their pancreas once had and administer that insulin themselves. It's hard to overstate how difficult it is to figure out the right amount of insulin to take and when to take it, multiple times a day, every single day.

Technology can't solve this, but it sure can help. Nightscout is a web-based Continuous Glucose Monitor (CGM). It's open-source software that allows patients and their caregivers to view glucose data in real time, and to receive alarms for abnormally high or low blood sugar values. These alarms save lives.

The Open Artificial Pancreas System (OpenAPS) is an open-source project that connects a small computer to a CGM and an insulin pump, automating the delivery of insulin to patients, mimicking to some degree what the pancreas would normally do. One third of people using OpenAPS are children, for whom managing blood sugar levels is especially challenging.

These are just a couple of examples of how community-built software can make a real, positive impact in people's lives. There are many other examples like this that apply to different conditions and situations — this is the story that hits closest to home for me, because as a type 1 diabetes patient I've experienced this impact firsthand.

As I zoomed out from my own experience and focused on programming as a means to achieve a larger goal, I began to ask myself how AI might push that even further.

¶ The creator's funnel

I kept thinking about these amazing projects and started wondering how they came to life; how the seed of an idea actually materialised into something positive for the world. Every project is different, but I think the process can be broadly broken down into the following phases:

1. Identify: Identify a problem worth solving or an opportunity worth chasing
2. Conceptualise: Plan and shape a viable solution to address the problem
3. Build: Execute the plan and turn the idea into something real and functional
4. Distribute: Get it into people's hands

For example, you might identify the pain of managing type 1 diabetes, conceptualise an interface that lets patients access glucose data with ease, build an application that shows that data in real time and provides alerts on abnormal values and, finally, distribute it as a web application.

But these phases don't form a linear path that every creator follows in the same way; they're more like a funnel, where fewer and fewer ideas reach the next stage of the journey. Not everyone who can identify a problem is able to conceptualise a solution; not everyone who can conceptualise a solution has the skills or the means to build it; and not everyone who manages to build a product knows how to distribute it.

This means that the amazing projects we see today don't represent all the creators, the ideas, or the potential out there — they're just the ones that made it through the creator's funnel. A classic case of survivorship bias.

By reducing the distance from idea to reality, we have a unique opportunity to harness more human ingenuity than ever before.

What if AI can completely disrupt this? It's now possible to generate a fully working application simply by describing what it should look like and what it should do. No technical background, no budget, no need to assemble a cross-disciplinary team just to prove an idea. Within minutes — not days, weeks, or months — anyone can prompt their idea into existence.

AI has the power to transform this funnel into a portal that everyone can walk through, democratising access to resources that were once completely unattainable for millions of creators with life-changing ideas waiting to be uncovered. By reducing the distance from idea to reality, we have a unique opportunity to harness more human ingenuity than ever before.

¶ Parting thoughts

We're collectively embarking on a journey with no clear idea of where it leads. Yes, my job will change in ways I still do not fully understand and some parts of it that I've grown to love may not be around for long.

But I realised that by focusing on the small pleasures of writing code, I was missing the forest for the trees.

I've been working in the developer tooling space for over a decade. I fell in love with the idea of building for developers, of lowering the barrier of entry for tools and technologies that empower them to do their best work.

What better example of that than enabling millions of creators to add their voices to the conversation?

Computer scientists, hackers, tinkerers, and vibe coders: it doesn't matter where you come from, I'm just excited to see what you build.

Picking the technology stack for a project is an important and consequential decision. In the enterprise space in particular, it often involves a multi-year commitment with long-lasting implications on the roadmap of the project, the pace of its development, the quality of the deliverables, and even the ability to assemble and maintain a happy team.

The open-source software model is a fundamental answer to this. By using software that is developed in the open, anyone is free to extend it or modify it in whatever way fits their use case. More crucially, the portability of open-source software gives developers and organisations the freedom to move their infrastructure between different providers without fear of getting locked in to a specific vendor.

This is the expectation with Next.js, an open-source web development framework created and governed by Vercel, a cloud provider that offers managed hosting of Next.js as a service.

There is nothing wrong with a company profiting from an open-source software it created, especially when that helps fund the development of the project. In fact, there are plenty of examples of that model working successfully in our industry.

But I think that can only work sustainably if the boundaries between the company and the open-source project are abundantly clear, with well-defined expectations between the maintainers, the hosting providers and the users about how and where each feature of the framework can be used.

I want to explain why I don't think this transparency exists today.

My goal is not to stop anyone from using Next.js, but to lay out as much information as possible so developers and businesses can make an informed decision about their technology stack.

¶ Declaration of interest

Let me lead with a declaration of interest:

• I work at Netlify and have done so for over four years
• Netlify is a frontend cloud platform that supports Next.js and other web frameworks as part of its product offering
• Netlify and Vercel are direct competitors

It's important for me to establish this for a few reasons.

My job involves building the infrastructure and tooling needed to support the full feature set of Next.js on Netlify, which has exposed me to the internals of the framework in a way that most people won't see. Over the years, I have seen concerning patterns of tight coupling between the open-source framework and the infrastructure of the company that builds it.

My employment is also the reason why I have always been very wary of voicing these concerns in public. As a Netlify employee, I don't really get to voice an objective concern about Next.js without people dismissing my claims as Netlify unleashing one of its minions to spread FUD about a competitor.

I'm not keen on exposing myself and the company to that type of debate, so I have always chosen to work behind the scenes in supporting the developers who decide to deploy their sites on Netlify and shield them from all the complexity that goes into making that possible.

But then something happened.

Last weekend, Vercel disclosed a critical security vulnerability with Next.js. This type of issue is normal, but the way Vercel chose to handle it was so poor, reckless and disrespectful to the community that it has exacerbated my concerns about the governance of the project.

For me, things change once your decisions put other people at risk, so I felt the urge to speak up.

¶ Openness and governance

I'll come back to this incident later, but before that I want to back up a little and give you a peek behind the curtain. My history of reservations about the openness and governance of Next.js stem from a series of decisions made by Vercel over the years that make it incredibly challenging for other providers to support the full feature set of the framework.

I'll cover these by laying out a series of facts about how Next.js is built. I'll then add some of my own considerations about how those facts live up to the expectations of an open, interoperable, enterprise-grade software product.

¶ Fact #1: No adapters

Most modern web development frameworks use the concept of adapters to configure the output of the framework to a specific deployment target: Remix, Astro, Nuxt, SvelteKit and Gatsby are just a few examples. This pattern allows developers to keep the core of their applications untouched, and simply swap the adapter if they decide to start deploying to a different provider.

These adapters can be maintained by framework authors, by the hosting providers, by the community, or all of the above. Frameworks are typically structured in such a way that it’s possible for anyone to build their own adapter in case one isn’t available for the provider of their choice.

Next.js does not have the concept of adapters and they have stated in the past that they would not support them. The output of a Next.js build has a proprietary and undocumented format that is used in Vercel deployments to provision the infrastructure needed to power the application.

Vercel's alternative to this was the Build Output API, a documented specification for the output format of frameworks who wish to deploy to Vercel.

This is not an adapter interface for Next.js, and in fact has nothing to do with Next.js. The announcement blog post said that Next.js supports this format, but as of today that isn’t true.

In November 2023, the Next.js documentation has been updated to say that Next.js would adopt the Build Output API in the following major version of the framework (which would be version 15):

Next.js produces a standard deployment output used by managed and self-hosted Next.js. This ensures all features are supported across both methods of deployment. In the next major version, we will be transforming this output into our Build Output API specification.

Next.js 15.0.0 was released in October 2024 without support for the Build Output API.

Vercel have built the Build Output API because they wanted their customers to leverage the rich ecosystem of frameworks in the space, but their own framework doesn't support it to this day.

This means that any hosting providers other than Vercel must build on top of undocumented APIs that can introduce unannounced breaking changes in minor or patch releases. (And they have.)

Late last year, Cloudflare and Netlify have joined OpenNext, a movement of different cloud providers that collaborate on open-source adapters for Next.js. Shortly after, Vercel have engaged with the movement and committed to building support for adapters. They haven't made any timeline commitments, but have recently said they are actively working on it.

It's important to remember that it's been almost three years since the launch of the Build Output API, and to this day the framework still isn't portable. I'm cautiously optimistic about that actually changing this time.

¶ Fact #2: No official serverless support

The official methods for self-hosting Next.js require running the application in a stateful way, as long-running servers. While technically possible, this is very hard to operate in any real-world production environment where a single instance isn’t sufficient.

The setup needs to be able to dynamically scale up very quickly in order to handle sudden bursts of traffic, while at the same time being able to scale down to zero in order to be cost-effective. This last part is essential when working with server components, for example, where the deep tangling between client and server code can break older clients unless every version of the server code ever deployed is available indefinitely.

One obvious answer to these requirements is serverless computing, as attested by official Next.js documentation that confirms the benefits of this model:

Serverless allows for distributed points of failure, infinite scalability, and is incredibly affordable with a "pay for what you use" model.

This clearly advantageous computing paradigm is precisely how Vercel has run Next.js sites in their own infrastructure for years. Given that Next.js is an open framework, it is reasonable to expect that you'd be able to use that same model in any serverless provider of your choice. But it's not that simple.

Next.js once had a serverless mode that you could enable with a configuration property, but it was removed without further explanation in October 2022. No equivalent mode was ever introduced.

The official React documentation, which the Next.js team help maintain, says that Next.js can be deployed to «any serverless hosting», but there is no official documentation whatsoever for this.

This means that any providers who want to offer support for Next.js with the same computing model that the framework itself promotes must reverse-engineer their way to a custom implementation.

¶ Fact #3: Vercel-specific code paths

Next.js has code paths that are only ever executed for sites deployed to Vercel. An example of this is a private flag called minimal mode, which allows Vercel to shift work away from the framework and run it on their edge infrastructure.

Here's an example of why that matters. Next 12 introduced middleware, a way to address use cases such as feature flags, A/B tests and advanced routing. What's common in all of these use cases is the need to run logic on the hot path, behind the cache, with very low latency.

The announcement included this:

This works out of the box using next start, as well as on Edge platforms like Vercel, which use Edge Middleware.

In practice, this means that you have two options: use next start and run middleware alongside the rest of your application in your origin server (which is typically running in a single region, after the cache), or use one of the «Edge platforms like Vercel» to run middleware at the edge, before the cache, unlocking all the incredible use cases that Vercel boasted in the resources linked in the announcement.

The phrase «Edge platforms like Vercel» surely means that there are many alternatives out there because other providers were given the option to also implement middleware at the edge, right? No.

This secret minimal mode is what allowed Vercel to break out middleware from the rest of the application so they could run it at the edge, but only Vercel has access to it.

Netlify does support running middleware at the edge, but we've done it at the expense of having a full team of engineers dedicated to reverse-engineering the framework and building our own edge middleware implementation on top of undocumented APIs. This type of commitment is just impossible for smaller companies that simply do not have the resources to fight this battle, which makes most of them stop trying.

As far as I know, Netlify is the only cloud provider to support the full feature set of Next.js outside of Vercel, which doesn't make sense to me. With Next.js having such a sizeable share of the market, I would expect a lot more hosting options, which would foster competition and innovation across the board, ultimately benefitting users and the web.

So why is there a hidden door in Next.js for which only Vercel holds the key? I think it's expected that the framework maintainers regularly experiment with features before they're launched, but minimal mode isn't that. We're talking about an entirely different operation mode for the framework, which has been in the code base for many years and which unlocks capabilities that are reserved for the for-profit company that owns the framework.

If WordPress had a privileged code path that was only accessible to sites deployed to Automattic properties, would it be trusted as a truly open project and would it have the dominance it has today?

¶ Security posture

Let's go back to the security incident. On Friday, March 21st at 10:17 AM (UTC), Vercel published a CVE for a critical security incident, ranked with a severity of 9.1 out of 10.

In essence, it was possible for anyone to completely bypass Next.js middleware by sending a specific header in the request. This is important because authentication was one of the flagship use cases of middleware, and this exploit meant that anyone could bypass the authentication layer and gain access to protected resources.

As the incident unravelled, a few things became apparent. First of all, the vulnerability was reported to the Next.js team on February 27th, but it wasn't until March 14th that the team started looking into it. Once they did, they started pushing fixes for Next 14 and Next 15 within a couple of hours.

So by March 14th (at the latest), Vercel knew they had a serious incident on their hands. The responsible thing to do at that point would be to immediately disclose the vulnerability to other providers, so that they could assess the impact to their own customers and take any necessary actions to protect them as quickly as possible. At times like these, our duty to protect users should rise above any competition between companies.

That is not what happened. It took Vercel 8 (eight) days to reach out to Netlify. In that time, they managed to push patches to Next.js, cut two releases, and even write a blog post that framed the incident as something that Vercel's firewall had «proactively protected» their customers from (even though their CTO later said that their firewall had nothing to do with it).

I think it's incredibly disingenuous to spin a critical security vulnerability in your open-source project as a strength of your product, with absolutely no consideration for whether users in other providers were also affected and what they should do to mitigate. In fact, they wouldn't even know this, because they hadn't even reached out to us at this point.

After being called out on social media, Vercel have rewritten the blog post to remove any mention of their firewall and clarify which providers had been affected and whether their customers had to take any action.

Vercel has then released a postmortem where they said — for the first time — that on March 21st they were able to «verify Netlify and Cloudflare Workers were not impacted». This is directly contradicted by their staff reaching out to Netlify on March 22nd offering help to «get a patch up». If we were not impacted, what was there to patch?

This lack of consideration for any users outside of Vercel has created unnecessary anxiety and confusion for a lot of people, leaving some providers scrambling to find a solution and then having to partially roll it back, others announcing that they were not vulnerable when in reality they were, etc.

As you read this, it's impossible for anyone to know how many sites out there are still vulnerable to this exploit, many of which would've been safe if things were handled differently.

And at the height of all this mess, Vercel's leadership had... a different focus.

¶ But Vercel owns Next.js

They do. And they have every right to make a business out of the framework that they've put so much work, talent, time and energy into building and growing. I'm not disputing that.

But that growth holds them to a high bar of standards that, in my opinion, they have repeatedly failed to meet.

«If Vercel own Next.js, what incentive do they have to open it up to other providers?» is a question I sometimes see and which I find intriguing. What incentives does Redis have for opening up their software when they own Redis Cloud? Why make Grafana open when Grafana Cloud is owned by the same company? Or WordPress, ClickHouse and many others?

The incentive is that they have to do those things if they choose to publish their software as open-source and not as a closed, proprietary solution. Their success is intrinsically associated with their users having the guarantee that they are free to choose whatever provider offers the service that meets their needs at any given time.

¶ Wrapping up

It's not my business to say which framework you should use. If you like Next.js and you still think it's the best tool for the problem you need to solve, you should absolutely use it. But I hope that this information helps you feel more confident about your decision, whichever way you're leaning.

As for me, I'll keep doing my job to help support the developers who chose to deploy their sites to Netlify, whatever their framework of choice is. And competition aside, I'm genuinely looking forward to help Vercel make Next.js more open and interoperable through the OpenNext movement.

Update (2025-03-26): Added a note about Vercel's most recent postmortem.

Update (2025-03-28): Vercel have committed «to not introduce any new privileged code paths and to either remove or fully document the ones that exist today, such as minimal mode». As for timelines, they are «hoping to get it done this year».

Update (2025-04-23): I have submitted a PR to fix incorrect information about Next.js deployment options in the React documentation.

Update (2026-03-26): Next.js 16.2 added a stable Adapter API.

Runtimes like Node.js rely on a package manager and a registry to install and distribute modules, but Deno has a different spin. It allows developers to import modules directly from a URL, which can be hosted on a CDN, your own server, or really anywhere on the web.

This level of flexibility brings infinite options, so I started looking for the best workflow to release modules in this new paradigm. This article describes the solution I landed on — one that works for solo open-source developers or large development teams in the enterprise world.

Here's the gist of it:

• The source code lives in a GitHub repository
• Releases are automated using a combination of Conventional Commits and Release Please
• The repository is connected to a Netlify site, which is responsible for serving the modules in version-locked URLs, protecting private modules, serving documentation pages, and a few other niceties

Let's get started.

¶ Setting up

The first step is to create a GitHub repository with a few things:

• A JavaScript or TypeScript entry point for the module. This is the file that people will import into their applications.
• A workflow file for Release Please, which will automate the release process using GitHub Actions.
• A Netlify Build Plugin for generating redirects to version-locked URLs.
• A Netlify configuration file, setting the right directories, build command, and response headers.

Next, we connect the repository to Netlify.

Alternatively, you can use the button below to create everything with one click.

Finally, we can change the site name to something a bit more memorable. You can do this by going to Site settings > General > Change site_name. I picked deno-greeter.

We're now ready to use the module in a Deno program.

$ deno repl --eval "import { greet } from 'https://deno-greeter.netlify.app/mod.ts'"
Download https://deno-greeter.netlify.app/mod.ts
Download https://deno-greeter.netlify.app/greetings.ts
Deno 1.24.3
exit using ctrl+d or close()
> greet("Jane")
"Good morning, Jane!"
>

¶ Versioning

We could start using our module as is, but we're missing an important part: versioning.

If we want to release a new version that introduces breaking changes, consumers should be able to decide whether and when to update their code.

Unlike Node.js, Deno does not use a package.json file to pin dependencies to specific versions. Instead, the import URLs themselves are expected to point to an immutable version of the module. When the code changes, the URL must also change.

We can achieve this pretty easily with Netlify, as you can configure your site to create a new deploy when a new Git tag is published. If we then configure Release Please to create a new tag for every release, we'll get distinct URLs for each new version of the module.

To do this, open the Netlify dashboard and navigate to Site settings > Build & deploy > Branches and select All.

To test the release flow, make some changes to the module code, push a commit using the feat: prefix, and open a pull request. Once you merge it, Release Please will create a release pull request automatically. Merging it will complete the release.

If you go to the Deploys page of the Netlify dashboard, you'll see a new deploy in progress. Once it finishes, you'll see that deno-greeter is available at https://deno-greeter.netlify.app/1.0.0/mod.ts — this is an immutable URL that points to version 1.0.0 of the module, and will be unaffected by future versions.

This process will happen automatically for every new pull request that you merge. New versions of the module will respect Semantic Versioning and will be inferred automatically from the Conventional Commits convention prefixes used in your commits:

• fix: will generate a patch version
• feat: will trigger a minor version
• feat!: signals a major version with breaking changes

¶ Private modules

The current setup works great for public modules, but you might want to restrict access to our module to people with the right credentials. This is a very common scenario in an enterprise setting, where teams of developers want to share common pieces of proprietary code without making it accessible to the outside world.

To do this, we can leverage Netlify's password protection feature. We start by creating a _headers file in the src directory with the following contents.

/*
  Basic-Auth: janedoe:supersecret123

This protects your site with a username and password combination, leveraing basic HTTP authentication.

To use the module in their applications, consumers must set a DENO_AUTH_TOKENS environment variable with the right credentials when running Deno CLI commands.

DENO_AUTH_TOKENS=janedoe:supersecret123@deno-greeter.netlify.app

You can read more about private modules in Deno and explore more advanced authentication mechanisms offered by Netlify.

¶ Documentation site

Using a full-fledged website deployment platform to host your modules comes with a few extra perks. For example, if you want to create a documentation site for your project, you don't need any additional configuration or tooling. You can place the HTML files in the src directory and Netlify will serve them on the same URL.

If you want to something like Docusaurus to build your docs, or even a full-fledged web framework like Gatsby or Next.js, you totally can.

And because the site is deployed alongside the module's code, they will be versioned together. So if someone is using version 1.0.0 of your module, they can find the documentation for that specific version at https://deno-greeter.netlify.app/1.0.0.

¶ Hosted version

Because we're using a Netlify site, we have a series of primitives at our disposal, including Edge Functions.

Edge functions are themselves based on Deno, so we can easily write one that imports our module and uses it to produce a response to an HTTP call. This lets us create a hosted version of our module, which applications can interact with by issuing an HTTP request rather than an in-memory import.

This can work as an alternative interface for applications that are using another JavaScript runtime or a different programming language entirely.

import { greet } from "../../src/mod.ts";
export default async (req: Request) => {
  const url = new URL(req.url);
  const name = url.searchParams.get("name");
  const greeting = greet(name);
  return new Response(greeting);
}

By deploying this edge function, deno-greeter can be accessed at https://deno-greeter.netlify.app/api?name=Jane.

¶ Parting thoughts

This is admittedly not be the most impartial technical piece ever, since I work at Netlify. I did honestly start from the premise of finding the best workflow for me, which I decided to share. So while there are many options out there, I struggled to find one that packs this much functionality with such simplicity.

With the «this is not a Netlify marketing piece» caveat out of the way, I would love to hear about the workflow that works for you. If you end up using the same as mine, definitely hit me up!

At Netlify, we use a diverse set of technologies, languages and paradigms to build our product. Along with Ruby, Go, Rust and others, we write quite a bit of JavaScript. All flavors of it.

My team is responsible for several mission-critical Node.js services: the Netlify CLI, the build system and the serverless function bundler are just a few examples. Despite the sheer number of repositories we maintain, and especially considering that some of them are open-source projects with daily contributions from the community, you might be surprised to learn that our team is relatively small.

I lifted the curtain on the tools and processes that we rely on to make this happen.

In 2016, I started working on a tool to fill the gap in user-generated content on (what is now called) the Jamstack: Staticman. Since then, the entire ecosystem has grown by leaps and bounds, offering developers a set of tools and primitives that were mostly unreachable just four years ago.

In this post, we'll use one of those primitives – serverless functions – to deploy Staticman without having to get anywhere near infrastructure configuration. In particular, I'll show you how to deploy an Eleventy blog with Staticman-powered comments with just a few clicks.

¶ TL;DR

Head to the Eleventy blog template and click Deploy to Netlify.

¶ A brief history

When Staticman was first released, it consisted of a Node application with an included web server. There was a free public instance available for anyone to use, but that wasn't a sustainable proposition for an open-source project (because money), so eventually people had to venture into deploying the application themselves.

As much as services like Heroku absorb much of the complexity involved in this, it's still by no means a straightforward process, especially for less technical folks.

With serverless computing power getting more accessible and more intrinsically connected to the Jamstack paradigm, it makes perfect sense to rethink the way Staticman is deployed. Rather than relying on a centralised, multi-tenant service, we can wrap Staticman as a serverless function that lives alongside – and gets deployed with – our site.

¶ Prior art

Before anything else, I want to point out that I was not the first one to explore this approach. Folks like Prabashwara Seneviratne and Jordan Patterson have done a tremendous job at creating content and tooling around the idea of a serverless Staticman.

I've simply restructured the application to make this use case more convenient and performant.

¶ Going serverless

While it's still possible to run Staticman as a regular Node server, the core application has been isolated and is now published as a separate module, which can be easily included as part of a serverless function without the unnecessary weight of the unnecessary server-related logic.

Staticman was initially built as a multi-tenant service, where one instance could serve an unknown set of repositories. The ability to run one Staticman instance for each site allows for some interesting optimisations.

For one, we can store site-specific configurations within the application, for in-memory access – this saves us a round-trip to the Git provider to retrieve the configuration data.

Secondly, we avoid all the complexity around asymmetric key encryption, which was the only way to guarantee a secure communication between the server and any number of guest sites. Now, any sensitive information can be stored in environment variables that will be exposed to the serverless function.

¶ See it in action

I've forked the Base Blog starter for the Eleventy static site generator and added a commenting system powered by Staticman.

You can deploy it to a free Netlify site with just a few clicks, with all the Staticman configuration being taken care of automatically for you. Here's how:

1. Go to https://github.com/eduardoboucas/eleventy-blog-staticman and click on Deploy to Netlify

2. You'll be redirected to Netlify, where you can connect your GitHub account if you haven't done so before

3. Fill in the following details:

   • GitHub access token: A GitHub Personal Access Token used by Staticman to push new comments to your repository on your behalf. See this guide on how to create one.

   • Repository name: The name of your GitHub repository, including your username or organization (e.g. eduardoboucas/eleventy-blog-staticman).

   • reCAPTCHA site key and reCAPTCHA site secret: If you want to use reCAPTCHA to protect your form against spam attacks, you should insert your site key and secret, which you can obtain here. If you don't want to use reCAPTCHA, you can leave these blank.

4. Done! 🎉

Every time you submit a comment, a new file will be pushed to the repository, which will trigger a Netlify build with the updated content.

¶ Configuration

You can tweak the Staticman instance by changing the configuration object.

For example, if you'd like new entries to generate a pull request for your approval, as opposed to a direct commit to your main branch, you can set moderation: true. This is also where you'd configure which fields are allowed and whether some of them are required.

To see all possible configuration options, check the Staticman documentation.

¶ Parting words

I sincerely hope that this simplified setup flow lowers the barrier of entry for Staticman, allowing many more developers to build amazing projects with pure Git-based user-generated content (like Dave's Splashed).

The features described in this post still have fresh paint – if you run into any issues, or if you have any feedback whatsoever, let me know.

I was a guest on episode #11 of Smashing Magazine's podcast. I had the opportunity to chat with Drew McLellan about Sourcebit and how it can help developers connect any datasource to their JAMstack sites. Have a listen!

Our lives are constantly flooded with information destined from the digital world: the sound of a Slack message on the laptop, a WhatsApp message popping up on the watch, or the email push notifications making our phones buzz incessantly. The screens we surround ourselves with are little black holes that are constantly teasing us with a snippet of information, knowing that we can't avoid getting sucked in to see more.

For a while, I've been toying with the idea of building a physical device that could sit peacefully in my living space and convey important information about a select part of my digital life in a minimalistic, non-obtrusive way. Something with a visual language so simple that I would be able to process a message immediately, without having to stop what I'm doing to parse and make sense of pixels on a screen.

A few years back, I completely fell in love with the Paper Signals experiment from Google. A cute little arrow pointing up or down, or an umbrella opening and closing is exactly the kind of simplicity I wanted.

This idea stayed at the back of my mind for a long time, and a few months ago I decided to build my own Internet-connected physical device.

¶ A traffic light

I created a list of ideas and possible formats, based on capabilities and hardware requirements. In the end, the winner was... a traffic light.

For one, it communicates in a language that is pretty much universal (albeit with some regional variations). And, most notably, the language is much more flexible than we give it credit for – the lights are usually associated with road traffic, but the different colours can convey an infinite number of meanings when placed in different contexts.

¶ Shopping and assembling

I started doing some research into electronics and hardware. My traffic light would consist of a Raspberry Pi Zero W, a $10 computer not much larger than a ping-pong ball, and three LED lights.

As for the enclosure, I designed it in a vector graphics editor and had it 3D-printed and shipped to me. That was a nerve-racking process, because I didn't know if I had messed something up until I ordered a print and waited a few days for it to arrive at my doorstep. (It's like not being able to test your code until you deploy it to production. Yikes!)

After a failed enclosure design, after reading up on Ohm's law, LEDs and resistors, and after ruining a soldering iron (don't ask), I finally managed to piece everything together and assemble my traffic light. Yay!

¶ Writing the software

With the hardware in place, it was time to write the software for remote-controlling the state of the lights.

I wanted the device to be connected to the web and controllable via HTTP calls to a public URL. This way, I could easily integrate the device with any platform that supports webhooks.

The Raspberry Pi Zero W has built-in Wi-Fi, which made it a breeze to connect it to my home network and to the Internet, but exposing a public web server is a whole other story. I wanted to be able to plug it into any network and not have to worry about redirecting ports on the router, creating firewall rules and that sort of thing.

Eventually, I decided to create a Node.js app (the client) that I would install on the device, and a central API that I would host on the cloud. This API would then communicate with the client via WebSocket, which uses a single TCP connection for two-way communication and eliminates the issue of being behind a router or firewall.

I've open-sourced the code for the API and client, in case you're interested in having a look.

¶ Integration with Netlify

At this point, I had a public URL that I could ping to set the state of the lights. Now, the sky was the limit!

I'm interested in monitoring the builds on my site, which is hosted on Netlify. Luckily, they have support for webhooks in their Deploy notifications, which lets you configure a set of URLs to hit when a build starts, succeeds or fails.

You can see the device in action in the video below. As soon as I start a build, the amber light turns on; it'll then turn green if the build succeeds or red if it fails.

Netlify is just one of a million possible integrations. I had it hooked up to Travis CI for a while, tracking the build state of a project. You could integrate it with your email provider or Slack account, showing you information about unread emails or direct messages. Maybe you could plug it into your Google Calendar account, to give you an idea of how busy you are for the day.

The possibilities are endless.

¶ Wrapping up

This was a super exciting weekend project and I actually had bigger plans for it. The idea was to improve the software and create an open-source ecosystem of devices, designed and produced by independent makers. People would be able to build integrations, submit designs and order devices online.

Unfortunately, I never got around to working on it, but I still ended up with a pretty neat little device that I can integrate with anything on the web. That's cool.

If you write JavaScript applications, you probably find yourself having to read and write data structures to local files or remote APIs, which means you're probably good friends with JSON.stringify and JSON.parse. We should really get to know our friends, so let's talk about something these methods do that you may not be familiar with.

Writing an object to disk or sending it over the network involves converting it to a sequence of characters such that it can be converted back to its original format and restore all its properties when needed. This is called serialisation and deserialisation.

You can choose any format you like for serialising and deserialising JavaScript objects, but JSON (JavaScript Object Notation) is a likely candidate since support for it is baked into the language – JSON.stringify() for serialisation and JSON.parse() for deserialisation.

So, let's look at a simple JavaScript object and run a simple test: we'll serialise it into a variable, deserialise that variable and then check that the resulting value contains the same structure and properties as the original object.

var original = {
  name: 'John Doe',
  yearOfBirth: 1988
}
var serialized = JSON.stringify(original)
var deserialized = JSON.parse(serialized)
console.log(
  original.name === deserialized.name &&
  original.yearOfBirth === deserialized.yearOfBirth
)
// > true

Sure enough, it works. But what if we add more exotic values to the mix?

JSON has support for 6 data types: strings, numbers, booleans, null, objects and arrays. What happens if we try to serialise a value of a different type, say a regular expression?

var original = {
  email: /^j(ohn){0,1}(\.){0,1}doe@example.com$/,
  name: 'John Doe',
  yearOfBirth: 1988
}
console.log(original.email.test('john.doe@example.com'))
// > true
console.log(original.email.test('jdoe@example.com'))
// > true
console.log(original.email.test('jdoe@example.org'))
// > false
var serialized = JSON.stringify(original)
var deserialized = JSON.parse(serialized)
console.log(deserialized.email.test('john.doe@example.com'))
// > "TypeError: deserialized.email.test is not a function
console.log(deserialized.email)
// > {}

What happened here?

You see, JSON.stringify doesn't know how to serialise a regular expression, so it writes it as an empty object. When we run the serialised value through JSON.parse, the email property will contain an empty object without any reference to the regular expression that existed in the original object. That's why calling the .test() method on it will throw an error.

¶ Custom (de)serialisation method

JSON.stringify allows us to supply a custom serialisation method, which specifies the format and shape with which a value is serialised. We can write a method that checks for regular expressions and encodes them in our own custom representation, as long as that representation is made up of built-in JSON types only.

For example, let's represent the regular expression /foo/i as ["<<REGEX", "/foo/i", "REGEX>>"] – this is an array of strings, so we're now only using types that can be natively serialised to JSON.

This only works if we make the deserialisation method aware of this notation. It needs to be on the lookout for arrays with 3 elements that begin and end with those special strings we came up with. When it finds one, it knows it represents a regular expression so it can extract the expression from it.

Here's the final code:

function deserialize(key, value) {
  if (
    Array.isArray(value) &&
    value.length === 3 &&
    value[0] === '<<REGEXP' &&
    value[2] === 'REGEXP>>'
  ) {
    let [, exp, flags] = value[1].match(/\/(.*)\/(.*)?/)
    return new RegExp(exp, flags || '')
  }
  return value
}
function serializer(key, value) {
  if (value instanceof RegExp) {
    return ['<<REGEXP', value.toString(), 'REGEXP>>']
  }
  return value
}
var original = {
  email: /^j(ohn){0,1}(\.){0,1}doe@example.com$/,
  name: 'John Doe',
  yearOfBirth: 1988
}
console.log(original.email.test('john.doe@example.com'))
// > true
console.log(original.email.test('jdoe@example.com'))
// > true
console.log(original.email.test('jdoe@example.org'))
// > false
var serialized = JSON.stringify(original, serializer)
var deserialized = JSON.parse(serialized, deserialize)
console.log(deserialized.email.test('john.doe@example.com'))
// > true
console.log(deserialized.email.test('jdoe@example.com'))
// > true
console.log(deserialized.email.test('jdoe@example.org'))
// > false

You can use this method to serialise and deserialise any type you want, like functions or custom classes.

Code is available on JSbin

Google Calendar API, Google Maps API, Twitter API, GitHub API, jQuery API, React API, the DOM API. Is everything an API? What is an API and how can it be such an ubiquitous concept, present in such a diverse range of platforms and technologies?

Most applications and devices we use every day have some form of interface that is conceived for the interaction with humans. That may be in the form of graphical elements on a website or mobile app, conversational text on a chat bot or even the sound of a synthesised voice on a digital personal assistant. The common link between these is that they were all built and optimised for the human sensory system.

¶ Human vs. machine

But there is a different type of interface, one that is built for interaction with other programs or machines. That is an API – an Application Programming Interface (with Programming being the key word).

Some applications have an API as their only interface, when their sole purpose is to be used as building blocks by other programs – like the jQuery API, the React API or the DOM API. Others have an API in addition to a user interface, which is like a restaurant having a seating area for customers on foot and a drive-through window for people in cars – it’s the same application, generally handling the same content, but made available to different types of consumers in the way that is most convenient to them.

That’s why you open Google Calendar in your browser when you want to check what your diary looks like for tomorrow, but instead you use the Google Calendar API if you want to write a program that retrieves that information programmatically.

But isn't it be possible to create a program that is smart enough to interact with a standard user interface (one designed for humans) and avoid the hassle of building and maintaining a separate interface? Yes, it is, just like it’s technically possible for a pedestrian to order food from the drive-through window, and for a skillful motorist to drive right to their reserved table at the restaurant – it’s just not the best tool for the job.

It’s extremely difficult for a computer program to match a person’s ability to interact with an interface that was built for humans, and even more difficult is for it to adapt to change in the same way that a human does. This brings us to what I consider to be the two most important aspects of an API, and what sets them apart from a user interface: the format and the contract.

¶ The format

The format is the set of technologies and languages used by the application to interact with the consumer. Since the consumer is a machine, requests and responses must be formatted in a way that is optimised for machines – sign language, songs or poetry are interesting ways for humans to communicate with each other, but not so efficient when it comes to machines.

¶ The contract

The contract is what assures developers that an API will continue to respond to their application’s requests in a consistent way. You see, if on a graphical user interface a light green button on the top-left corner changes to a dark green button on the bottom-right corner, most people will instinctively adapt and continue using the application without any instructions or assistance.

Programs are a bit more strict. If an API changes the word tomato to tomAto without giving consumers the opportunity to update their code, entire applications can potentially break.

Contracts are a way for APIs to announce what exactly they produce and what they receive; as long as developers are following the rules that were established upfront, things will continue to work the same way.

¶ API paradigms

So how do you build an API? Is there a specific set of technologies and tools that you must use? Not really.

As long as you use an appropriate format and put a contract in place, you can use whatever programming paradigm, language and technology stack you want – even a static JSON file on a server can work as an API, if documented and published properly.

There are, however, some guidelines and specifications that apply to Web APIs, which are APIs that connect a server and a client over the web using the HTTP protocol. These are merely recommendations on things like naming conventions, what endpoints (URLs) to expose and how to convey success and error states.

¶ RPC

The earliest paradigm was RPC (Remote Procedure Call) which basically works as a function that is executed on a remote server. If you wanted to create an RPC API for adding, editing and removing articles, you’d have an endpoint at /getArticles for retrieving items, /addArticle for creating, etc. Like an in-memory function, each RPC endpoint can accept any number of arguments.

¶ REST

A more popular and flexible alternative is REST (REpresentational State Transfer) and it works by representing entities as resources. In our example from above, an article would be a resource, represented at /articles. To interact with this resource, the client is expected to use one of the available HTTP verbs to indicate the type of operation – GET for reading, POST for creating, PATCH for updating and DELETE for deleting.

REST is characterised by utilising HTTP features whenever possible, like verbs, headers and status codes.

¶ GraphQL

A more recent paradigm that has been gaining a lot of traction is GraphQL. Unlike RPC or REST, GraphQL exposes a single endpoint for all interactions, relying on a custom query language (akin to SQL) to tell the server exactly what data to get and in what structure. It’s possible for a single query to retrieve data from multiple collections of documents and automatically resolve the relationships between them.

GraphQL has a strong focus on performance, allowing consumers to receive only the fields they require (although this behaviour is sometimes falsely portrayed as exclusive to GraphQL, but REST supports it too).

¶ Wrapping up

We've established that an API is just another type of interface, but one with a specific format and a very strict structure (the contract). If you're thinking about building one, this article by Nicole Sievers.

There’s a huge number of platforms to choose from if you’re looking to build a blog. WordPress is a likely first candidate, as these days it powers over 30% of the entire web, but products like Medium, Blogger, or Wix, to name just a few, are also popular and powerful alternatives.

All of these platforms are similar in what they achieve, but different in what they offer and how they work. Some of them are free, whilst others are paid or place advertising alongside your content; some of them take care of the hosting for you, others require you to run a piece of software in your own infrastructure; some allow you to use a custom domain name, while others charge a fee for that. It feels almost impossible to find a solution that ticks all the boxes.

There’s another alternative that might do just that, and it’s not a name that usually comes to mind when you think of a blogging platform: GitHub. With Pages, any GitHub repository can be turned into a website associated with the easiest development workflow you can imagine. You don’t need to run any software or worry about setting up a server, and there’s no FTP, SSH or anything else getting in the way – you simply push your content to the repository and it goes live automatically.

Since GitHub offers a free tier with support for an unlimited number of repositories, this effectively means that you can host as many websites as you like, for free, with no advertising or setup required. Plus, it allows you to use your own domain name with HTTPS. That doesn’t sound like a bad deal, does it?

¶ Compared to more traditional blogging platforms

Before going any further, it’s important to point out a few key differences between GitHub Pages and the more traditional blogging platforms. Most of these platforms behave as opaque services, offering a set of visual interfaces from where you can manage your content. What happens between that and your site going live is not really under your control, particularly the how and where the content is actually stored. Will you be able to access it if the service suddenly shuts down? How easy is it to extract the content if you decide to migrate it to a different platform?

In that sense, GitHub Pages is a more transparent option. Because it uses the Git protocol, you can easily keep a copy of the repository in your local system, or even set up multiple remote mirrors using different providers (like Bitbucket and GitLab), so you’re not forced to put all eggs in one basket. Also, content is stored in flat files in the format of your choice. There’s no magical interface between you and the content – it’s just there.

However, this also makes GitHub Pages more of a barebones solution. It doesn’t come with a content management system right out of the box (even though you can one), and under the hood it represents a fundamentally different paradigms from the likes of WordPress. Rather than having a system that can dynamically fetch, generate and manipulate content on every request, GitHub Pages only lets you serve static files, which means your pages must be generated in advance.

This paradigm might not be the most obvious choice for certain applications, but a blog site is usually a great fit. Content is not expected to change every few seconds and it’s usually not automatically generated, so it’s perfectly reasonable to build a set of static pages every time you write a new post. Once those pages are generated, you can simply push the files to a repository and they will be live on your GitHub-powered blog within seconds.

¶ Getting started with GitHub Pages

To get started, the first thing you’ll need is a repository. To create one, head to https://github.com/new and you’ll find a screen similar to the one below.

After choosing a name and description for the repository, proceed to Create repository. If all goes well, you should be taken to your new repository page. It’s not terribly interesting at this point, since we haven’t added any content, but it shows the repository address in the box highlighted in red. Make note of that, we’ll use it in a minute.

Next, let’s build our first page. Create a new directory and place a file called index.html inside it, with some simple HTML.

<!DOCTYPE html>
<html>
<head>
  <title>My new blog</title>
</head>
<body>
  <h1>Welcome</h1>
  <p>This is where it all begins!</p>
</body>
</html>

Now it’s time to publish. There are various ways in which you can interact with your repository. For this tutorial, we’re going with the plain old terminal, as we’ll use a very short and simple list of commands, but if you’d rather use a graphical interface like GitHub Desktop, that’s perfectly fine too.

Open a terminal window and navigate to the directory in which you saved the file (cd /path/to/your/directory). Once there, type the commands below:

git init
git remote add origin git@github.com:eduardoboucas/stackbit-blog.git (replace this with your repository address)
git add index.html
git commit -m "Create first page"
git push origin master

What’s happening here? We’re starting a new Git repository in the directory we’ve created and then linking it to the GitHub repository. Then, we’re adding index.html to the list of files to be published, committing it with a message describing the operation, and finally pushing it to the remote repository.

If you refresh your repository page on GitHub, you should now see the file we’ve just uploaded.

Finally, we need to enable GitHub Pages for this repository. On the screen shown above, click on Settings and scroll down to the GitHub Pages section. In the Source selector, select master as the branch to build from and click Save.

After that, you should see a message confirming that your site is ready to be published and indicating its URL. If you navigate to it, you should be able to see your new website.

¶ Adding Jekyll to the mix

We have managed to create a functional solution, but in reality it’s not a very practical one. Whilst it’s fine to manually generate the HTML pages for this example site, it’s not a sustainable process for a reasonably-sized project.

For example, imagine that we want to create a landing page for our blog where all the posts are listed. For each entry, we want to display the title, an excerpt and a Read more button which, when clicked, takes people to another page where the full post is displayed. This means that creating or updating a post suddenly involves editing two files. Once we add things like pagination and category or tag aggregation pages, that number starts to grow and it becomes unmanageable.

Also, if you wanted to migrate your content to a different platform in the future, or perhaps reuse it across different channels, you’d want it to be in a format and structure that is as raw as possible, decoupled from any implementation or technology. Arguably, storing it in HTML files that are bloated with presentation markup is not the best way to do it.

This is where static site generators come in. A static site generator is a piece of software that takes content in various formats and generates HTML pages with it as per your requirements. This means taking a directory full of blog posts, in a format like Markdown, and generating landing pages, full post pages, pagination, tag and category aggregation pages, search and anything else you can think of. All you need to do is run a command (usually called a build step) and an entire site will be generated automatically for you.

There are hundreds of static site generators to choose from, but in this article we’ll focus on one in particular: Jekyll. The reason for this is that Jekyll has a special status with GitHub Pages. Whereas with any other static site generator you need to run the build step in your machine and push the resulting files to the repository, with Jekyll you can simply push the source files and GitHub Pages will run the build step for you, publishing the resulting files automatically.

To add Jekyll to our blog, first we must delete the index.html file we created previously. Then, install Jekyll and tell it the name of the directory where it should create the site. We should use the directory we’ve created previously, as it’s already linked to the GitHub repository.

gem install bundler jekyll
jekyll new stackbit-blog

To build the site on your system, run jekyll serve. It will generate all the HTML files and create a URL where the site will be available. Every time you modify a file, the site will be regenerated and the URL will reflect your changes.

If you’re using a github.io URL (e.g. your-username.github.io/your-repository), you must tell Jekyll that the base path is /your-repository instead of the root path. To do this, open the _config.yml file and set the baseurl property to /your-repository (in my case, this was /stackbit-blog).

When you’re ready to push your new Jekyll site live, you can run:

git add .
git commit -m “Add Jekyll”
git push origin master

In a few seconds, you’ll be able to refresh your GitHub URL and see your new Jekyll-powered site in action.

¶ Choosing a theme for your Jekyll site

To change the look and feel of your site, you can try different themes. A quick search for “jekyll themes” will lead you to thousands of themes to choose from, with different layouts and styles. When you find one that you like, you can enable it by adding it to the configuration file.

Alternatively, GitHub makes a handful of themes available for you to install via their interface. To try it, go to Settings, scroll down to GitHub Pages and click on Change theme. You’ll see a preview of each theme available, and once you find one that you like, hit Select theme and your site will update accordingly.