Inzuro

Inzuro is a tenant-based, multi-language Website and PWA designed to streamline the sales process for insurances and warranties. Built for high performance and scalability, the platform employs a robust tech stack that includes PHP 7.4 with Symfony 4.5 for the backend, SQL for database management, and a frontend developed in ES6, SCSS, and Bootstrap. Docker and Webpack are utilized for containerization and asset bundling, respectively.

My Involvement

• Deployment: I set up Gitlab CI/CD to work with Docker to seamlessly deploy our site. I devised a deployment strategy as well as best practices for backups and data safety.
• Requirements Definitions: I was talking directly to customers and leading requirement meetings to figure out what exactly they needed from this Platform
• Database Structure: Using the Doctrine ORM I set up the entire Database
• Backend: I coded the entire Backend using Symfony

Problems & Solutions

i18n

The Problem

The Inzuro Platform was supposed to be used by stores all over Switzerland, which means it had to be translated into German, as well as French and Italian

The Solution

Of course I first tried using the Symfony-native yaml translation files, though this was soon becoming a problem. Firstly it needed to be possible to store translations of user-generated content in the Database, which we couldn’t possibly translate in the project core. Secondly, we kept getting messages from our french-speaking partner about faulty translations, so we constantly had to change the files.

So, I went back to the drawing board, and what I came up with was a singular, central Database which stored all of our translations. The User class “Translator” was added to the system, which was able to edit translations in that DB – There was a translations page where they could search for whatever word they were looking for, in order to update its translation. And if they were on any page where they noticed an incorrect translation, they could simply highlight those words with, right click, and a custom context menu would open up with a text input field where they could change the translation to what it should be.

This Solution worked very well, but it was also very dangerous. As we weren’t using translation id’s but rather just the original string as key, I suspect an error was bound to happen (though it never did)

Platform Updates

The Problem

Soon enough we were pushing new features on a weekly basis, and even squashing bugs on the daily, but up to this point we’d always done these updates through manual FTP uploads, which just isn’t a viable solution in the long-term, especially not for a production system.

The Solution

So I got to learning Docker and GitLab CI/CD, and after about a month of learning to swim in the sea of containers, images and automation, I’d created a setup where I could just push to the git branch corresponding to the environment I wanted to update (dev/test/prod), and the server took care of the rest. It would create an automated database and file backup, build my frontend, and build my Docker images, and while all this is happening a nice “Update in Progress” Page is shown to visitors.

A version of this setup is still in use.

Setting all of this up really helped me fall in love with Docker, and now there isn’t a single coding project I do without Docker anymore.

Show-and-tell

Some notable parts I’d like to specifically show off

Dashboard

We knew there had to be some sort of Dashboard that would show some recent sales data, and other important metrics.

So I had devised a framework for creating new dashboard panels, and they could be as simple or as complex as you wanted them to be. A “Hello World” type panel could be realized in just 2 lines of twig templating code. But it was also possible to customize both how the panel loaded it’s data, and how it displayed it, independently of one another.

There were many hurdles to overcome when it came to displaying the panels themselves (order, positions…), which was great practice for sorting, recursive algorithms, and other coding challenges for me.

Now, if I had to make another Dashboard there’s a lot I would do differently today. But that doesn’t mean the functionality of what I’d built was bad – in the contrary, it is the one part of the application I am still the most proud of.

By the end, it wasn’t just useful for showing a sort of home page to the user, but we could use it in many different places. It also got used as the entity detail view, and a few other pages.

Evaluations

Data is a nice thing, but it’s worthless if there’s no useful way of working with and evaluating that data.

So I built a page, using the Dashboard Framework, which showed a number of panels which were responsible for printing evaluations of different data sets. There were some filters, like which date range was to be evaluated, or which specific insurance product. This gave you a table of the 10 most recent entries and a button to download an Excel Sheet with that data.