Inside Hapi #2: Wellbeing report tech stack and progress update 📊

Published in

Hapi Wellness

7 min readJun 12, 2017

If you missed the last issue, check it out here.

Over the past fortnight we have been fleshing out the fundamentals of our new wellbeing report, with a large portion of our time dedicated to R&D and the architectural side of things.

We have now created a working demo and thought it would be fun to walk through the tech stack we used and process we followed!

If you would like updates sent straight to your inbox and early access to product testing, join the beta list below ⬇️

Process flowchart:

First we outlined a high level process of each stage that a user will go through, and what actions need to happen behind the scenes.

In our first alpha build we will be simply releasing a report, and add recommendations as well as a login system in later versions.

Originally we were going to use the promising software builder Bubble, but decided against it in the end as it would be harder to achieve a really polished interface (at least we concluded), and instead opted for more of a custom setup which you will see below ⬇️

Frontend:

We currently use the amazing visual website builder Webflow to power our entire Hapi website, so it seemed like a natural progression to use it for our new wellbeing report too, given how extensible and efficient it is.

Webflow is grand if you’re more a designer than a coder (as I am), because you can build responsive and highly functional websites in a drag and drop editor, whilst still having the flexibility to add as much custom code as you desire, which is really neat. Plus all the code generated is W3C compliant and cross-browser compatible for all you sceptics.

The quiz.

As our wellbeing report will be based on a set of questions that users answer, we need some sort of form to collect data. That’s where we will be using Typeform for our initial quiz, as the user-experience is second to none.

It’s yet another really simple drag-and-drop service that doesn't require you to hand code a bunch of forms, which is an ideal option if you don’t have much database experience (again, like me!).

Database:

Next up we need a place to store data that is collected from users in the Typeform. As I have very little database experience and don’t want to dedicate a bunch of time to learning MySQL, PHP or Node.js, and as this the very first version we’re releasing is a closed-alpha, I wanted to find a simpler way to hack together data-storage.

Enter none other than Google Sheets.

As it turns out you can easily structure a Google Sheet to act as a database, and generate a JSON feed to parse the data into a webpage.

But as I’m lazy and seek the path of least resistance, I instead found a service that turns a Google Sheet into a REST API. Say hello to Sheetsu.

Sheetsu does all of the heavy lifting for you, by formatting your Google Sheet data into a structured and easy to query format.

Another massive advantage of using Sheetsu is the security benefits. Merely creating a JSON feed out of a Google Sheet essentially exposes the entire set of data to the public if somebody has the URL, which you don’t want!

Whereas Sheetsu acts as the middleman between your data and the interface using HTTPS authentication, never exposing the URL to the original Google sheet and only querying the specified entry of data based on a unique user token, instead of the entire dataset.

MASSIVE shout out to the founder Michael for helping us get set up, and for writing a bunch of custom code that was extremely useful!!! 😀

Bringing it all together:

Now that all the individual components are set up in isolation, it’s time to connect them all together with the ultimate… connector, Zapier, an amateur coder and automation fanatics best friend.

Zapier essentially lets you connect thousands of different apps and services without writing any code. Amazing right!?

Above you can see a basic end-to-end test to determine if we can parse data from Typeform into Webflow using unique user tokens. We simply match the fields of the Typeform input data to columns in our sheet.

Here’s what the Zap does:

When a new Typeform entry is submitted ⬇️
Store data + the unique user token in our Google sheet ⬇️
Send an email to the user with a link to the report.

Visualising the data:

Finally we have to visualise the user’s data in the wellbeing report, which has been one of the harder parts to get working!

First of all we need to tell the page what data to use. The first part of this was achieved in the previous Zapier step where the user is sent an email with a link… which is the report page url + the user token.

E.g. app.gethapi.me/report?=usertoken

On page load the user token is parsed back to Sheetsu, which searches for the ID in Google Sheet and returns the row of data to our page.

We then convert the Sheetsu data into a JavaScript Object, so that it can be easily accessed and propagated throughout the report.

As an example, this is what my user data looks like:

From here it’s just a matter of linking each piece of data to elements on the page, in our case using document.getElementById as it’s the simplest way to do it within Webflow.

Second to that we’re using two chart libraries to create a few pretty looking graphs in the report, Chart.js and Progressbar.js.

We’re using the multiple properties chart to display an overall wellbeing score in a percent based format, and the polar area chart to display individual category scores for sleep, nutrition, fitness, cognition, happiness and lifespan.

The only thing left is to incorporate conditional visibility to elements on the page, which just means showing and hiding elements based on scores.

E.g. if the user’s sleep score < 35%, show X element (such as a recommendation as to how they can optimise their sleep).

Hosting:

We don’t have to worry too much about hosting in general as one-click deployment is built right into Webflow using AWS + their CloudFront CDN and Fastly.

But as we need a little more flexibility we’ve also setup a place to store and reference files using Amazon S3, given it’s free for the first 12-months too! 😀

Other stuff:

In addition to all of the services we use for the actual creation and running of the wellbeing report, here’s a few more that are used behind the scenes.

I use Atom as my code editor.
Github for version control.
Notion for documentation.
Cyberduck for pushes to our server.
Sketch for design.
And InVision for prototyping.

And that’s the tech stack we’re using for the alpha version of our wellbeing report! It’s quite a hack and obviously not the standard we want to be at eventually, but as an early stage company with limited resources we will do with what we’ve got for now!

If you would like to join the beta-list, signup here.