The post title says ten years, but to be precise, it has been 10 years and 10 months until I decided that it is time to end my long-term employment at heureka.group and start looking for something else. And it was a hell of a ride!

TLDR? #

If you want to know just the too-long-did-not-read version, meaning primarily list of technologies I have worked with, then check my About me page.

How it started #

I joined Heureka when it had around 20 people in August 2013. At that time it was PHP+MySQL project. I was programming from about when I was 15 years old, but I started experimenting in Delphi, C, Java, C# and bit of PHP. So I was by no means a pure PHP programmer, but I successfully passed the code-challenge I was given at the so-called “test day”. I remember being there from 8AM till 7PM without lunch pause (no time to waste!) until I felt the task is somehow finished up to my liking.

By the way thanks Vit for reaching out to me with the job opportunity and mentoring me in my beginnings ❤️.

So what have I been doing there all those years? I will split this to separate parts, because over time, I was involved in multiple projects/eras.

Chapter one - Journey of PHP & MySQL (2013-2016) #

Since the Heureka’s monolithic codebase was already pretty big when I started, first was get to know how the whole system works, so I was doing some maintenance, bugs and chores to get the idea, which is, what I believe, how it works in every company when you are starting. After few months, the more serious work has finally started.

Internal tooling and administration #

The next stop where I was getting to know the other part of the codebase. This experience also confirmed, that I am inclined more towards back-end work. I will be honest and say that making front-end and UI is not something I have ever enjoyed, nor I know how to properly do.

XML feed downloading and parsing #

This was very nice experience, because we had about 20.000 e-shops (I think) sending us goods to sell in the XML feeds and the task was to download and parse them in time, and subsequently storing incremental changes found in the feeds to our MySQL database. At that time, we had no fancy tooling like Kubernetes etc. (did not exist at that time), so this was achieved using custom solution written in PHP that was able to spawn multiple “workers” at once to be able to process all that data. I would not call it big data at all, but this amount of data processing was not really common in the Czech projects at that time.

Billing process #

When I gained some experience and trust, I was involved in making some non-trivial changes in click billing processing (Heureka’s primary source of income at that time). This meant practical rewrite of legacy billing code and implementing some measures against “fake” clicks, that should not be billed to our partners.

Cross-sell in the marketplace #

I was involved in a task, that should make users of Heureka marketplace buy more things by recommending products that the user might like based on the data about orders of other customers.

It was a project where I took several paths until some usable result was achieved. Starting by writing some optimized SQL queries to get the data and processing it using cron-jobs, it was quickly discovered that we need to use other tools, because the cron-job was not really able to compute all that in reasonable timeframe.

So I had fun with trying out Hadoop and graph databases. The solution was deployed, but it did not unfortunately bring the desired business results and after some time the project was shut down. Nevertheless, I have touched some interesting technologies back then. But to be honest, I have never used them again from that time.

Verified by customers rewrite #

One of the cornerstones of Heureka are user reviews that are gathered via “verified by customers” programme. My team was in charge to rewrite the old legacy code and prepare new, fresh-looking version for the customers.

This project was not something I enjoyed that much and after some time I told my manager, that I might be up for some change.

Chapter two - iOS Mobile app (2016-2021) #

Around that time I was learning in my spare time how to develop iOS apps as a pet-project, and since Heureka had old and ugly mobile app that we “inherited”, and also managers were thinking that we should have new Heureka mobile app, we came to a conclusion with my former manager that we will form a brand-new mobile apps team. And I was one of the guys responsible for the iOS version that was written on the green field in the modern Apple’s Swift programming language.

For a long time, I was the only full-time iOS developer. We had one contractor throughout the time to help me, and we seeked another colleague to join us until we found Jakub who joined our iOS sub-team. Together we developed the “new” version of iOS app and were continually working on it.

Experience showed, that main pain point for mobile apps is the back-end - getting and preparing the data. Since there was no dedicated team for this matter, the new features in the mobile apps demanded APIs and data we did not have and no other team also could deliver it in reasonable time. So after some discussion (and also necessity) we started doing also the backend services for our mobile apps, both iOS and Android (created by Android mobile-apps sub-team of course).

After some short time we also “recruited” some Android guys, who wanted to help, to help us with the back-end. The number of services we needed to develop kept growing, and we ended doing about 40% of the iOS and 60% of the back-end in our sprints. We discovered that the mobile apps backend work is challenging, fun, but also never-ending, so after some discussions we settled upon creating new full-time sub-team: mobile apps backend team. So Me, Jakub and Peter from Android formed this new team and the company hired other iOS and Android devs to substitute us.

Chapter three - Mobile apps backend (2021-2024) #

