A few days ago, i came across a task to build a that only composed of one page that will contains some tools. It has a very minimum content and much more about the functionality about that tools. When i initially build it, i just go hardcoded every content there in the codebase. Until at certain point, i feel like that the content team is requesting many content changes on that page. Later i find the hassle that i every time there's a content change request, i need to open up my code editor, change the content, build the app, and deploy it again. With that happen, i'm start thinking that using a CMS would convenient. But, i also feel like investing tens or hundred bucks for managing this small and minimum content is not worth the price.

While looking at that problem, suddenly some insight come up in my mind. I remember a twitter debate some times ago regarding what CMS is the best to use, and i remember there's one guy that jokingly (or that's what i initially thought) said he's using a spreadsheet, and it's the best CMS. While looking at that tweet, my brain starting to making sense of it. With that as inspiration, i start to creating some Prove of Concept for my case.

Making Sense of It

A spreadsheet file is basically a tabular file with rows and column. With this we basically able to build some database using that, combine it with its easily accessible file editor, we can basically create a CMS out of it. Even though that wouldn't be that reliable to use for a big and sophisticated system. But, in my use case, i would only need a very small and simple database with only few tens of rows. Managing that much of data in a spreadsheet file would still be simple.

Another reason i use is editing a spreadsheet file is something that most people can do, so it basically very easy to use. While the availability of an online version can also make it easily accessed and shared. With the use case of a CMS, we also can also build some content type with managing it by sheet.

How To Create One

Now, the question is how to create this. So, i start my digging on how i'm able to create this. I find that the best one is to utilize google sheet to create and manage the spreadsheet file. The clear reason for this is because it's free, no cost that you will spend for a CMS which usually quite pricy, it also easily accessible, and many people certainly ever use it. But, the deciding reason is the extended service that google have called "App Script". This service is a scripting platform that allow us to create application or running script that connected with a google workspace products, as example is google sheet. Using the App Script, we can create a REST endpoint where we can retrieve our CMS data in spreadsheet in a JSON format.

In order to do all of that, you can follow this steps by steps process.

• First we need to create a google sheet file. You can create it via your google drive or just hit the link https://docs.google.com/spreadsheets/create.
• Then, you can define your content type by the sheet.
• To start creating a data within the content type, you will only need to utilize at least two columns. The first column would be the key column, and the second columns is the value. The important things to note is, the key column would be used to index your data in your front end application later on. So this is something that not supposedly to change when you deploy the website.

• Since our spreadsheet is ready, now we can create an App Script with this. Open the "Extensions" option in google sheet menu, and click "App Script"

• To create a REST API on that App Script, you need to create a function called "doGet", this allow you to make a GET request to the App Script and run the code inside that function.
• Bellow is the example of that function

1function doGet(data) {
2  const doc = SpreadsheetApp.getActiveSpreadsheet();
3  const sheet = doc.getSheetByName('Content');
4  const range = sheet.getDataRange();
5  const values = range.getDisplayValues();
6
7  const result = {};
8
9  values.slice(1).forEach((item) => {
10    const key = item[0].toLowerCase().replaceAll(' ', '-')
11    Object.assign(result, {[key]: item[1]})
12  })
13  
14  return ContentService.createTextOutput(JSON.stringify({data: result}))
15  .setMimeType(ContentService.MimeType.JSON);
16}

Within that function, initially i retrieving the values within the "Content" sheet. Initially that value would be in format of a 2D array, that in form of an array of data within a rows, which the rows data itself is in array. In this case, i want to transform the data into an object, with the key is from the first column and the value is from the second column. I also transform the key that previously in a more human readable format to a kebab-case format. So it easier to access and use in the codebase later, while i think also less prone to writing error.

• Whenever you complete with your function, click the "Deploy" button in top right corner and fill the required field for the deployment.

After following all of those steps, you will get a REST endpoint where you can retrieve the JSON data that you create in the App Script. Bellow is the example of JSON data from what i create earlier on .

1{
2  "data": {
3    "title": "LOREM IPSUM DOLOR AMET",
4    "sub-title": "Lorem ipsum dolor sit amet",
5    "paragraph": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed et mauris libero. Sed quis diam nec magna iaculis fermentum vel id ligula. Mauris auctor augue non ipsum convallis, vel efficitur felis eleifend. Vestibulum non ex nec nisl scelerisque accumsan.",
6    "cta-button-label": "Lorem ipsum",
7    "cta-button-link": "https://wa.me/message/*********",
8    "process-1-label": "Lorem ipsum dolor sit amet, consectetur adipiscing elit.",
9    "process-1-label-limit": "Lorem ipsum dolor sit amet, consectetur adipiscing elit.",
10    "process-1-input-placeholder": "Lorem ipsum dolor sit amet, consectetur adipiscing elit.",
11    "process-2-label": "Lorem ipsum dolor sit amet, consectetur adipiscing elit.",
12    "process-2-button": "Lorem ipsum dolor sit amet, consectetur adipiscing elit.",
13    "process-3-button": "Lorem ipsum dolor sit amet, consectetur adipiscing elit.",
14    "process-3-not-found": "Lorem ipsum dolor sit amet, consectetur adipiscing elit."
15  }
16}

Limitation

Spreadsheet isn't specifically created to be a CMS, so it will always have some limitation to it. The first things that you might notice is complexity, this solution isn't suitable if you have a website with very rich content, that have many deep interconnected content type. Even though you might able to build it, but i will be some system that not maintainable and friendly to use in long run. This would also mean that this system wouldn't be very good for a drastic scalability in the future.

The speed would also be another concern, from what i experience with my use case, i at least took 1-2 seconds to get the data from the App Script endpoint. Of course this will be a concern if you have a bigger and more complicated system. Compared if you request the same amount of content to another CMS provider, it will definitely take far less time.

Another things to note is potential user flaws. Since changing the key is definitely able to ruin your system, but the value of the key itself can be easily changed by someone. This would also imply that this system can't be used by many people that have a potential of not fully understand what in there.