Jamstack has been in the website world for years. Static Site Generators (SSGs) – which often contain content that resides within the GitHub repo itself – are a big part of this story. This opens up the idea of having helpers who can open bridge applications for adding, modifying or editing content. Very useful!
Why build with a static site approach?
When we need to create sites based on such content, it is common to think about which database to use. Keeping content in a database is a one-time honor. But this is not the only approach! Because SSGs can be a great alternative;
They are cheap and easy to deploy. SSGs are usually free, which makes them perfect for MVP or concept proof.
They have great security. There is nothing to hack through the browser, because most of the site contains only static files.
You are ready to scale. The host you are already on can handle it.
There is another benefit to us when it comes to content sites. Site content can be written in static files in the repo itself. This means that adding and updating content can only be done with instant requests on GitHub, for example. Even for non-technically inclined people, it opens the door to things like Netlify CMS and the concept of open writing, allowing for community collaboration.
But let’s move on to the super low fi route and embrace the idea of bridging requests for content using nothing but basic HTML.
How people contribute to adding or updating resources is not always straightforward. People need to understand how to fork your repository, how and where to add your content, content formatting standards, required fields, and all sorts of things. They may even need to “spin up” the site locally to make sure the content looks right.
People who are serious Want to help? Our site sometimes lags behind because contributing is a technical hurdle and a learning curve – which is unfortunate.
Do you know what anyone can do? Use <form>
Just like a normal website, the easiest way for people to submit content is to fill out a form and submit it with the content they want.
What if we could create a way for users to add content to their sites in addition to HTML? <form> Designed to take exactly the content we need? But instead of posting the form on the database, it goes the way of the bridge application against our static site generator? There is a trick!
Trick: Create a GitHub bridge application with query parameters
Here’s a little tricky trick: We can pre-fill a bridge request against our storage by adding a query parameter to a specific GitHub URL. It comes from the GitHub document itself.
Let’s reverse that.
So now, how do we create this link? after the Does the user submit the form?
Let’s take a server-less site with CSS-Tricks, for example. Currently, the only way to add new resources is to fork the repo on GitHub and add a new markdown file. But let’s see how we can do this with form instead of jumping off the hops.
The server-less site itself has many categories (e.g. forms) that we can collaborate on. For the sake of simplicity, let’s focus on the “Resources” category. People can add articles about Serverless or Jamstack related things from there.
All resource files are in this folder in Repo.
Just picking a random file from there to discover the structure;
title: "How to deploy a custom domain with the Amplify Console"
author: "Nader Dabit"
tags: ["hosting", "amplify"]
In this tutorial, we’ll learn how to add a custom domain to an Amplify Console deployment in just a couple of minutes.
Given this content, our form must contain this column:
Link piece or description.
So let’s create an HTML form for all these fields:
I’m using Belma for styling, so the class names used here are the same.
Get user input about the content they want to add.
Make a string out of all this material.
Encode to format the string in such a way that people can read it
Attach an encoded string with a full URL pointing to the GitHub page for new bridge requests.
Here is the pen:
After pressing the Submit button, the user is taken to the right place on GitHub with an open bridge request for this new file.
Quick Warning: Users still need a GitHub account to contribute. But it’s much easier than knowing how to fork a repo and make a bridge application with this fork.
Other benefits of this approach
Well, for one, it’s a form that resides on our site. We can style it any way we want. This kind of control is always good.
Moving things forward
Let’s do a play with the other point above. We can pre-fill our form with information from the URL provided to the user instead of having to enter it manually.
With that in mind, let’s just ask the user now. give Input (instead of four) – URLs and tags only.
The demo used as an API to preload the data based on the URL provided by the user. Easy for user!
You can think of it as a minimal CMS for any type of static site generator. All you need to do is customize the form and update the pre-filled query parameters so that you can match the required data formats.
How would you use that kind of thing? The four sites we saw in the beginning are good examples. But there are many other occasions where the user may need to do something with the submission, and this may be a less elevated way of doing so.