The former experience creating apps itself has given us pretty good overview of the challenges of the mobile apps that we leveraged during the back-end services development.

Mobile apps development for service like Heureka is somewhat specific in a way, that usually single team in a company is responsible for developing and managing single business area (for example search team si responsible for search and nothing else, feeds team is responsible only for feeds etc.), but this does not work for the mobile apps, since our responsibility was to integrate every single customer-facing business area in Heureka into one mobile app, being it homepage, search, favorite products, user account, product reviews, you name it.

And since Heureka transformed into microservice-powered, cloud-native company few years back, one of the first things we needed to do was provide all this data to public internet via gateway.

REST Mobile apps gateway #

Mobile apps should not access the backends directly and that is the reason why first generation of the gateway was born. We designed it as a REST API written in asyncio Python using Sanic framework. It worked somehow ok, but over the time the REST showed its weaknesses, especially the never ending changes in models and consequently the need to update the documentation. We decided to try something different and after some time we settled upon trying the GraphQL.

GraphQL Mobile apps gateway #

We did quite a big research before trying this out, but the internet articles motivated us to do this. Majority of the code we written in the time was in Python, so we picked Strawberry GraphQL framework and went to build this second generation of mobile apps gateway. After some initial struggles (for example error handling in GQL) we eventually overcome them, and we had production ready GraphQL gateway deployment. This is what current mobile apps are using now (2024). Since it is business critical component, we have SLIs and SLO targets defined and in case of SLA breach, the alerts are triggered and the unfortunate person, who is on-call, is taking care of the issue.

OpenID provider #

Long story short, we needed some simple user authN & authZ solution for mobile apps. But at that time, there was no we could use, since existing legacy login solution was cookie based and thus, web-only and no team was available to write/provide some standardized solution. So our mobile apps backend team to the rescue! We spent some time studying the RFCs about OpenID Connect, OAuth2.0 and its extensions (like Proof Key of Code Exchange - PKCE) and we have written our simple OpenID Connect provider using Python + Redis for use in mobile apps. This solution served its purpose for few years with no problems and recently was replaced by new company-wide solution.

Product-detail aggregate database #

I was involved in the project of other team, as a temporary help for duration of about 6 months, and helped create a database with aggregated data for the most visited page in Heureka - what we call the product detail. The input data is flowing from various sources and teams in the event bus built using RabbitMQ. The task was to consume all this data. transform it if needed, and store it into the MongoDB database. The product detail is then fetching this data using GraphQL API layer built on top of MongoDB database.

Mobile push notification service - 1st generation #

Once upon a time, there came a product request for ability to send mobile push notifications to our mobile app users. We needed to build the infrastructure to be able to do that. This project ended to be quite a challenging task, where we designed a pipeline of microservices written in Go that provided this functionality and also providing the “history” of the sent notifications to the users. This was our first contact with Go, and it ended up to be one of the few services, that had almost no errors in our Sentry error log at all due to the strict Go’s error handling nature 🎉. I am by no means an experienced Go Programmer, and it was fun trying out new language!

Push notification framework aka The Notizz #

Since maintaining the mobile apps gateway is not super creative work, we wanted to do something challenging once again. Because we had former experience with sending mobile push notification, we wanted to build new solution based on the experience we gained previously. But this time, not only for mobile apps, but for the whole company a supporting multiple notification “channels”, being it mobile push notification, web push notification, e-mail, or SMS or whatever. Management gave us a green light, so or team conducted a lot of in-house interviews with various stakeholder to map their needs and expectations while we were working on the MVP.

This project was really close to my heart - reason is that our team came up with the idea, we successfully promoted it to the management who appreciated the effort, and we had lots of fruitful design and pair-programming meetings with Jakub and Peter throughout the time. After Peter recently left our team, this project had a big delivery speed hit, because our team shrunk to just 2 developers. Also, due to nature of the project, being company-wide, 2 people most probably could not develop and support it the way we wanted. So in the end, we handed the project over to other team in Heureka to finish it, because now, after careful consideration, I am leaving the company too. So I bet you guys will make our child come alive and top-notch, the way we designed it! 🤞

Other activities #

Tech talks co-organizer #

Heureka has an internal education/experience sharing platform called Tech Talks. Because I have a piece of mentor in me, I was member of the organizing committee. My duties were being a moderator, seeking people who want to present stuff, and I was also presenting myself there multiple times on various subjects like OAuth2.0, Clean Code and others.

Conclusion #

As I wrote in the beginning, it was a hell of a ride, and I had privilege to work with many wonderful people here and have tons of fun memories I can share over a good drink. Now I am curious where my path will continue. Peace!