Using this and Gitlab and Netlify you can make static pages that can edit themselves without having a backend anywhere. That is the holy grail of dynamic static. Or Naught Static Pages as I call them :)
I'm not talking about making use of some "serverless" backend like Firebase or something. I'm talking about only using git hosting and static website hosting and in browser computation to make "dynamic" websites.
What you do is:
* You make a regular static page with whatever static web page framework or view template software you like that runs in the browser. I got Handlebars to work. (I'm looking at trying Choo next, because it is literally one hundredth of the size)
* Make another "admin" page where the user can input the data. This page first checks out the current git repo.
* When the user hits submit you use the newly edited data to build the static site in the browser and commit/push everything to git where it is automatically pushed to netlify.
You first have to bootstrap this process on your own machine in the first commit.
I've been holding on to this secret for over a year. Well the cats out of the bag now. I haven't run into someone doing something similar with Isomorphic-git yet. I've had it in production for an artist website for almost a year. I don't know if this is good or bad for Gitlabs or Netlifys business model.
It looks like Netlify-cms runs the git and static website software on Netlify backends. So you're not getting the freedom to do whatever you want in the frontend like you do with my approach where the static site generation and git handling happens in the browser. With Netlify-cms you are tied to their implementation of these things on their backend servers.
You can configure netlify-cms to go through netlify for the git operations or not. Going through netlify servers let users edit without github credentials.
On the blog where I have set this up, it goes direct and content editors aren't that happy with the experience
Doing static site generation in the browser would definitely help with previews, at the cost of not working with off-the-shelf static site generators.
I like the "dynamic but static" idea ! Doesn't this already exists if you have a static website but with some dynamic features (js client code calling some serverless functions or querying stuff on AWS for example) ?
I guess here you are adding the "you can edit it from a browser", is that right ?
I was about to make a site just like you describe, having a static website that uses js to dynamically show and edit some content and have it be fetched and stored at some serverless host like Firebase. I guess AWS has something similar to Firebase, but the complexity of AWS keeps me away from checking it out.
There are two benefits to my approach, which motivated me to do it.
1. No backend code or database. Not even serverless. All the complexity of managing this is gone. Don't have to worry about quotas or paying for this either as it doesn't exist. We just need a static site host that can pull and host from git. Netlify does this.
2. Perfect caching performance, as we build a new static website when we change any data. Nothing is generated at view time. The thought of each user calling a backend for the same data over and over on each page load, when the page hasn't changed gives me pain. With this all the data is just built directly into the static site and the static site host and the browser takes care of doing http caching if it isn't changed.
Dynamic page content without hosting a backend. Backend hosting can be enormously complicated when you just want to be able to edit a few fields in the page dynamically.
My experience is that the "backend" of a website is where the backend business logic code and the database of the web page is. But in this case it is all running in the frontend in the browser.
I'm not sure this is a secret, I think I've seen people talk about this in the past. I even did a little bit of work looking into whether or not it was feasible as a replacement for CMS backends like Wordpress, but eventually gave up because:
A) Git operations on both Github and Gitlab are kind of slow (compared to normal AJAX requests).
B) It requires you to embed Git credentials into your webapp clientside, and I'm more comfortable building secure client sessions than I am messing around with libsodium to encrypt credentials locally.
C) The lack of isolation between my data and site code means that I don't have defense in depth if the credentials get compromised. If someone breaks into my session, they can't only compromise my database, they also have push rights to my entire repository. This is especially problematic for apps where I want multiple people to have access, since I often don't trust them to keep their passwords secure.
D) To expand on that, you can't do any validation of input at all -- clientside validation doesn't count. Your only permission you can grant people is "100% commit access to my entire repo, plus (potentially) the ability to execute arbitrary code during my build process", or "nothing".
E) It's also just honestly a lot more complicated than normal hosting. There ended up being a lot of niggly details that I was fiddling around with that weren't terrible to solve, but left me asking, "what exactly is my end-goal here and is it worth the time I'm putting in?"
The security issues mean that having an open submission form is a pretty bad idea anyway, so really you'd only want to do this for a personal site. Except -- I can't think of any scenario where I want to edit a personal website, I have an Internet connection, and I'm on a computer I'm comfortable typing Git credentials into, but I don't have Git installed. Usually it's just going to be easier to make the edit locally and push to Git the normal way.
----
If you are trying to build a multi-user submission form:
You can build a purely static site on Netlify and use 100 hours of 'serverless' functions for free. Your functions can still do stuff like push changes to Gitlab and trigger Gitlab builds if you don't want to fiddle with a database, except now you can actually run real input validation. Plus, if you're using serverless functions, you can make your submission forms work without Javascript, which is a nice plus.
At the point where you're doing more than 100 hours of work a month running builds, you're also probably at the point where the pure-JS repo solution is going to have a really hard time scaling. And if you do reach the point where 100 hours doesn't cut it, you can scale up Netlify functions without rebuilding your entire submission form to use a different architecture.
----
None of that is to say that the setup Sammi describes isn't worth playing around with, or that you can't build a working site with it, or that people should be discouraged from trying. It's very cool; and it's useful to try things like this even just from the perspective that they're fun projects that will make you a better coder.
I just question whether it's really a holy grail, or even a good idea to hook up to your own Gitlab account. I would posit that the reason you see fewer people actually following through and adopting Isomorphic Git in this way isn't because no one's thought of it, it's because you can build the same solution more efficiently and safely for the same price ($0) using serverless functions or (worse-case) setting up a single $5 Linode VPN that you share between all of your sites.
You don't need to embed the git credentials in the site. I just made a login form that takes the gitlab credentials. Gitlab gives you 5 users per project, so you can give several people access.
You're absolutely right that this is not a replacement for a full blown CMS, or for when server side input validation is necessary, or for when different people need different edit rights. I've stayed away from using the term CMS for this reason as it implies that complex content management abilities are required. These "dynamic static" pages only give you full edit rights or not, and you need to build everything manually as it is a static website after all.
I have found this approach useful for hosting a static website for an artist where I wanted the artist to be able to easily update some info on the site. I imagine there are a lot of cases like this where you are building a small static website for someone else who isn't a developer and you want them to be able to update the site themselves later, so they don't have to bother you about it.
I'm not talking about making use of some "serverless" backend like Firebase or something. I'm talking about only using git hosting and static website hosting and in browser computation to make "dynamic" websites.
What you do is:
* You make a regular static page with whatever static web page framework or view template software you like that runs in the browser. I got Handlebars to work. (I'm looking at trying Choo next, because it is literally one hundredth of the size)
* Make another "admin" page where the user can input the data. This page first checks out the current git repo.
* When the user hits submit you use the newly edited data to build the static site in the browser and commit/push everything to git where it is automatically pushed to netlify.
You first have to bootstrap this process on your own machine in the first commit.
I've been holding on to this secret for over a year. Well the cats out of the bag now. I haven't run into someone doing something similar with Isomorphic-git yet. I've had it in production for an artist website for almost a year. I don't know if this is good or bad for Gitlabs or Netlifys business model.