8 things we learned at Druid

Last week we said goodbye to our wonderful interns Florence and Bea. During their four month internship with us, they built a demo application with JavaScript for car repair shops and their customers – and did an absolutely brilliant job.

The app lets users choose the nearest car repair shop, book an appointment for car maintenance, keep in touch with the shop through in-app chat and see the progress stage of their car as it’s being repaired. The app was built with the user in mind, focusing on the user’s convenience.

Before Bea and Florence embarked on new adventures, we asked them to write about their learnings and experiences from the project and beyond. It turned out they had a lot to share – so let’s dive right in!

1. Progressive Web Apps (PWA)

PWAs have been in the app ecosystem for some time and you may have probably used one without knowing. They are web apps with an enhanced capability in modern web browsers.

Among many of the features we discovered are its installability, offline mode experience, linkability, native-app feel, re-engaging nature and a single codebase that can be used on different devices. It was interesting to know that companies like Uber, Trivago, AliExpress, Spotify, Starbucks and Pinterest are already using PWAs as their web service platform.

Although it was a new concept for us, a lot of research enlightened us on how we could apply it in the project we wanted to build. We built a PWA with Create React App (CRA) which was incredibly convenient because CRA has a template for building PWAs.

2. Teamwork

Team synergy was by far one of the most important factors that influenced the outcome of our project. This encompasses a lot of factors ranging from setting project expectations to good and clear communication.

We tried as much as possible to be on the same page in the building process of the project. From the technical perspective, we set up a system where we could review each other’s codes before merging changes to our main branch. That meant we had to ensure we were writing readable and understandable codes. In order to ensure uniformity in our codebase, we had rules set in ESLINT.

After working independently to solve complex problems for more than half-way into the internship, we decided to try pair coding at some point. To be honest, we wished we had started with pair coding much earlier, because we realised how knowledge sharing contributed to arriving at solutions quickly.

3. Who needs a server these days?

You may have heard about “serverless backend”, which means running your server-side code without having to maintain your own server. The solution is tempting, because it cuts the costs (on-demand, so you don’t pay for idle time of the server), it’s easy to scale and lowers administrative overhead.

AWS Lambda is a popular choice, but managing service discovery, API gateways, and keeping your app and the functions in sync can be overwhelming – that’s where Netlify functions come to the rescue. We chose to use them in our project, because they are a make-it-easier layer over Lambda functions, which means we could use them without an AWS account; also, keeping everything up to date was a breeze.

With the serverless functions in a correctly named folder in the project, we were deploying our React frontend together with the serverless backend at the same time and Netlify did the dirty work handling all the rest. Add to that the continuous deployment straight from our GitHub repository, including previews of pull requests updates, and you got yourself a recipe for painless deployment handling!

4. Mercure for real-time features

For our app we needed real-time communication to create our in-app chat and to update the UI of the end user when the admin changes the state of the user’s appointment. We decided to use Mercure, an open protocol not using Web Sockets, but instead built on top of HTTP and SSE (Server-Sent Events).

With the Mercure Hub set up (using Docker image for local development and deployed to Druid’s server for production), we needed to do two things in our app: publish updates and subscribe to them.

Publishing happens when someone sends a new chat message or the admin changes the appointment state – a regular POST request is sent from our frontend to the serverless backend, where the data is saved to the database and Mercure update is published to the Hub.

Then the Hub’s job is to pass this update down the correct channels, so that only the users subscribed to it get the information. Subscribers are browsers; for example when an end user opens their appointment view, the app subscribes to updates about their appointment (change of stage or price estimate) and to updates of their chat (and only theirs, so that they don’t get somebody else’s messages by mistake).

To subscribe, we used EventSource, which is kind of a keep-alive connection to the server (the Mercure Hub in our case) and differs from Web Sockets in that EventSource is one-way communication, it can only listen to updates, not send any – which is all we needed.

5. Web push notifications

Like any new feature that was implemented without prior knowledge of how it should work, implementing push notification was mostly learning by doing. Push notifications are messages sent to user’s devices from a website via a browser. And with the offline feature of PWAs, users do not miss notifications even when they are not online.

Looking at our app’s use case, push notification capabilities were useful for notifying users whenever there was a change in information. For eCommerce and marketers it’s an amazing way to re-engage with web visitors whenever there are new products, releases, etc. It was relevant to build this feature, especially as PWAs are becoming more popular and being supported by more browsers.

6. User experience

We needed to keep the end user in mind as we worked on our app. Have you noticed the unexpected shifting of elements like videos, buttons or fonts on a web page while the page is still loading? Exactly, that can cause a poor user experience and is referred to as Cumulative Layout Shift (CLS). It’s a Google metric which is used to measure the user’s experience on a web page.

CLS is usually a good way to detect coding issues which could be resolved to improve usability on your site. These may be tiny details that could slip through during development and may seem “irrelevant”, but they definitely count! What is the point in building an app that lacks usability? Knowing about CLS and its importance highlighted user experience as an important skill to have as it makes us better developers.

7. Scrummy Scrum

Agile methodologies have become the default way of working in the software development field, so to nobody’s surprise we used the Scrum method in our project. We learnt about this style at school, but only working on a long-term project unveils the true power of Scrum.

Thanks to the regular feedback sessions in retrospective meetings, with every iteration there were less conflicts or misunderstandings, with every sprint we worked better and more efficiently. For every ticket in the backlog we assigned points to estimate the time and effort needed to complete the task, which helped us understand deeper the goals, expectations and each other’s views.

We also made mistakes like not deploying every sprint – it came back to bite us in the last few weeks of the project as we ended up with several issues accumulated in production. Debugging and understanding which error is caused by which part of the code failing was unnecessarily complicated, so lesson learnt!

8. Teal is the new black

There’s so much more in the management philosophies landscape than the traditional, hierarchical way of big bosses, small bosses and the workers. Druid is slowly but steadily undergoing a Teal transformation, aiming at a flatter management structure.

Many tasks at the company are being taken care of by swarms – a group of people interested in the issue or topic around which the swarm was formed. The doers declare their readiness to put time and effort into the subject, the helpers can offer a little less time, and the followers are interested in the works, but for one reason or another can’t promise much help.

In our time at Druid we had a chance to observe among other things the work of the salary week swarm who took care of designing and executing salary negotiations. The best thing about swarms is they can be formed as issues or tasks arise, and torn down when they solve what they were born to do or when they become inactive and die out.

Another part of the Teal way that we found interesting is the advice process helping in decision making. When there is a decision to be made, one person volunteers to be the decision maker and asks for advice, especially from people directly affected by the decision and from experts on the topic. Others can then give advice (not their opinion, but strictly advice), but the final choice of course of action is made by the decision-maker – that also includes full responsibility for the outcome.