And now for something completely different
Druid is known for being a Drupal-house. And we are. Most of the projects for us are still in the category of Drupal where a CMS is needed. But Drupal is not always the right tool for the job. Like Dries Buytaert stated in DrupalCon Vienna, “Drupal is no longer for simple sites”, and generally not for all use cases. That said, Drupal is still a very good choice for the right jobs.
We have recently had some non-Drupal projects, and now I’m going to tell about one of those. Non-Drupal meaning, however, that the tech stack wasn’t completely new to us, as we are already very familiar with the programming languages themselves (PHP and JavaScript).
The need – say no more, say no more
Our customer had a need which was not totally structured at the moment as they targeted a market which is under a major disruption. The digital landscape for this particular market is evolving, and as is often the case with evolution, you need to adapt or perish. What we already knew from the start was that the application needed to be mobile-friendly and its main function should be to facilitate communication between users. Create a backlog from that!
Mobile? So we thought PWA is the way to go. At Druid we have been fans of PWA for a while, and we have written about this exciting concept before. Progressive Web Applications are the future and show much promise. PWA is also a very good choice when you want to distribute your apps without App Store or Play Store. For example, some internal tools could be delivered from intranets. I’ll tell more about PWA later. Anyway, we thought that PWA would suit the need very well.
Communication? Wink wink nudge nudge. Say no more, say no more. This raised ideas for data structuring and for the UI.
Tech stack – And Now for Something Completely Different
We decided to go bold and try totally new components for this project: frontend, backend, database and infrastructure. Of course, there was knowledge and learning behind these things with some PoCs and such. And like I said, we were familiar with the tech. Or at least someone on the team was.
If we start from the bottom, we chose Docker for being the glue between components and between environments. We quickly drafted an open source version of this Docker thingie and released it as a separate thing. Stonehenge is a multi-project local development environment and toolset on Docker. Now the project uses Stonehenge as a developer’s tool to run it. As the local development environment is quite a common problem for developers, we thought this could be beneficial for others too. So that’s why we extracted this functionality from the project and released it as a separate tool.
Basically, Stonehenge provides us with local URLs and a proxy to handle the traffic to our projects. Proxy is made with Traefik which is just a breeze of fresh air compared to any previous tech used for the same purpose. I can say it works and performs very well on production too!
The project itself defines the services for our application. The basic stuff like Nginx, PHP, database and CLI and their relationships. We use Docker Compose for this.
For the application itself, we chose Symfony 4 for the backend and React for the frontend. Basically, Symfony creates a standard JSON API which the React application then uses. One reason we chose Symfony was the support for our database (what could it be?) via Doctrine. When evaluating different backend (PHP) frameworks, we studied the experiences of other developers, and there seemed to be nothing but praise for Symfony 4. And it really was a pleasure I can say. Some of us already had experience with Symfony as Drupal 8 is built on top of Symfony 3. Still, there were many new things for us to learn.
The database. MySQL, MariaDB, PostgreSQL or something else? We ended up choosing MongoDB to complete our jump into the unknown. MongoDB is a so-called NoSQL database where data is stored as objects instead of rows. This is very useful with data that can be very different by structure (read: document might have data which the other documents of the same type do not have). Also, the schema does not need to be defined beforehand (and updated) but it just lives by how you use your document entities.
React is something which I personally cannot write very much about, however my colleague Kristian has written a small recap of its use in our project below. Beware though: the Dependency Hell in Javascript world and the vast amount of same-but-different kind of tools available might sometimes make a developer’s life not-so-easy.
Quote from Kristian:
“It was pretty great to work with React on a large-scale project. In general, it was surprisingly easy. We did make some mistakes early on, which ended up forcing us to refactor. The original plan was to render the majority of the application with Twig, and only the communication aspect would be controlled by React. Eventually, the majority of the application was ported to our React app.
This means that we initially didn’t implement any sort of routing system and we didn’t think enough about the architecture of our store. Luckily we were able to refactor with relative ease once these problems presented themselves.
Probably the most fun thing during this application for me was working with MobX. This is something I’ve wanted to do for a long time, and I’m glad I got a chance to finally use it in a commercial application. Essentially MobX is a state management tool built on the observer pattern. All observers who are watching an observable variable will magically update whenever the observable value changes. If there is one thing I’d do differently next time, I’d probably use MobX State Tree, which is a more opinionated version of MobX with some Redux-like behavior, without the overhead of Redux.”
Well, there you have it.
As we jumped on the PWA bandwagon, React helped us there to basically create a single page app which helps on some aspects on PWA. What does a PWA do, one might ask? You can think of it as an app which is basically a webpage. That means no App Store or Play Store for distribution. The app is updated when the web application is updated. There are a few distinct features to make it an “app like” experience: caching of assets for speed, standalone mode (to make your own UI without browser components), access to some mobile APIs and offline capabilities. There are also push notifications which currently work only on Android. Check the 2018 State of Progressive Web Apps for more info.
Progressive Web Applications is funny enough something Apple envisioned already in 2007 when they announced/released the original iPhone. Currently they are very strongly driven by Google. So this means basically that PWA works better on Android phones at the moment.
Fortune favors the bold, and I strongly believe the PWA is the future of apps and especially useful when creating tools for organizations and business.
Well, that was quite a long rant about technical stuff. Let’s take a breath for a moment.
“And now a film about a man with a tape recorder up his brother’s nose”
GDPR aspect
Yeah, the infamous GDPR. At this point we don’t have actual user data, so we’re nicely covered. But we designed the whole development on dummy data which started to be very fruitful during the project. We programmatically added data fixtures, which filled our database with dummy data. So in that sense, we’re totally GDPR-compliant when we do development. We don’t need production data.
This gave us some unexpected benefits too. In testing for example, we quickly noticed that we can use this generated data within our tests. How cool is that! Well, it is quite cool I can say.
“In this picture, there are 47 people. None of them can be seen.”
Next steps
The project is now in MVP state and moves to “field-testing” phase. Hopefully, end-users will like what we have done. The testing will be done with small groups and in a controlled way. This means we use a certain set of generated data suited for that test group. Also, we control the PWA aspect of the MVP. At the moment it works best on Android, so that will be the platform used in testing in testing.
“Now, what’s to be done? Tell me sir, have you confused your cat recently?”
About the coconut
We have learned a lot! This means that our learnings are already influencing our new projects and somewhat of how we handle older projects. We’re about to copy the backend stuff for a new API-only project and the Docker stuff has evolved into a very usable state. And releasing an open source project (Stonehenge) was a definite plus!
The most exciting part at least for me has been to share all this with more and more people inside Druid so that all the learnings can be put into practice on a wider scale.
“Wait a minute — supposing two swallows carried it together?”
Marko Korhonen
CTO, The Ministry of Silly Walks
