Boards in the Clouds – Part 1: Introduction

With more and more team members spread across different floors and people working from home this solution didn’t scale well. We advise our clients to live and breathe digitalization, so we thought it would be the perfect opportunity to set a good example and to digitalize our whiteboards.

Equipped with design and frontend knowledge we still needed a way to build a backend. A few things were essential for us to create this kind of solution:

Web collaboration

Working on a whiteboard collaboratively should feel as close as possible to a real board. Which is why we needed real-time web updates without having to worry about the details.

Driven by native web technologies

Our designers and front end specialists love web technologies such as JavaScript, so our backend should use them as well.

Handlebars for the cloud

We wanted technology that could guide us on how to architect and develop the backend. We truly believe that HTTP and web APIs will play an important role in how companies and services will communicate with each other in the future. Therefore, designing a backend with an API-first approach is something that we wanted to train ourselves in.

Authentication

Obviously the posts and boards should not be visible to the public at first. As a design and innovation consultancy we don’t want to worry about our applications‘ security. Both security (e.g. HTTPS) and authentication (e.g token-based authentication) best practices should be baked right into our backend.

As you might already know we’ve partnered with the native web to build wolkenkit, a JavaScript backend that empowers interdisciplinary teams when building cloud-native applications. Since it addresses lots of the points I’ve mentioned above, it seemed like a perfect opportunity to use it for our own needs. In the upcoming series, we would like to document how we used wolkenkit and an interdisciplinary mindset to move our boards into the cloud. The result of this journey is an application that we’ll share as open-source once we’re done. So, stay tuned.

In the second part of our series we’ll talk about how we modeled the backend using domain-driven design.