Have you ever worked on a project where after downloading the code from the repository you start to wonder what business requirements are hidden under the layer of unreadable tests? Or maybe you are currently wondering how to test a new feature that you have been entrusted to implement?
Everyone repeats like a mantra that tests are an indispensable element of development work. Is there anything to it? Well, I need to admit that as a developer, I rather often want to skip the test writing stage. I assume I’m not the only one. I’m aware that it’s a mistake, even with testers on board. Effective and efficient testing of your own code can help with catching bugs in new functionalities, as well as in changes to already existing ones. It cannot be questioned. Sometimes tests also help to understand how some long-unused functionality or component works. And that’s a small bonus too. Can a large project cope without testing? Probably so. But the number of errors and their severity will probably be much higher. That’s why in Allegro Ads we pay attention to writing tests.
Most of applications we create are basically loops. An average program waits for an event, then processes it following some business logic. Afterwards it begins waiting for another event to arrive. Java Servlets work this way too. Popular frameworks such as Spring allow us to only care about the business logic, while the framework takes care of the application main loop.
The source code of Allegro iOS app for buyers used to be divided into separate modules hosted in multiple repositories (polyrepo). The source code was migrated to a monorepo a few years back along with the history of all repos that constituted the app. Updating source code of a module on one repository could affect another module hosted on a separate repository. Versioning modules and propagation of dependency update led to long release process of the entire application. Our main repository for the iOS application thus became our monorepo. After 9 years of development of the app the repo size has grown enormously and the git clone command became a nightmare taking too much time. We had a possibility to shrink the project size during the migration from an on-premise to an external git repo hosting provider.
A new version of MongoDB, 5.0, has been recently launched. The list of changes included one that I found particularly interesting: the time series collections. It is a method of effective storing and processing of time-ordered value series. In this article we will verify whether the processing of time series is really as fast as promised by the authors.
The Clean Architecture concept has been around for some time and keeps surfacing in one place or another, yet it is not widely adopted. In this post I would like to introduce this topic in a less conventional way: starting with customer’s needs and going through various stages to present a solution that is clean enough to satisfy concepts from the aforementioned blog (or the book with the same name).
At some point in your career, you realize that it’s time to try to advance through the hierarchy. You think you are doing a good job. You are constantly developing and learning something new. But at the same time, someone you know, with much less experience and knowledge than you, has long been higher up the hierarchy than you. Then you ask yourself: what is wrong with me? In my case, the answer turned out to be properly gathering the expectations concerning my skills and work.
Micronaut is one of the new application frameworks that have recently sprung up. It promises low memory usage and faster application startup. At Allegro we decided to give it a try. In this article we’ll learn what came out of it and if it’s worth considering when creating microservices-based systems.
Every e-commerce platform needs some kind of central authorization system. At Allegro we use OAuth and have our own implementation that stays true to the RFC. Allegro has millions of users. There are also a lot of requests that go through OAuth services. At some point there comes a need to have better control over how much traffic we want to allow in a certain time window, while maintaining full performance of the platform. Here is where the idea of rate-limiting comes in handy.
This article describes a classic case of refactoring a search form UI component, a critical part of every e-commerce platform. In it I’ll explain the precursor of change, analysis process, as well as aspects to pay attention to and principles to apply while designing a new solution. If you are planning to conduct refactoring of a codebase or just curious to learn more about frontend internals at Allegro, you might learn a thing or two from this article. Sounds interesting? Hop on!
One of the key elements ensuring efficient operation of the services we work on every day at Allegro is fast responses from the database. We spend a lot of time to properly model the data so that storing and querying take as little time as possible. You can read more about why good schema design is important in one of my earlier posts. It’s also equally important to make sure that all queries are covered with indexes of the correct type whenever possible. Indexes are used to quickly search the database and under certain conditions even allow results to be returned directly from the index, without the need to access the data itself. However, indexes are not all the same and it’s important to learn more about their different types in order to make the right choices later on.
It’s easy to find resources about improving Elasticsearch performance, but what if you wanted to reduce it? In Part I of this two-part series we looked under the hood in order to learn how ES works internally. Now, in Part II, is the time to apply this knowledge in practice and ruin our ES performance. Most tips should also be applicable to Solr, raw Lucene, or, for that matter, to any other full-text search engine as well.
It’s easy to find resources about improving Elasticsearch performance, but what if you wanted to reduce it? This is Part I of a two-post series, and will present some ES internals. In Part II we’ll deduce from them a collection of select tips which can help you ruin your ES performance in no time. Most should also be applicable to Solr, raw Lucene, or, for that matter, to any other full-text search engine as well.
The main goal of boosting website performance is to improve the user experience. In theory, a satisfied customer is more likely to use a particular company’s services, which is then reflected in business results. However, from my own experience I can say that not every change can be easily converted into money. I would like to tell you how to reconcile these two worlds, how to convince the business that the benefits of better performance are a long-term investment, and how to streamline the development process during the design or code writing process.
Imagine you have to migrate your JavaScript project to TypeScript. It’s fairly simple to convert one file from JS to TS, but if you want to take type checking to the next level (going for TypeScript’s strict mode) it is not that easy. The only solution you have is turning on strict mode for the whole project which may result in thousands of errors. For most projects that are not strict yet, it would take quite a bit of time and effort to fix all the strict errors at once.
The following article is an excerpt from Software Mistakes and Trade-offs book. In real-world big data applications, the amount of data that we need to store and process can be often counted in the hundreds of terabytes or petabytes. It is not feasible to store such an amount of data on one physical node. We need a way to split that data into N data nodes.
It’s been over 5 years since the introduction of the article describing the ongoing transformation of Allegro’s frontend architecture — an approach that was later formalized by the industry under the name of Micro Frontends. I think that after all this time we can safely say that this direction was correct and remained almost entirely unchanged in relation to the original idea. Still, some of the challenges foreseen in the publication soon became the reality. In this article I would like to focus on the CSS part of the whole adventure to tell you about how we manage consistency and frontend performance across over half a thousand components, and what it took us to get to where we stand today.
Almost every modern web application somehow interacts with a backend - be it loading data, doing background sync, submitting a form, or publishing the metrics. Making API requests is not an easy task - we have to consider multiple outcomes and handle them properly. Otherwise, we might end up with confused users and decreased conversion. Although the stakes are high, it is still very likely to encounter an application designed with only a happy path scenario in mind. The question is - how can we improve it?
Some time ago, our team faced the issue of moving an existing Apache Spark job from an on-premise Hadoop cluster to public cloud. While working on the transition we came across another way to process data that is Apache Beam. We were curious whether this tool had more advantages in comparison to traditional Apache Spark. We wanted to find the answer relatively quickly with minimal effort. Hence, we built two projects to process the same data using these technologies. Below you can get to know the architecture of the jobs written in Apache Spark and Apache Beam.
I’m a big fan of logging as much extra data as possible. I’m also a DRY approach believer. I feel strong anxiety when I see repetition in code. Combining all these “passions” is not always easy. It’s hard to log everything without repeating things. Even if it’s possible, it usually leads to inelegant code.
Some time ago we announced that Allegro passes Core Web Vitals assessment and thanks to that we were awarded in “Core Web Vitals Hall of Fame”. It means that Allegro is in the group of the 27% fastest websites in Polish Internet.
Accurate forecasting is key for any successful business. It allows one to set realistic financial goals for the next quarters, evaluate impact of business decisions, and prepare adequate resources for what is coming.
The beginnings in a new job can be really tough, especially in such uncertain times as the pandemic. Remote onboarding, Zoom meetings, inability to talk face-to-face — it’s a big test, especially if you’re switching industries. My story is quite similar: in July 2020 I started a three-month internship at Allegro to train for product management. When the internship ended, I was offered to stay permanently as Junior Product Manager. I’d like to describe my beginnings at Allegro. But first — a few words about me.
According to Wikipedia there are approximately 700 computer languages available. Seven hundred. This is an unbelievable number and it’s the reason why programmers face the problem of choosing a programming language to work with, which frameworks to use and which tech stack to learn. All of them have pros and cons, but when looking for an all-purpose language you should take Kotlin into consideration and ask yourself the question: “Do I really need another programming language?”.
Maybe it’s another “How I’ve changed my worklife” story, but I hope it is an interesting one. It seems quite important to tell: before the beginning of my Allegro adventure, I was working as… an archaeologist. It was both physical work on excavations and research work at my PhD studies. And the only thing that connects my past work and the current one is: attention to detail.
