Accueil / Blog / Métier / 2016 / Alone in the cloud

Alone in the cloud

Par Eric Brehault publié 14/12/2016
Thoughts while helping my brother-in-law
Alone in the cloud

A database for my brother-in-law

My brother-in-law is a nice guy. On his free time, he works with the Red Cross to help homeless people in his neighborhood. Few days ago, he phoned me:

- "Eric, I would need a kind of database", he told me,
- "Oh ok, and what for?",
- "I want to collect in a single place all the welfare association or shelter adresses we can lead people to in our town and the other towns around. I am pretty sure there is an easy way to do it, could you point me to the right approach?".

There are certainly thousand ways to do it. But what is the easiest way for my brother-in-law? He knows how to use a computer but he is certainly not a developer, and he cannot manage a web server. So a cloud solution was obviously the best solution.

- "Maybe you should try Google Forms", I said.

I had never used Google Forms much before, but I knew it was very simple to set up a form, share it with various persons, and collect the results in a Google Doc spreadsheet, which is quite handy.

Two days after that, he called me back:

People often thinks there is an easy way to do what they want to do with their computer, and that is generally true... until it is not.

- "Google Forms is just great, I managed to create exactly what I need to collect the information. But do you know how I could offer a nice way to filter the data according various criteria. I am pretty sure there is an easy way to do it.", he told.

Yeah, people often thinks there is an easy way to do what they want to do with their computer, and that is generally true... until it is not.

After searching on internet for few seconds and finding nothing obvious, I answered:

- "Just give me access to your Google Form and spreadsheet, I will have a closer look and I let you know".

 It turned out it is not possible to display the collected data using Google Forms default features. I guess Google Forms just focus on one simple task: creating forms, so that's fair enough, right?

So I needed a way to list and filter data stored in a Google Spreadsheet. I found one: Awesome Table can do that. Awesome Table allows to define filtering criteria by adding a custom row in the spreadsheet. That's something my brother-in-law can do.

But now, we have two web pages: one is the Google Form page, and the other one is the Awesome Table one. And it would make a lot of sense to have them together, or at least linked somehow.

That was more difficult: using Google Apps Script, I succeeded in implementing a modal that can be opened from the Google Forms page and which just displays an IFRAME containing the Awesome Table page.

It is a bit tricky, and clearly not something my brother-in-law would have done by himself, but still, it works.

Low-code/big-code, two ways to use the "cloud"?

This story gives a quite good idea about why the "cloud" is awesome. But it also shows some limits.

The principle here is we can use powerful online services to build our own applications, and when the regular features do not fit our specific needs, we can customize them a little bit. That's the low-code approach.

That's what SalesForce is about, that is what Google is targeting with App Maker, and there are a lot of other similar providers.

Those solutions are vertical, they focus on a specific domain (building forms, managing sales, etc.).

There are also horizontal solutions: a pure headless backend, able to store your data. They usually comes with a REST API, and play nice in a microservice architecture.

But they have no UI nor integration features out-of-the-box. If you want to use them, you are expected to write code to talk with their API.

We could call it the "big-code" approach. Typical examples are Firebase or Contentful, and, in the opensource side, Kinto.

Big-code is for developers, but even "low-code" is difficult

Clearly, building an entire web site (or web application) on top of a pure REST API is a developer thing.

So non-developers will probably pick a vertical solution, but we have two problems here:

  • as it is vertical, it will probably not cover "everything" we might need (like: it just does forms, but no filtering),
  • low-code is still code so any customisation will involve actual programming skills.
Wouldn't be great if non-developers could create web sites the way they want?

Wouldn't be great if non-developers could create web sites the way they want, composing pages and agregating existing powerful features together freely?

Guess what, that's exactly what CMSes are about!!!

Where are CMSes today?

  1. CMSes can cover many different needs, they are not narrow vertical solutions (just think about my brother-in-law use case: using a CMS, we would have a custom content-type to manage the adresses, everything would be indexed, we could filter and sort all the results, even display them on a map, manage alerts, make it multlingual... you know, the full thing),
  2. CMSes have been designed to be used by non-technical people.
  3. Nevertheless, they do offer very powerful low-code solutions.


  1. They are old, their architecture is not very cloud-oriented.
  2. A lot of developers don't want to work with them anymore, they are considered "dirty", while headless services would be "clean".
Everybody can see how crappy UI is Google Spreadsheet compare to WordPress

Many people have posted articles explaining "Hey, we do not use any CMS anymore, we just run a static site and manage our content in Google Spreadsheet!". What's surprising here is that if you take any CMS, let's say WordPress for instance, well, everybody can see how crappy UI Google Spreadsheet is to manage content compare to WordPress.

So why people seems so enthusiastic about moving to the cloud?

Well, when we say "serverless" or "cloud", we know it means "using someone else's server", but more importantly, it means "we do not even care how the server is configured". That is a key point. Having a service running somewhere and being able to use it right away just by knowing its URL is a great thing.

Think about ElasticSearch for instance. Step 1: you install it on a server, step 2: you use from the outside, period. (I am talking about a simple usage of course, more demanding use cases might obviously involve a lot of work on the server side).

At the moment, CMSes are not architectured that way, and if they don't move now, they might become a thing of the past. Not because they are not useful, just because they do not work as the rest (rest/REST, you got it? :) ).

Don't let users alone in the cloud

So moving to a more cloud-compliant architecture is a necessity. And a lot of CMSes are currently developing their REST API, trying to build a headless CMS.

A headless CMS is very valuable because it turns a CMS into a flexible and versatile backend

A headless CMS is very valuable because it turns a CMS into a flexible and versatile backend that can be used in many application development contexts (instead of setting up every time a new backend for every app, and then try to somehow exchange its data with the rest of the information system, including the CMS).

But a pure headless CMS (just like Contentful) does not sound to me like a safe marketing approach: headless is a big-code thing, valuable for developers but totally unapproachable for non-developers (what would my brother-in-law would have done with a REST API?).

The CMSes success was based on user features. And those features are still very valid, and it happens they are exactly what is missing today when using those powerful vertical cloud-based solutions.

For most users, the low-code approach (which is the current solution promoted by those vertical solutions) will not be satisfying enough to compensate those deficiencies.

CMSes have the opportunity to become the user-friendly layer to build sites the cloud-way. So, to me, the challenge is not just to make CMSes more cloud-oriented, but also make the cloud more CMS-like.

Voir aussi
Django Rest Framework : les Serializer et les exceptions (partie 1) Django Rest Framework : les Serializer et les exceptions (partie 1) 16/12/2015

Django Rest Framework est une extension à Django pour développer rapidement des API REST robustes ...

Django Rest Framework : les tests (partie 8) Django Rest Framework : les tests (partie 8) 22/02/2016

Avec les API REST, développer très rapidement des tests fonctionnels complets qui frôlent les ...

Django Rest Framework : versioning pour les API REST (hors série) Django Rest Framework : versioning pour les API REST (hors série) 08/02/2016

À tort, le versioning est souvent une étape négligée au début d'un projet d'API REST : pas ...

Design d'API pour app mobile Design d'API pour app mobile 04/04/2016

Recette d'une API qui rend happy.

Django Rest Framework : versioning avec DRF (partie 7) Django Rest Framework : versioning avec DRF (partie 7) 15/02/2016

DRF remplit vaillamment son devoir et propose une intégration poussée du versioning d'API. À tel ...