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.
Coordinating complex processes, both business and technical, can be a challenging issue in a distributed system. Especially when the complications associated with them, such as concurrency, idempotency, scalability and hindered testability, come into play — possibly all at once. This is definitely something that can keep many programmers awake at night.
So you’re new to Allegro, have just finished your tech onboarding and are stunned with information overflow? Or perhaps you are planning to join Allegro and don’t know what it looks like in here? I am about to try and describe how I felt just a few months ago and what startled or dismayed me. I hope this short article will answer all your concerns.
Many of us spend most of their software development careers improving and extending applications protected by pre-existing security mechanisms. That’s why we rarely address problems related directly to authentication and authorization unless we build apps from scratch. Regardless of your experience I still hope you will find this article interesting. It’s not meant to be a tutorial. I would like to focus on clarifying basic concepts and highlighting common misconceptions.
So I was tuning one of our services in order to speed up some MongoDB queries. Incidentally, my attention was caught by the size of one of the collections that contains archived objects and therefore is rarely used. Unfortunately I wasn’t able to reduce the size of the documents stored there, but I started to wonder: is it possible to store the same data in a more compact way? Mongo stores JSON that allows many different ways of expressing similar data, so there seems to be room for improvements.
Programmers who have ever developed software for Apple platforms in the early days of Swift language might remember ridiculous times it took to compile the whole project. For large and complicated codebase times used to range from 10 up to 40 minutes. Over the years our toolset has improved alongside with compilation times, but slow build times of source code can still be a nightmare.
