Near the beginning of my software development career, I worked on a pretty standard web application. The project was not a commercial success, but it did give me a good technical foundation that turned out to be very useful for my career so far.

image

For those interested, the tech stack was relatively boring (in a good way) with the backend service written in Java and frontend written in Angular 2+.

One of the most memorable aspects of that project was how we built the news/blog section. I might have forgotten some of the specifics, but the high-level idea should still be accurate.

The implementation

It all started with a need to be able to display articles written by the company. By that time the rest of the product was mostly in place and the section meant for articles had a simple placeholder.

I’m not completely sure on how we even landed on the choice that we eventually ended up making. I do know that the solution had to be simple and convenient enough to be used by non-technical people. Running a separate service, such as Wordpress, just to be able to post articles was probably not a reasonable choice.

The idea for the CMS implementation ended up relying on Google Docs. The person writing the articles would create a new document in a specific Google Drive folder. The title of the document would be used as the title of the article, and the content would be shown as-is on the web page. To support localization, there was one subfolder for every language as well.

The backend service would periodically query the contents of the shared Google Drive folder. If new posts were found, it would export them into HTML and store them on the backend. If I recall correctly, it might have also done some sanitization or tweaks to overcome some limitations related to this setup.

The frontend would then load the latest post and show it on the landing page. There was also a view that showed the full list of articles. By default, Angular 2 would strip out all of the styling in order to sanitize the data, and it does make sense for most use cases, since you probably don’t want an user named Little Bobby <script>alert('lol');</script> Tables causing trouble. You could work around that by using a functionality that turned all of that off. Unless you had malicious users writing the content, you should be fine. And if those people had access to the Google account hosting those documents, then you probably had bigger issues anyway.

If you look at this solution from another angle, it makes a lot of sense. What we ended up doing was using Google Docs as the editor and host for any content that we wanted to show. You don’t need to implement an editor into your back-office interface if you rely on a big company that has done all that work for you. No need to retrain users as well, just point them to the folder and let them work with the editor that is likely already familiar to them.

I cannot say much about the long-term viability of this solution, as the project ended up being shut down not long after. Based on experience gained ever since, I’d reckon that this solution could fail in all sorts of fun ways:

  • Google changing the Google Drive API
  • Google automatically banning your account because its “AI” deemed your content to be in violation of some policies
  • Someone accidentally deleting the shared folder or contents within it

Conclusion

I’m not sure if I would consider something similar in a future project. Implementing a good chunk of this as a junior developer was pretty fun though. It also serves as a good example of creativity and not reinventing the wheel when it’s not necessary.

I am happy to see that others have come up with similar solutions since then. If you look up “google drive cms”, you’ll find some relevant results:

While I can’t say that the solution we built was the first of its kind, I do feel validated that other smart people have also come up with a similar solution.