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 CMS is needed. But Drupal is not always a 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.
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 the 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 very well for our need.
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 with totally new components for a new 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 Open Source version of this Docker thingie and released it as a separate thing. Stonehenge is a multi-project local development environment & toolset on Docker. Now the project uses Stonehenge as a developer’s tool to run it. As the local development environment is a quite 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 good on production too!
The project itself defines 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 consumes. One reason we chose Symfony was the support for our database (what it could 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 build 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 rather than rows. This is very useful with data which 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.
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 the PWA wagon, React helped us there to basically create a single page app which helps on some aspects on PWA. What PWA does 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 “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 visioned already at 2007 when they announced/released the original iPhone. Current thing is still very strongly driven by Google. So this means basically that PWA works currently better on Android phones.
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 a quite 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”
Yeah, the infamous GDPR. As in 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 also gave us some unexpected benefits too. Like in testing, we quickly noted 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.”
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 learned stuff is already influencing 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 to very usable state. And releasing Open Source project (Stonehenge) was a definite plus!
The most exciting part at least for me has been sharing all this with more and more people inside Druid so all the stuff learned can be put into practice on a wider scale.
“Wait a minute -- supposing two swallows carried it together?”
About the writer
CTO, The Ministry of Silly Walks