DEV Community: Accesto

Insights from the PHP Foundation Executive Director

Michał Kurzeja — Mon, 14 Apr 2025 11:22:51 +0000

I recently interviewed Roman Pronskiy, who works at JetBrains as the Executive Director of the PHP Foundation and has been a PHP dev since 2010. In this interview, Roman shared his insights and vision for PHP. Roman’s experience offers a unique perspective on the evolution and future of PHP. In this post, I will sum up the topics we discussed, from the Foundation’s milestones and ongoing projects to what lies ahead for the PHP community.

The Emergence of the PHP Foundation

Firstly, I wanted to hear directly from Roman how the PHP Foundation came to be:

“JetBrains hired Nikita Popov around 2018 and worked closely with him on modernizing PHP. They realised that the current model for supporting the PHP language was not sustainable. Despite PHP being widely used across the globe — from small projects to giant enterprises — the responsibility for its maintenance and development fell on the shoulders of only a handful of people. Recognising this imbalance and its potential risks, JetBrains decided to initiate the project, ensuring PHP would have the backing of a larger, more sustainable group of contributors.” — Shares Roman.

The Evolution of Confidence in PHP’s Future

I asked Roman about how his perspective has evolved since the PHP Foundation’s inception. His first post on the topic was full of uncertainty about the PHP future because of Nikita leaving, so it was interesting to see the change of perception: “Absolutely, we started because we saw the problem, we needed to act. We did, and now there are no doubts in the PHP's bright future. PHP is turning 30 next year and it’s as good as immortal at that point (laugh). I see a lot of new faces joining PHP and a lot of excitement in the community.”

PHP Foundation’s Initial Steps

Naturally, the Foundation's road to where it is now was quite long, so I asked about its humble beginnings: “The Foundation’s primary focus in its early days was straightforward: pay developers to maintain the language.” Roman emphasized, “Right now, we maintain a great pace to deliver big features every year.”

Milestones Achieved in Three Years

Later our discussion drifted to the most memorable achievements of the Foundation during those three years. “First two years of PHP Foundation we were figuring out the basics, what we want to achieve, how we would proceed with that goal and what people should be hired for that job.” — said Roman.

Property Hooks and PIE Tool

When the Foundation truly started to shine it’s in its third year: “These were much-needed features that nobody wanted to tackle for years,” Roman explained. PIE, a tool designed to simplify the installation of PHP extensions such as Xdebug, significantly enhances the developer experience.

“Extensions are now very close to being like packages; they basically look like Composer packages. It’s still open to discussion whether PIE will be part of Composer someday. It’s not decided yet, but I hope it will be,” Roman added.

These and other quality-of-life improvements have made the current state of the language much, much better.

Security Audits

With support from a German government-backed agency, the Foundation conducted extensive security audits, identifying and addressing some flaws. A public report will soon detail these findings.

Modernizing PHP.net website

PHP Foundation not only focuses on PHP core development but also does its best to ensure the growth of PHP's popularity. It is hard to discuss a language's future without considering how it is seen by new developers joining the market, or returning developers assessing if PHP would be a good choice. PHP.net is supposed to be the “face” of the language, so we started this discussion there:

“For years, the official PHP website didn't even mention popular 3rd party tools like Composer that nearly everyone uses. That's finally changing.” Besides that, Roman highlights incremental improvements, including better navigation, interactive code examples, analytics, and a new “Why PHP” page.

I wanted to know more about the changes that were made to php.net and those that are still in the plans. So I kept asking, and I got some interesting information:

“Recently, we went through many code examples on the page and checked them for possible vulnerabilities. We would also like to add more marketing to the website, including some case studies of companies that used PHP to great success and other mentions, examples, and statistics of PHP success. If you think about it — their success is also partly ours, and few people know how many great products are built with the help of PHP”

On a side note, it’s obviously still an open-source project. As I learned during the interview — the top bar of php.net recently was changed, the change itself was suggested by one enthusiast who worked a couple of months on that change, which was later approved.

Overcoming Challenges: AI and Performance

I was also wondering what the Foundation identifies as the biggest challenges for PHP right now. Roman shared his thoughts on that topic acknowledging the dual challenges of AI integration and performance:

“We cannot ignore AI and the industry trends,” he emphasises. “While PHP isn't primarily an AI language, it is crucial to ensure it works seamlessly with AI technologies. This includes improving HTTP interfaces and API handling capabilities. For example, persistent curl handles were implemented for PHP 8.5, which could significantly improve performance for applications making frequent API calls.”

On performance, he cites community-driven initiatives like FrankenPHP, which combines PHP with a Go web server. “What we want is to enable the community and unblock them on any issues so they can build amazing things on PHP. We are constantly in direct contact with products like FrankenPHP and if they encounter any issues — we prioritise resolving them”.

Generics in PHP

The question of Generics in PHP arises basically on every PHP event I went to, clearly, that’s the topic that is on the mind of many PHP developers, so it was worth discussing. Responding to the community’s interest in Generics, Roman explains:
“We’ve invested heavily in researching how to tackle this. Our goal is to find the best solution for the community.”

PHP Foundation plans on scaling

I was interested in knowing if there are any plans to scale the Foundation's size in the near future.

“I would like to, but that definitely comes with challenges. First and foremost, there is the financial challenge. We are trying to plan the budget at least two years ahead to give our developers a sense of security. Second, as of now, we have 10 developers on board. Any more to that number will most likely require an addition to the leadership part of the team.

But for now, we would like to hire additional developers only for specific projects for a year or two. A good example would be the delivery of Generics we discussed prior. We also want to experiment with Rust in the PHP core, for that we would need someone extremely experienced in that specific area.”, Roman concludes.

Exploring Rust Integration in PHP Core

Intrigued, I wanted to know more about the reasoning for adding Rust to the PHP core.

“This is something we might like to try in 2025. It’s not about performance; it’s about safety and attracting more engineers. Starting with support for Rust extensions. You will be able to write extensions with Rust, install them with PIE and treat them as regular packages.”

Supporting the PHP Foundation

As a PHP developer myself and a co-founder of a company employing more than a dozen other PHP developers, I appreciate the Foundation's work and want to draw more attention to the ways companies or individuals can support it. So, I steered the discussion in this direction.

Financial Contributions

“The first and obvious answer to anyone who wants to help the PHP Foundation — You can always support us financially. All of our expenses are fully transparent and are published on our website.” — Roman starts.

Spreading the Word

“Articles, like yours, bring attention to our cause, help other developers and improve the community. We are also always happy to repost any valuable content on our social media to help those who support us.”

Roman also adds, “If you don’t have a direct line of communication with us — write public feedback, critique, suggestions, or anything that you find important. We would also happily share detailed case studies on how you used PHP to achieve success on our social media, as I mentioned previously — your product success is also partly ours.”

Providing Feedback

“Lastly, feedback from people like you helps us a lot. If you think about it, PHP core developers are not PHP developers themselves. They have a rough understanding of what they want to improve in the language, but I would bet that experienced PHP developers like you will have much-needed input for them to consider and address the issues better.

With the help of analytics on PhpStorm and php.net, we are getting some information, but the real feedback is even more helpful. I am constantly in discussions with PHP developers, and I am sure I will have some for you too, later on. A client can come to you and ask if they should upgrade to PHP 8.4 or rewrite the project in Golang, which is also the worst decision they can ever make. But If such concerns arise in your clients, you know where they stem from, and that’s extremely valuable information for us.“

Final questions

Wrapping up the interview, I wanted to know Roman`s favourite sources for keeping up to date with PHP news: “The research I do for my newsletter PHP Annotated is usually more than enough. I get the information by following and directly talking to cool people in the community on Twitter (now X), Bluesky, or Mastodon. This newsletter should cover all the news of the ecosystem,” said Roman.

Conclusion

As Roman Pronskiy aptly puts it, “PHP is as good as immortal.” As PHP approaches its 30th anniversary, the language continues to evolve at a never-before-seen pace — now under the stewardship of the PHP Foundation. With a focus on innovation, security, and community engagement, the future of PHP shines brighter than ever.

A brief history of PHP language & what we can learn from it?

Piotr Gołofit — Fri, 11 Apr 2025 10:05:02 +0000

This year PHP gets into its thirties 🎉 And on this occasion I would like to briefly summarise the history of PHP web development, to better understand the present and the future of the PHP programming language. I am pretty sure there is a lot we can learn from this story.

So let's begin...

It was in June 1995, thirty years ago... or wait, let's start even a bit earlier...

How did it all start?

It is November 1968 in frosty Greenland, when the future programmer Rasmus Lerdorf is born. The World Wide Web is still 21 years from being invented. And Greenland is still part of the Kingdom of Denmark, and no one is trying to buy it 😉

Would his parents know that Rasmus will become a programmer? Probably not, as the C programming language will be unknown for another few years.

Fast forward to 1994. Rasmus Lerdorf is working on his online resume. Yes, online, because the World Wide Web was invented in 1989 and became open to the public in 1993. He is probably one of the first to have a digital CV 💪

Rasmus wanted to track how many people had visited his resume. How would you do it back then? It was way before Google Analytics was launched. Heck, Google itself would be unknown for another four years! So what did he do? He coded himself a simple set of Common Gateway Interface (CGI) binaries first in Pearl and later in the C programming language, which eventually led to PHP being born. Here is his story.

"PHP began life as a simple little cgi wrapper written in Perl. I wrote it in an afternoon during a period between contracts when I needed a quick tool to get an idea of who was reading my online resume. It was never intended to go beyond my own private use. The web server where I had my resume was extremely overloaded and had constant problems forking processes. I rewrote the Perl wrapper in C to get rid of the considerable overhead of having to fork Perl each time my resume was accessed."

~Rasmus Lerdorf (source: https://www.php.net/manual/phpfi2.php)

From PHP Tools to PHP Foundation

Later more people using the same Web Server contacted Rasmus if they could use his wrapper. And as usual, if you give something to people, they keep asking for more. So Rasmus added more and more features to his toolset leading eventually to a semi-complete distribution along with documentation, a mailing list and a FAQ. How did he name it? A "Personal Home Page Tools", or in short, a PHP Toolset.

PHP/FI (aka PHP 1)

Back then, Rasmus also began experimenting with databases and developed a tool for seamlessly integrating SQL queries into web pages. This solution, essentially a CGI wrapper, parsed SQL queries and simplified the creation of forms and tables based on those queries. He named this tool a Form Interpreter or FI for short. And that's how a PHP/FI was born. By many called a PHP v1.

PHP 2

In 1997 the PHP acronym was formally changed to PHP: HyperText Preprocessor. In the second version of PHP/FI 2.0, Rasmus has completely rewritten the PHP and FI packages and combined them into a single program. It also evolved to the point, where it was a simple scripting language embedded inside HTML files. That's probably the moment where the term "dynamic web pages" was born, as PHP enriched static HTML sites with server-side generated content. And in this very way, it was to be known for many years to come, until web development got into templating and finally APIs and SPA applications.

PHP 3

In 1997, two Israeli students from Tel Aviv - Andi Gutmans and Zeev Suraski — reached Rasmus online regarding his implementation of PHP. They wanted to use it for their university project, but it was simply inefficient and lacking some features. So they started discussions around various aspects of the current implementation and their redevelopment of PHP. And that's how PHP version 3 was born. It introduced included object-oriented programming and was the first version that more or less resembles PHP as it exists today. Two years later Zeev and Andi would combine their first names to register their new company - Zend Technologies. You might have heard of it 😉

PHP 4

May 2000 brought us PHP version 4. It was the one which, among other features, introduced HTTP sessions and output buffering. Andi Gutmans and Zeev Suraski started working on it just after the official release of v3. Their goal was to improve PHP and its performance for larger and more complex applications. The result of their work was a release of Zend Engine 1.0 which became the core of PHP 4.

Thanks to OOP introduced in version 3 and new features from version 4, PHP became something more than just a simple scripting language for dynamic web pages. It evolved from a hypertext preprocessor to a fully fledged programming language for building more and more popular dynamic web applications and API's. It was around this time when the first ever RESTful API started to appear.

PHP 4 was also the first one that powered... WordPress 1.0! The very first public version of this popular CMS was released in May 2003 when most of the servers were running on PHP 4.1. This was probably one of the crucial moments in the history of PHP. It was also the spark that led to a famous statistic saying that PHP powered over 80% of the whole internet. A year later, a young Harvard student Mark Zuckenber (ever heard of him? 😉) will code thefacebook.com using PHP 4.

First logos of Facebook (named TheFaceBook back then) and WordPress from 2003/2004.

PHP 5

Quick jump to July 2004 and release of PHP v5. By this point in time PHP's development community comprises dozens of developers, along with numerous others contributing to PHP-related projects such as PEAR, PECL, and documentation. It is a huge success for PHP and it is believed that this programming language is currently installed on even hundreds of millions of domains worldwide.

PHP 5 represented a fundamental redesign of the language, featuring the new Zend Engine that improved performance while expanding object-oriented programming features with better syntax and functionality. It also added innovations like exception handling and enhanced error reporting. These advancements helped cement PHP's status as a powerful and widely used language for web development.

The first version of Symfony released in 2005 extended PHP code with many useful components.

The year 2004 and the release of PHP 5 was also a turning point for a passionate Perl developer Fabien Potencier. That's exactly when he decided to switch his focus to PHP and created the Symfony framework project (released a year later) to help his company leverage the power of PHP for complex web applications.

And what may surprise you, as of April 2025, still more than 10% of PHP pages use version 5!

PHP 6

Legendary 🦄 sixth version of PHP. How to summarise it? I think this comic does it pretty well:

No PHPun Intended comic about PHP 6.

And now being more serious - why PHP 6 was never released? The plan was to introduce deep native support for Unicode in PHP. Unfortunately, the number of technical difficulties around this implementation (including performance issues and backward compatibility) led to abandoning the PHP 6 project in 2010 and its Unicode features. Many of the non-Unicode features that had been developed for PHP 6 were incorporated into PHP 5.3 and 5.4 instead. For the next PHP version web developers had to wait for over a decade. But in the meantime, two important things happen to PHP. First of all, in 2009 we founded Accesto 😉 And a year later, Taylor Otwell released the very first version of Laravel. For some reason I see the first one as a more important fact - but I guess you may disagree 😉

PHP 7

This version feels like yesterday, but is already 10 years old! Released in 2015, delivered substantial performance enhancements (up to twice as fast as PHP 5.6 🚀) and reduced memory consumption. With its subsequent versions 7.1-7.4 added a lot of language features like the ?? operator, anonymous classes and return type declaration, just to name some.

PHP8

PHP 8.0 was released in 2020 with many new features (eg. named arguments, union types, attributes, null safe operator) and significant performance improvements (huge difference thanks to the JIT compiler). Further minor releases brought us enumerations, fibers, readonly classes, DNF Types, and typed class constants. And many more! An impressive list for just a minor release I must say.

The last PHP version (8.4) introduced property hooks, asymmetric visibility and array functions.

PHP.... The Foundation

November 2021 sets another important milestone in PHP history. Nikita Popov, one of the significant contributors to PHP is leaving the project. Is it the end of PHP? On the contrary! This event became a catalyst for a series of events which in the end led to the PHP Foundation being established. With its mission to ensure the long-term prosperity of the PHP language. From now on, PHP as a programming language has a solid team of core developers, contributors and supporters.

The goal of The PHP Foundation is to ensure the long-term prosperity of the PHP language.

What we can learn from PHP history for today?

The history of PHP shows that this was never a hype-driven language. Throughout its history, PHP wasn't the first one to introduce various features. It adopted object-oriented programming pretty late and for many years was pretty far from types. But at the same time, it never stopped evolving! PHP may not be up to date with what's latest or sexy and may not have all the sugar yet. But it is getting the modern syntax eventually. May not be the first one, but thanks to that, it does implement only those solutions, that proved to be useful in other languages and other technologies. And eventually, modern PHP code does not differ much from any other contemporary language used by web developers.

Getting mature, not old!

For the last 30 years, PHP has constantly developed and improved as a language. It wasn't getting old through these years! On the contrary, it was constantly evolving and adapting to modern web development.

How much more you can improve after 30 years of constant development? PHP shows that quite a lot. The last version 8.4 introduced property hooks, asymmetric visibility and array functions. But one thing is language features, another is better security and performance improvements.

And speaking of performance. Last month we upgraded PHP for one of our clients from 8.1 to the latest 8.4. Results? Approximately 15-20% performance boost:

Web transaction time was shortened by 15-20% after upgrading PHP to the latest 8.4 version.

We have already seen some good performance boosts in this project with previous upgrades within version 7 and version 8. So I wasn't really expecting any significant further improvements this time. But PHP continues to surprise me. After 30 years we can still expect some nice gains. Good job to all the core PHP developers! 💪

PHP was built out of necessity

Personally, I also like the fact that PHP was created by Rasmus Lerdorf to solve his real-life problem. And for years it continued to evolve in that very manner — driven by real needs, not by hype. Also the same was with the PHP Foundation. It wasn't established to gain power over PHP development or because having a foundation is cool. It was built out of a real need to support PHP and its growth.

Recently our CTO did a small interview with Roman Pronskiy, an Executive director of the PHP Foundation. Roman revealed couple of initiatives that will shape the future of PHP in the upcoming months and years. And of them are driven by real needs, not by hype. Examples? Introduction of generic types in PHP, and extensive security audits for PHP language, supported by German government-backed agency!

Happy birthday, PHP!

Some may think that a programming language that is 30 years old is a finished history. That after so many years we should not expect any new language features. But that's definitely not the case with the PHP! It may not be the first one that introduces various features, but you don't have to be first to be solid, reliable, and thanks to that... relevant. Personally, I like PHP because after 30 years it can still get better and better.

Queueing in multi-tenant SaaS systems. How to ensure its fairness

Michał Kurzeja — Wed, 13 Sep 2023 08:27:02 +0000

Queueing in multi-tenant SaaS systems is often introduced to improve the overall platform stability, improve the user experience and scale the system. When you browse the internet or ask some developers, it will often be mentioned as an easy-to-implement solution. Well, it is not always that way, and there are sometimes some pitfalls that you can encounter while doing this step.

What multi-tenancy and single-tenancy actually mean

Let's first discuss some basics, so we have a common understanding of:

SaaS (Software as a Service) — this is probably self-explanatory as selling software in this form is pretty common now. But quoting Wikipedia:
- SaaS is a software licensing and delivery model in which software is licensed on a subscription basis and is centrally hosted. SaaS is also known as on-demand software, web-based software, or web-hosted software
Multi-tenant — this means that the SaaS software you offer is serving multiple tenants/multiple customers using one instance. It does not matter if your instance is a server, multiple servers or serverless, the important thing is you have a shared infrastructure. Most SaaS companies are running using this model as it is way easier to manage and lowers the overall maintenance costs. In fact, only very specialized services, with high charges make sense not to be multi-tenant.
Single-tenant — opposite to multi-tenant. This means that in order to onboard a new customer, your tech team needs to set up a new instance of the app. Each tenant can also have a different version of the app (although maintaining too many differences often gets too expensive and hard to manage). This means, that in a single-tenancy system, each new customer runs a separate software instance. Each tenant can have multiple users that share the same instance.

Single-tenant vs multi-tenant SaaS architecture

The decision between multi-tenancy and single-tenant architecture is out of the scope of this article, but the basic rule of thumb is to choose what is important for you — the ease of management of multiple customers — probably hundreds and thousands, of being able to adjust every single tenant by adding custom code changes. Another decision driver for a single-tenant architecture would be a requirement of separate computing resources, data isolation, data security, and some specific legal requirements. In general, something we could summarize as tenant isolation.

What is the problem with queueing in multi-tenant systems?

Let us imagine a system where we have a long-running process that the clients execute. It can be anything — from processing a file (import a CSV, video format conversion), or anything else that makes sense — like crawling a page etc.

Now in such systems, it could happen, that one customer executes so many tasks that are queued, that his "tasks" pile up and form a long waiting queue to be handled.

If Client 1 executes 1000 such tasks, all other customers (2, 3 etc.) will have to wait until this one gets his 1000 tasks done. This happens because queues are by default FIFO — first in, first out.

In this case, Client 2 will wait for ages to get his one task done, will get quickly angry and can potentially cancel the subscription. Why would he wait an hour or two to get one simple conversion finished?

So we have one customer affecting the user experience of many customers, by consuming all the computing resources available.

What is fair processing in multi-tenant architecture

Before we jump into a bit more technical discussions let's quickly consider what we think is fair.

The quick answer is that one client causing a big load, should not cause harm to other clients. So we should process Client 2 and Client 3 from the image, and then continue with Client 1 tasks.

But to be honest, in lots of SaaS, we have different tiers of clients. Not all clients are equal. A client that has the lowest tier should probably have a bit less priority than a client on an enterprise Tier. This could mean, that f.e. our business decision is to handle clients in the top Tier four times faster than in the lowest one. This does not mean we process all tasks of the top tier first, we just process them a bit faster if the queue is full.

This might be considered unfair, but I would like to have my target multi-tenant architecture handle such cases.

Multi-tenant SaaS architecture — things to consider

In order to properly implement a multi-tenant architecture we need to consider the following related problems:

Single-tenant vs multi-tenant — data isolation

When you switch from a single-tenant to a multi-tenant approach you need to consider how you partition your data. Your application now stores data from multiple tenants/multiple customers in a single software instance, but the tenant's data should not be shared between them!

In short, the three multi-tenancy models for data storage are:

Silo - when each tenant has a separate instance of the storage, f.e. a separate database server.
Bridge - when each client data is stored on the same database server, but has a separate schema to store data.
Pool - when all clients share the same database (including schema), but the tables have columns to inform which tenant data it represents.

As you can see, the Silo approach is quite close to running a single-tenant architecture. In fact, for the db storage you need to create a single instance for each new customer. This can be automated and is a bit easier to manage than running a separate instance of the software per customer, but it still requires quite a lot of work and raises the maintenance costs. When you need to go the Silo way, it's good to consult with cloud service providers — they usually have articles explaining how to implement dedicated instances for storage using their cloud services.

This is quite an interesting discussion to have when planning your multi-tenant architecture. You can read more about it f.e. in this Amazon whitepaper

Noisy neighbour

Because multi-tenant SaaS software clients share the same hardware resources, it can happen that the activity of one of the tenants will have a negative impact on other tenants. I already touched the queueing part of it, but the same issue applies to other resources. F.e. a client executing many heavy actions that are not queued can cause a partial system outage that also hits other users. In this case, even when a user is not causing a big load on the system, he will encounter slow response times, errors etc. It happens not only when all tenants use a single database instance, but even if they only use the same software instance, as the CPU resources are shared.

Figure with 3 tenants, each consuming less the maximum throughput of the solution. In total, the three tenants consume the complete system resources.

You can read more about it in this Microsoft Documentation.

How to fix multi-tenant queueing?

While researching the web I found a couple of different solutions, let us quickly go through them and discuss the pros and cons.

1. Add more workers

This can definitely be considered as a first aid if the problem hits you. If you have a lot of consumers there might be a need for faster processing = lower waiting times. But let us be honest — this won't solve the problem. One client can still block the processing for others, and there is usually a limit of consumers that you can execute. Next to that, if the processing is using some external systems/APIs, you can easily hit the rate limits.

It is worth mentioning, that even when you use cloud computing with virtual machines that you can scale easily, there is usually a hard limit enforced by the cloud platform you use.

2. Request throttling

Did I just mention an external system could have a rate limit? Yup. When we hear rate limits, we usually tend to think about APIs. But we could introduce something similar in our app. Not always, but in some business flows, you can show an alert to the user, that he added too many tasks, and because of that — needs to wait a bit, or... just upgrade to a higher tier ;)

This does not solve the queue issue itself but could help limit the problem of a noisy tenant. You can set limits for tasks added within a minute, hour, day etc. Not perfect, but I think it's worth considering.

2.1 Request throttling with priority

Priority — connected with the tier the tenant is on, can be actually added to many of the described solutions. If you connect tenant priority with a rate limit, it can lead to some interesting results. Most queues support the priority of a message, and that will allow to process enterprise customers a bit faster.

3. Sharding

In this case, you can just split the tasks into multiple queues (each queue can serve multiple tenants). A simple solution could be based on the client number, like this:

In the example, I split the clients into 3 different queues. In this case, when Client 1 starts to process too many tasks, it will "only" affect 33,(3)% of the other tenants. Does not fix the problem, but definitely makes it a bit less painful (at least for some users).

3.1 Sharding, but better

This is something I did not see in any articles, but I've learned from one of our projects. You can actually come up with better ideas for sharding, than the client id.

As an example, we could have a default queue for processing tasks, but we can also add a queue for our "enterprise" tenants. Next to that, we can come up with queues for tenants that are known for high load and just process them next to the default queue.

In the project I worked for, there was a special "spike" queue, that was activated by a rate-limiting mechanism. If the system detected that a tenant was queueing too many tasks, he was moved to a "spike" queue.

4. Multiple instances - per tenant queue

Easy, elegant, powerful and not always possible. Just create an automation (using Cloudformation or Terraform), that sets up a queue for each new tenant. You can consider this to be the Silo approach described in the partitioning SaaS part above.

This is probably the perfect solution if you do not have too many tenants, and there won't be too many new each month/day.

In our case, we had thousands of tenants register every week, so a per-tenant queue was not an option. It would be a nightmare to manage, but also we would hit the limit of SQS queues within one week.

4.1 Processing this amount of queues

Another question is how to handle that many queues. Well, there are at least two options:

If the customers pay enough, you could run a consumer for each of them. Not perfect, but I think it would fit the Silo approach quite well.
You could implement a slim consumer that iterates through all the queues, and fetches max one new task from each tenant queue, then forwards the task to one shared queue. The "output" queue is then connected to your consumers - shared across all tenants. This approach is described by Simone Carriero in his article.

5. Switch what is queued

This is our case, and before I describe it I would like to underline, that it fits our needs, and might be considered a bit controversial. Yet, it has worked perfectly for over two years now ;)

A bit of background on what we had to handle:

We have quite a lot of new tenants every week;
Each new tenant starts by importing data from an external system;
An import might be just a few elements, but might also be thousands of them;
Data is imported from an external system that has rate limits — both for us and each of our tenants;
So when we hit the rate limit for Tenant A, we can usually still process Tenant B.

A "Default" approach to this would be to queue each element, as each of them needs to be fetched from the external API, and then processed.

This is obviously a terrible idea, as one import of 10000 elements will be processed for ~1 hour (due to rate limits), and tenants that import 10 elements will have to wait, although they could be served within 3 seconds.

So we decided to rethink what exactly we queue, and instead of queueing a certain element, we just queue the fact that tenant X import needs to be processed:

Next to that, we maintain a separate list of elements to be imported into the database.

A consumer receives a task to process import no. 1, fetches the next element for it, and after it finishes, it reschedules the task to the queue:

Rate limit adjustments

As mentioned, the system we are connected to has a rate limit enforcement both on our app, but also on the tenant level. Our app rate limits are quite big, and in 99% of cases, we hit the tenant limit. So it makes sense to slow down importing one tenant, in order to process others.

In the case of our solution, that was pretty easy to implement. First, we had to fetch the rate limit information from the external service. That actually already there in each response header. We have exact info on how many requests are left in a specified timeframe.

Based on that, we can calculate a delay — the closer we get to the limit, the bigger the delay gets. As the delay grows, the rate limit "recovers", and we can lower the delay.

Next, we pass the delay to the queueing solution:

Now the queue handles the delay and provides us only with tasks that we can run without hitting the limits.

Handling different tiers

As mentioned in the introduction, in most SaaS solutions there are different tiers of users, and we might need to process some users faster. Like a big enterprise account etc.

In our system, each tier has an assigned "multiplier" that tells us how many import tasks we should schedule for the import task. Based on that, we can manage the pace/velocity at which we import the data:

What is the perfect solution for your SaaS?

There is no one-size-fits-all solution for multi-tenancy queueing, and I doubt our approach will be the best one for all of you. I just wanted to light a spark, and make you think about a couple of things:

Although we (developers) tend to say queueing is easy, it is not. It is easy to implement, but it comes with quite a lot of problems you can hit, fair processing and data partitioning are two of them.
You might read about some battle-proven solutions described by well-known companies, but I think it is still beneficial to sit down and re-think the approach for your multi-tenant app. You might come up with something similar to what we did, that works a lot better in your case.

Multi-tenancy in SaaS is usually not easy, but to be honest I think in 95% of cases it is worth investing the time, as it makes maintenance costs way lower. So unless you are in an MVP phase, you should make the investment.

If you have any other ideas for solving queueing in multi-tenant architecture — let me know!

Creating Angular Tooltip Directive - Part 2: adding customisation

Piotr Gołofit — Mon, 17 Oct 2022 13:54:15 +0000

In my previous blog post, I explained how to create your own angular tooltip directive without using any third-party component libraries (like using angular material tooltip). Today, I will show you how to add more customisation to build a fully-fledged tooltip module.

Note: the whole code from this tutorial is on GitHub

Customising Angular tooltips

The tooltip directive created in tutorial part 1. should be good enough for many basic use cases. But in more complex situations, you may be tempted to install some dependencies to external angular tooltip libraries. Let's avoid this, and instead, let's take our own tooltip directive to the next level. Today, we will make it way more universal by adding a few features & options:

tooltip position (below, above, left or right);
tooltip themes (dark theme vs. light theme);
tooltip delay time (separate tooltip delay show & tooltip delay hide);
dynamic tooltip that follows the mouse cursor;
support for touch devices / mobile devices.

Without further ado, let's jump straight into the first customisation.

Tooltip position - angular tooltips in the right place

So far, our tooltip was always displayed below the parent element. Now we will add an additional attribute position that will allow us to display it more flexibly. We will allow it to be placed below, above, left or right of the host element:

export enum TooltipPosition {
    ABOVE = 'above',
    BELOW = 'below',
    LEFT = 'left',
    RIGHT = 'right',
    DEFAULT = 'above'
}

To keep our code nice and clean, let's create tooltip.enums.ts file, where we will define enum types for all the available customization properties. In addition to apparent options for TooltipPosition (above/below/left/right), you can also define a default position in our enum.

Now, let's update the ts file of our directive to accept the position attribute as an @Input:

export class TooltipDirective {

  @Input() tooltip = '';
  @Input() position: TooltipPosition = TooltipPosition.DEFAULT;

In part 1 of this tutorial we created a method setTooltipComponentProperties(). In that method, we calculated the position of our tooltip relative to the HTML element on which the user hovers (to display it right below it). New version of this method will have separate calculations for each of the TooltipPosition options:

private setTooltipComponentProperties() {
    if (this.componentRef !== null) {
      this.componentRef.instance.tooltip = this.tooltip;
      this.componentRef.instance.position = this.position;

      const {left, right, top, bottom} = this.elementRef.nativeElement.getBoundingClientRect();

      switch(this.position) {
        case TooltipPosition.BELOW: {
          this.componentRef.instance.left = Math.round((right - left) / 2 + left);
          this.componentRef.instance.top = Math.round(bottom);
          break;
        }
        case TooltipPosition.ABOVE: {
          this.componentRef.instance.left = Math.round((right - left) / 2 + left);
          this.componentRef.instance.top = Math.round(top);
          break;
        }
        case TooltipPosition.RIGHT: {
          this.componentRef.instance.left = Math.round(right);
          this.componentRef.instance.top = Math.round(top + (bottom - top) / 2);
          break;
        }
        case TooltipPosition.LEFT: {
          this.componentRef.instance.left = Math.round(left);
          this.componentRef.instance.top = Math.round(top + (bottom - top) / 2);
          break;
        }
        default: {
          break;
        }
      }
    }
  }

We will also define the position property in the .ts file of our TooltipComponent:

export class TooltipComponent implements OnInit {

  position: TooltipPosition = TooltipPosition.DEFAULT;
     ...

The value of the position property is assigned in the setTooltipComponentProperties in the code above. We will use it to set a proper modifier to our CSS tooltip class...

<div class="tooltip"
     [ngClass]="['tooltip--'+position]"
     [style.left]="left + 'px'" [style.top]="top + 'px'">
  {{tooltip}}
</div>

...to properly align our tooltip in the desired position:

.tooltip {
   ...
  &--below {
    transform:translateX(-50%);
    margin-top: 7px;
  }

  &--above {
    transform:translate(-50%, -100%);
    margin-bottom: 7px;
  }

  &--left {
    transform:translate(calc(-100% - 7px), -50%);
  }

  &--right {
    transform:translateY(-50%);
    margin-left: 7px;
  }
}

I am using a BEM notation, so it will be eg. tooltip--below or tooltip--left, but feel free to adjust it to the CSS conventions of your project.

Also, if you added a small triangle indicating the tooltip anchor point, you should also adjust it for new positions. Below is just an example of the right-positioned tooltip, feel free to check the repo for the full CSS here: https://github.com/accesto/angular-tooltip-directive

.tooltip {
   ...
    &::before {
      border: 5px solid black;
    }
   ...
  &--right {
    ...
    &::before {
      border-top-color: transparent;
      border-bottom-color: transparent;
      border-left: none;
      left: -5px;
      top: calc(50% - 5px);
    }
  }

And that is it:

  <div class="cat-icon" 
    [tooltip]="'Meow on the right!'"
    position="right">
</div>

Note: if your project setup (in tsconfig.json) requires angularCompilerOptions.strictTemplates you may need to import the enum type and use [position]=TooltipPosition.RIGHT instead of simple position="right".

Tooltip themes - angular tooltips that match your UI

Our next customisation will allow us to use our tooltip in both light and dark UIs.

Again, we will start by defining an enum type for our TooltipTheme options:

export enum TooltipTheme {
    DARK = 'dark',
    LIGHT = 'light',
    DEFAULT = 'dark'
}

Depending on the theme, we will adjust the tooltip background, and of course the tooltip text colour. We also have to adjust the tooltip anchor point (small triangle) to match the tooltip background:

.tooltip {
   ...
  &--light {
    background-color: white;
    color: black;

    &::before {
      border: 5px solid white;
    }
  }

  &--dark {
    background-color: black;
    color: white;

    &::before {
      border: 5px solid black;
    }
  }
   ...
}

And to make use of these themes, we have to pass the theme property to our component template the same way as we did with the position. I will skip that part here but feel free to check the complete code in the repo: https://github.com/accesto/angular-tooltip-directive

Tooltip delay time - instead of showing the tooltip immediately

Now, let's play a little bit with the tooltip behaviour. So far we just wanted to show the tooltip immediately when the user's mouse hovers over the selected HTML elements. But common practice is to show the tooltip after the user hovers over the tooltip's trigger element for a longer period (measured in milliseconds) - which may indicate that he needs some help or explanation. Let's add some delay time before we make our tooltip visible. Options are two - we can either instantiate our tooltip component after the delay, or do it immediately, but play with its opacity. I'll go with the second option, as it will give more options to control the potential show animations/transitions:

.tooltip {
  opacity: 0;
   ...
  &--visible {
    opacity: 1;
    transition: opacity 300ms;
  }
}

To control visibility, we have to define visible: boolean = false property in our TooltipComponent and use it in the class directive:

[class.tooltip--visible]="visible"

Let's now add setTimeout() to our onMouseEnter() method of our tooltip directive:

 onMouseEnter(): void {
   if (this.componentRef === null) {
       ...
      this.setTooltipComponentProperties();
      this.showTimeout = window.setTimeout(this.showTooltip.bind(this), this.showDelay);
    }
  }

  private showTooltip() {
    if (this.componentRef !== null) {
      this.componentRef.instance.visible = true;
    }
  }

Where this.showDelay (defined in milliseconds) will of course be another @Input() property of our angular tooltip directive. For formality, let's also clear the timeout if the user's mouse leaves the tooltip's trigger element:

  destroy(): void {
    if (this.componentRef !== null) {
      window.clearTimeout(this.showTimeout);
      ...
    }
  }

The same we can do with the hide delay. For that, we need to modify onMouseLeave() method of our angular tooltip directive:

   @HostListener('mouseleave')
  onMouseLeave(): void {
    this.hideTimeout = window.setTimeout(this.destroy.bind(this), this.hideDelay);
  }

Again, hideDelay will be an @Input() property that will define closing time in milliseconds. And of course, we also have to clear the timeout of our close delay in case the user hovers again over the parent element.

And that is it - see an angular tooltip example in action, with delays for showing and hiding the tooltip:

You could also add some hiding animation/transition after the hide delay, but I will leave that to you.

Dynamic tooltips - eg. when the user hovers over an area

Tooltips, as the name suggests, are often used to provide additional information on tools that users have in the UI. Let's assume you are building an online graphics editor. It's a common case, to show the mouse coordinates over the editor canvas. For that, we will need a tooltip that won't appear in one place, but will rather follow the user's mouse. For that, we will let our angular tooltips listen to pointer events, and update their position whenever the user moves the cursor. Let's call it a dynamic tooltip position:

export enum TooltipPosition {
    ABOVE = 'above',
        (...)
    DYNAMIC = 'dynamic',
    DEFAULT = 'above'
}

We could also define the tooltip position left/right/below/above the mouse cursor, but let's not overcomplicate this and stick to just the default behaviour. We will simply display the tooltip next to the cursor, and will hide the anchor point:

&--dynamic {
  margin-left: 20px;

  &::before {
    display: none;
  }
}

Listening to the pointer events is quite straightforward, we just need to add another @HostListener that will update the position of our angular tooltip whenever the user moves the mouse:

@HostListener('mousemove', ['$event'])
  onMouseMove($event: MouseEvent): void {
    if (this.componentRef !== null && this.position === TooltipPosition.DYNAMIC) {
      this.componentRef.instance.left = $event.clientX;
      this.componentRef.instance.top = $event.clientY;
      this.componentRef.instance.tooltip = this.tooltip;
    }
  }

You may be wondering why we also update the this.componentRef.instance.tooltip? It's because otherwise, we won't be able to dynamically update the tooltip content. This allows us to achieve tooltips like these:

Support for touch devices - mobile tooltips

Last but not least, we will focus on making our tooltip module compatible with mobile devices. What's different on mobile? Lack of the mouse pointer of course! So how we can show our angular tooltip if the user cannot hover his mouse over anything? It's quite simple actually. We just need to adjust our tooltip directive and in addition to pointer events, listen also to touch gestures.

First, let's determine what kind of gestures we want to detect. Shall we show the tooltip whenever the user taps (touches) some button or other HTML content? That would be quite straightforward to implement, but would actually prevent users from using that button. We still have to allow all the standard taps for the normal usage of the UI. Instead, let's detect the situation when the user long presses the screen over the HTML content. But how do we define the long press?

Unfortunately, there is no touch event that would express the long press. But no worries, we can combine touchstart and touchend events, to detect if it was indeed a long press.

So far we have been initialising our tooltip right inside the onMouseEnter method. Now, because we will have more than one trigger than the mouse, let's move the initialisation to a separate method:

@HostListener('mouseenter')
  onMouseEnter(): void {
      this.initializeTooltip();
  }

  private initializeTooltip() {
    if (this.componentRef === null) {
    ...

And we will use that method also after we detect the long press:

@HostListener('touchstart', ['$event'])
  onTouchStart($event: TouchEvent): void {
    $event.preventDefault();
    window.clearTimeout(this.touchTimeout);
    this.touchTimeout = window.setTimeout(this.initializeTooltip.bind(this), 500);
  }

  @HostListener('touchend')
  onTouchEnd(): void {
    window.clearTimeout(this.touchTimeout);
    this.setHideTooltipTimeout();
  }

  private setHideTooltipTimeout() {
    this.hideTimeout = window.setTimeout(this.destroy.bind(this), this.hideDelay);
  }

Simple as that, now our angular tooltips are ready for mobile devices. Cheers! 🍺

Summary

In part 1 of this tutorial, we created a custom angular tooltip directive for displaying very basic tooltips. Part 2. brought many customisations to our tooltip module. You should now be able to use it in most of your angular applications. Sure it still has fewer features than the best angular tooltip libraries (like an angular material tooltip), but if you miss some features, feel free to extend it further.

You can play with the default options & default values like default delay. You can add further settings like font size or passing custom css class. Or you can even consider creating an angular tooltip service, for non-manual triggers (to show/hide the tooltip programmatically).

I will leave it to you. And in the meantime, you can check the complete code of the angular tooltip directive from this tutorial here: https://github.com/accesto/angular-tooltip-directive

How to create your own Angular Tooltip Directive - a short tutorial

Piotr Gołofit — Tue, 09 Aug 2022 14:45:00 +0000

Tooltips may seem insignificant, shy, and sometimes neglected. But they are real superheroes of many user interfaces. And like superheroes, they appear from nowhere, right when you need them, exactly where the help is needed. But, what is their superpower?

Tooltips are really powerful at delivering information. They are a perfect way to provide contextual help, without overloading users with too much information at the first glance. Tooltips appear wherever users need some additional data or explanation. No sooner, no later. This allows you to maintain the UI nice, clean and minimalistic.

Tooltips are commonly used as a pop up tip to explain the meaning of various tools, buttons and icons

Providing help in form fields, explaining complex features or tools, displaying additional information over charts... There are many ways tooltips can improve the user experience of your application. So if you are a front-end developer building an app in Angular, there is a huge chance that sooner or later you will be adding tooltips here and there.

How to add tooltips to an Angular app?

Before we dive into creating our own Angular Tooltip Directive, let's see some other ways to add tooltips in the Angular app. One of the most popular ways is to use the Angular Material component library. It provides a large set of components that follow the Google Material Design system. Another common UI library that you can consider is ng-bootstrap - it is an Angular version of the previously most popular HTML/CSS/JS library in the world - Bootstrap. If you seek something more lightweight yet powerful, you can also check ng2 tooltip directive.

Examples of Angular Material & NG Bootstrap tooltips

So why should I create my own Tooltip directive in Angular?

With so many tooltip solutions available, creating your own tooltip directive may seem like reinventing the wheel. But here are some reasons why you still may want to consider building it from the scratch on your own:

Because you don't want to rely on yet another npm package or you just want to keep your app lightweight - without adding the whole Angular material to achieve tooltips;
Because you may need more customisation to your tooltip style (like light theme vs dark theme) or behaviour (eg. dynamic tooltips that follow your mouse - I will cover that in part 2. of this tutorial). You may also want to add some directive options like content type, custom hover options (animation, hide delay, show delay) or a support for touch devices / mobile devices;
Because you may be building a whole component framework for your app and want tooltips to be part of it;
Last but not least - because you may want to learn how to build angular structural directives, and although there may be some simpler directives to start with, tooltips will give you a good lesson.

So if you already decided to build your own tooltips, let's see how we can approach that task and what building blocks of Angular shall we use.

Tooltip as a Directive, Component or as Service?

It depends, of course 😉 The same way as a custom button in Angular can be implemented as a standalone component tag, or as a directive applied on a standard HTML tag. Today I will show you how to implement a tooltip in Angular as a directive because I find it the most common use case. Usually, tooltips don't live on their own (like Components) and don't need to be invoked programmatically (via Services). They are usually add-ons to existing HTML content, and that is where structural directives work best.

But as your use case may be different, you may consider implementing tooltips as an:

Angular Directive - plain and simple, just an add-on to existing HTML code, usually containing just a string or a short text;
Angular Component - when you need to place inside a tooltip something more sophisticated than a text or an image, eg. some additional data above an interactive chart, or even to make universal tooltips that can display any given content inside the ng template tag;
Angular Service - mostly if you need to programmatically add or manipulate tooltips from the TypeScript code, eg. from within the functions of other components or services.

Tooltips above charts - potential place where you can consider implementing tooltips as a components

Creating Tooltip Directive in Angular - step-by-step recipe

Ok, so let's start from the short todo list with the steps required to build our reusable tooltips:

Create a tooltip component with a template;
Define tooltip background and other styles;
Create a tooltip directive;
Add basic tooltip logic;
Wrap it up in the tooltip module;
Give it a test ride!

And here is a list of necessary ingredients for our Angular tooltip directive recipe:

1 component - to define a template and a style of our tooltip;
1 directive - to attach tooltips to HTML elements;
1 module - to wrap it all up and make it reusable.

Component, directive and a module?! You mentioned only a directive before! Yup, you got me! I did cheat on you, but just a little. You can actually achieve all of that with just an Angular directive. But having a component inside a directive (kind of) gives us a more convenient way for styling, and a module will help us to wrap it up and keep our code clean. So apologies, but I had good intentions 🙈

Note: you will find the whole code from this tutorial in our repository: https://github.com/accesto/angular-tooltip-directive

Step 0 - set up an Angular project or use your existing one

For those of you willing to reuse your existing project, just skip to step 1. but if you want to start from scratch, please open your favourite IDE, and in the terminal type in:

ng new angular-tooltips-tutorial

And follow the standard installation process of a fresh Angular project. After the project is up and running, replace the contents of app.component.html with a single button:

<button>Do something</button>

Or, with a cat icon.

Step 1 - create a tooltip component

Let's start by generating a tooltip component via Angular CLI:

ng generate component common/ui/tooltip

I like to keep all the common UI building blocks (like buttons, tooltips, labels etc.) in app/common/ui/directory, but of course, feel free to adjust to your preferences.
Our tooltip component will actually be just a nice wrapper for a template and some CSS, no fancy logic required, so tooltip.component.ts can be as simple as:

import {Component, OnInit} from '@angular/core';

@Component({
  selector: 'tooltip',
  templateUrl: './tooltip.component.html',
  styleUrls: ['./tooltip.component.scss']
})
export class TooltipComponent implements OnInit {

  tooltip: string = '';
  left: number = 0;
  top: number = 0;

  constructor() {}

  ngOnInit(): void {}

}

Later we will add some customisation, but for now, the only difference from an empty component boilerplate are three properties - tooltip, left and top. These will keep a tooltip text and position (tooltips will be placed globally within the browser window and we will be using position:fixed for locating them).

In the template, we just need to display tooltip text and attach its location to the left and top properties of a component, so HTML content of tooltip.component.html would look like this:

<div class="tooltip"
     [style.left]="left + 'px'" [style.top]="top + 'px'">
  {{tooltip}}
</div>

Simple enough, isn't it? Let's now add some basic styles to make template content look like an actual tooltip.

Step 2 - define tooltip background and other styles

Here is an exemplar styling with a black background, white font and some rounded corners, but feel free to make it your own:

.tooltip {
  position: fixed;
  background-color: black;
  border-radius: 4px;
  color: #ffffff;
  font-family: Arial;
  padding: 3px 6px;
  font-size: 13px;
  margin-top: 5px;
  transform:translateX(-50%);
}

As already mentioned, tooltips will work globally, thus position: fixed. Last line with transform:translateX(-50%) will ensure that tooltip self-positions itself horizontally.
You may also want to define some max width or z-index, but I will leave that with you. Right now, let's maybe just add a nice triangle indicating an anchor point:

.tooltip {
(...)
  &::before {
    content: '';
    width: 0;
    height: 0;
    border-left: 5px solid transparent;
    border-right: 5px solid transparent;
    border-bottom: 5px solid black;
    position: absolute;
    left: calc(50% - 5px);
    top: -5px;
  }
}

So the overall tooltip will look like this:

As for now, we aim to display the tooltip below the HTML element, but in part 2. of this tutorial I will explain how to add some additional usage options - including tooltip location/direction, show delay or closing time. But first, let's finally create an Angular Tooltip Directive.

Step 3 - create a tooltip directive

Directives can be created via Angular CLI in the same way as components:

ng generate component common/ui/tooltip/tooltip

Mind the additional /tooltip in the path, as we want our directive to be generated in the already existing folder with a component.

Now, let's declare, inject and import a few objects that we will need inside our directive:

import {TooltipComponent} from "./tooltip.component";

@Directive({
  selector: '[tooltip]'
})
export class TooltipDirective {

  @Input() tooltip = '';

  private componentRef: ComponentRef<any> = null;

  constructor(
    private elementRef: ElementRef,
    private appRef: ApplicationRef, 
    private componentFactoryResolver: ComponentFactoryResolver,
    private injector: Injector) {
  }
}

We start by importing our tooltip component class, as we will create its instance (via component factory) every time we want to show a pop-up tip to your users. We also need a few objects to be injected into our constructor:

elementRef - we will use it to access the HTML element on which we place the directive tag, eg. a button or a link, to check its position in the browser window;
appRef - reference to a whole app, that will allow us to inject our tooltip to the application HTML content globally;
componentFactoryResolver - that will provide us with a factory for creating our TooltipComponent programmatically inside the TooltipDirective code;
injector - that will provide Angular dependency injection for our TooltipComponent.

Then, we declare a componentRef property, to store the reference to a TooltipComponent, which we will be instantiating via the factory.

Remember also to provide a meaningful selector name for the directive. I just used a [tooltip] for convenience, but you can name it eg. [appTooltip].

Then, let's define an attribute that we will use to pass as an @Input() to our tooltip. Right now we just need a tooltip content, so you can name it simply a tooltip or something like tooltipText.

Again, for convenience, I stuck with the tooltip as it allows me to simplify the syntax, and use the directive easier. So instead of:

<div appTooltip [tooltip]="...

I can skip the selector part and simply write:

<div [tooltip]="...

That is of course, convenient, but may sometimes cause you trouble if a tooltip property conflicts with some other directives you may have, so watch out!

Step 4 - add basic tooltip logic

After having all the groundwork done, let's implement some tooltip logic. We will start by creating an actual tooltip on hover, or more precisely onMouseEnter.

@HostListener('mouseenter')
  onMouseEnter(): void {
    if (this.componentRef === null) {
        const componentFactory =
              this.componentFactoryResolver.resolveComponentFactory(
              TooltipComponent);
        this.componentRef = componentFactory.create(this.injector);
        this.appRef.attachView(this.componentRef.hostView);
        const domElem = 
              (this.componentRef.hostView as EmbeddedViewRef<any>)
              .rootNodes[0] as HTMLElement;       
        document.body.appendChild(domElem);
        this.setTooltipComponentProperties();
    }
  }

This method will be listening (thanks to @HostListener) to mouse pointer events relative to the DOM element, on which we have applied our tooltip directive. Event mouseenter is emitted each time the user's cursor starts to hover above our DOM element. When that happens, we first check if our tooltip does not exist yet (using its reference this.componentRef) and if not, we will move on with its creation:

First of all, we need to use the resolveComponentFactory to get the factory that can manufacture our tooltip component;
Then, we use it to create the component, passing the dependency injector;
Next, we attach our component to the virtual DOM of the whole app, via the appRef;
We also attach it to the real DOM via a standard document.body.appendChild;
Last but not least, we define and invoke methods to set up the position and title of our tooltip.

This method for setting up the properties would like this:

private setTooltipComponentProperties() {
  if (this.componentRef !== null) {
    this.componentRef.instance.tooltip = this.tooltip;
    const {left, right, bottom} =           
          this.elementRef.nativeElement.getBoundingClientRect();
    this.componentRef.instance.left = (right - left) / 2 + left;
    this.componentRef.instance.top = bottom;
  }
}

Method description is quite straightforward:

Access to this.componentRef.instance allows the use of an actual instance of our component so we can set up its properties like tooltip text (I did access component properties directly, but I encourage you to define some setters instead);
getBoundingClientRect() - allows us to get the HTML element location and based on that calculate the tooltip coordinates relative to a browser window.

That is how we handle hover, now it's time to take care of tooltip hiding:

@HostListener('mouseleave')
  onMouseLeave(): void {
    this.destroy();
  }

  ngOnDestroy(): void {
    this.destroy();
  }

  destroy(): void {
    if (this.componentRef !== null) {
      this.appRef.detachView(this.componentRef.hostView);
      this.componentRef.destroy();
      this.componentRef = null;
    }
  }

There are two situations in which we have to make sure that our tooltip hides: when we hover out (mouseleave event), and when the element on which we applied our angular tooltip directive is destroyed (ngOnDestroy).

And... that's it! Let's only wrap it up and we are good to go.

Step 5 - wrap it up in a tooltip module

Again, we will use the Angular CLI:

ng generate module common/ui/tooltip

And inside the module, we will declare our component and directive, and will export our final Angular tooltip directive:

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import {TooltipComponent} from './tooltip.component';
import {TooltipDirective} from './tooltip.directive';

@NgModule({
  declarations: [
    TooltipComponent,
    TooltipDirective
  ],
  imports: [
    CommonModule
  ],
  exports: [TooltipDirective]
})
export class TooltipModule { }

And... done. Let's now give it a test ride.

Step 6 - give it a test ride!

To use tooltips we just have to add our TooltipModule in app.module.ts:

...
import {TooltipModule} from './common/ui/tooltip/tooltip.module';

@NgModule({
    ...
  imports: [
    ...
    TooltipModule
  ],
    ...
})

And we are ready to apply the directive like this:

<div class="cat-icon" [tooltip]="'Meow!'"></div>

or for a button:

<button [tooltip]="'Some explanation'>Do something</button>

And that was it - you can now hover above your button (or a cat 😺) and see how our tooltip appears:

How can we improve our Angular tooltips?

That was just a very basic tutorial on building your own angular tooltip directives. Bear with me and wait for part 2. in which we will extend this with many useful customisation and usage options. Part 2. will include:

Tooltip hide delay / show delay;
Tooltip position: above/below/left/right;
Dynamic tooltips that follow the mouse cursor;
Tooltip themes eg. dark vs tooltip background;
Default options & default values like default delay;
Tooltip showing and tooltip hiding animations;
Support for touch devices / mobile devices.

Cheers! 🍺

Equal or identical. How to compare variables?

Michał Romańczuk — Wed, 27 Jul 2022 05:50:13 +0000

== or ===? How many equal signs to put up so that it is correct and that nobody in the code review has a problem with it? Why is it so tricky in PHP?

Type Juggling

In PHP, the type of a variable is defined by how it was used*. Depending on what we have assigned to variable, it becomes that type¹. What does it mean?

(* From PHP 7 we can define types of method arguments, from 7.4 it is possible to define types of class properties!²)

$foo = "1";  // $foo is string
$foo += 0;   // $foo is integer
$foo *= 1.5; // $foo is float

In example above, string "1" has been assigned to the variable, so variable is string type, then integer 0 was added to it so it changes its type to integer. After that, let's multiply the integer variable by float 1.5. The variable is now float type.

This example shows how automatic conversion is performed by operators, in this case adding and multiplying. It is enough that one of the sides of the action is of the float type, then both will be treated as float and the result is also going to be of this type. The case is similar with integer although float is "stronger" and in the case of integer + float both sides will be treated as float.

Unequal equal

Let's get to equality, first look at the php documentation³ :

Equal: $a == $b, TRUE if $a is equal to $b after type juggling.

Sounds trivial and looks natural. Type juggling results in that, there is no need to think too much about what we compare, all is done automatically... ;) but is it?

Time for a quiz, will the following conditions be met?

0 == "eleven"
0 == "wtf-1.3e3"
1 == "\n\r1\t"
10 == "10 - 10"
"-1300" == "-1.3e3"
9223372036854775807 == "9223372036854775811"
"1.00000000000000001" == "1.00000000000000002"

Now attention, drums... in each of above cases it will be true. What just happened here? The, so far, highly intuitive comparison operator has now behaved in a manner rather unnatural to the eye.

How does the comparison operator actually work? To find out, it's best to look at how it was implemented⁴. However, this is not a simple reading, because the code is very complicated there. In short, the operation of == depends on the type of its arguments. Pairs of argument types are defined. If a given pair is supported (it is known how to compare it), the result of the comparison is returned, but if the given pair of types is not supported, the arguments are cast to another type (Type Juggling) and are only then compared.
In most cases this works in a predictable manner, but there are pairs of types that can surprise.

numeric value - string with a number and something extra

When string is compared with integer or float, then the string is cast to a numeric value, but this casting can sometimes be surprising.

10 == "10 - 10"; // true

In this case, the value of string is cast on to the integer, if string starts with a number, then whatever goes after that number is ignored. In this case "10 - 10" will not be the result of subtraction, so not 0 but 10.

numeric value - string with a non-number at the beginning

0 == "Lorem ipsum dolor sit 0"; // true

If string does not start with a number, then along with a numeric value it will always be cast on to 0.

numeric value - string with a big number

9223372036854775807 == "9223372036854775811"; // true

The integer from this comparison is the maximum integer value - PHP_INT_MAX (on 64-bit platforms), the string on the other hand includes a number slightly higher, just at 4 ;). In this case the integer will be cast to float, so the string eventually also to float. Such is the nature of float.

So never trust floating number results to the last digit, and do not compare floating point numbers directly for equality.

It's a warning from PHP documentation⁵ so it's better not to compare float values directly, but use dedicated functions:

numeric value - string with a number and white characters

1.0 == "\n\r1\t"; // true

White characters are ignored when casting to a numeric value. If you look at the example above you'll find one "\n\r1\t".

string - string

When comparing two string values it would be natural if it were true when they are the same ;) but what does it mean "the same".

"\n1" == "\r1"; // true
"1.0" == "\t1"; // true
"1e0" == "1";   // true
"-0.5e-2" == "-0.005";  // true
"1.00000000000000001" == "1.00000000000000009"; // true

"10" == "0xA";  // true  PHP < 7
                 // false PHP >= 7

When comparing string type arguments, at the beginning both arguments are cast to a numeric value. If it succeeds, they are compared as numerical values. Interestingly, PHP can do a lot of tricks when searching for a number in string⁶. Scientific notation or leading whitespace are not a problem, as well as hexadecimal notation up to version 7.0.

object - object

If it was too clear and predictable up to now, it works a little different when comparing objects.

class Example {
   public $property = 1;
}

$foo = new Example();
$bar = new Example();

$bar->property = 1.0;

$foo == $bar;    // true
$foo === $bar;   // false

Considering what I wrote earlier, everything in the example above is correct. The $foo and $bar variables are of the same type (Example class), their property ($property) in $foo is equal to 1 (integer) and in \$bar is equal to 1.0 (float). Thus, the result of the == comparison is true. Because the values match, types don't have to (integer vs. float). For === the result is false because the class property types do not match?

$baz = new Example();
$qux = new Example();

$baz == $qux;    // true
$baz === $qux;   // false

What happened here? Both variables are of the same type and their property is of the same value and of the same type, and still the result of === is false.
When comparing objects, identity (===) will return as true only if the same instance of the same class is compared⁷ . Yes. It is not enough for a variable's type (class) and all its properties to match, it must be same object. Comparison == will compare the object type and compare all its properties (also with ==).

So how should I compare?

In the examples I showed, it is clear that using the == comparison, sometimes may give a result different from what we expect. How to deal with this? Every time you write == (two equal signs), a red light should start flashing. We should always use the identity operator === (three equal signs), which also compares the type of the variable and does not cast anything before that. Well, almost always.

The only time we can use the equality == instead of identity operator === is when we do it intentionally and we have reasons for that!

Strangler pattern approach to migrating applications - pros and cons

Michał Kurzeja — Mon, 11 Jul 2022 07:10:27 +0000

The strangler pattern is a common approach to rewriting, modernizing and migrating existing (legacy) software to a new approach/solution/implementation. We already covered some topics related with it in the past. Mentioned it as one of the alternatives for system rewriting, and described a case-study migration in one of our projects. But it seems, that strangler pattern is gaining more and more visibility in recent years, and this is not a surprise for us.

Strangler pattern comes with a good set of pros that it brings to a project. Also, the toolset that are now available to developers allow to easily perform this kind of migrations on living systems. Let’s take a deeper look at some basics, and the pros and cons that arise from them.

Strangler pattern approach

Let’s focus on the very basics first. What does the strangler pattern mean?

Well, in this pattern, we start with a legacy system that we need to rewrite, modernize or migrate to something newer. Quite often such legacy systems use some outdated technologies, frameworks, libraries, and their overall complexity makes it very hard or even impossible to refactor the code bit by bit.

Our first step with the strangler pattern is to put an intermediary facade in front of the old system. In that case, all requests need to go through the facade, before they reach the legacy system.

As a next step, we decide what part of the system (what service) we would like to migrate. Let’s assume we work on an e-commerce system. We could decide to migrate the home page first. In that case, we write this part of the system from scratch, using a greenfield approach. You can choose the tech stack, the architecture - everything. There are no major constrains. In our case, we usually decide to use Symfony, and an event-driven architecture.

The new system is built next to the old system:

When the team is finished with the development, and the new code is tested, we can adjust the facade and move the traffic for home page from our old system to our new service.

Following this approach, we can migrate the legacy application part by part. There is no need to work with the legacy code, all new features can be implemented in the new system. You maintain the old application, and at the same time add functionality to the new system. By following the strangler pattern approach, you can pay back the technical debt and add new features at the same time. Eventually, the new architecture will be completely replacing old code.

Pros and cons of strangler pattern implementation

Pros

Minimize risk of migration by splitting the migration process into smaller, separated chunks of work. Divide and conquer!
Allows to quickly deliver business value and achieve visible results - rewriting a small subset of features takes significantly less than rewriting the whole system.
Has no major constraints regarding the software architecture and technology behind the new system.
In most cases, the development effort required to rewrite the entire application is lower than in other approaches
Easy to implement and understand. The code complexity is rather low.
Works well even when refactoring a complex system.
Allows to implement microservices architecture and split the work between multiple development teams. But as there are no constraints on the software architecture, you can also apply it to a monolithic application.

Cons

Requires a lot of attention to the boundaries between old and new parts. Connection points, data exchange, etc.
As a result of the above, might require to write lots of Adapters.
It is quite easy to break some best practices and end with a dependency hell.
Sometimes rollback scenarios might be hard to implement, and you obviously should have them.
When implemented wrongly, the parts might become tightly coupled.

Summary

As always, using a software pattern comes with some consequences. You literally exchange one problem for another one. There are no silver bullets, but by knowing different approaches you can decide on what problems mean less risk for you.

In case of strangler pattern, you exchange the huge risk of rewriting a legacy monolithic application into smaller, less risky changes. You iterate faster, in a more agile way. There are obviously some consequences that arise, and you should be aware of, but smaller failures are always easier to fix, and that's what the Strangler fig pattern offers you.

Boy scout rule in 6 examples - the basic principle of web development

Michał Romańczuk — Mon, 20 Jun 2022 09:23:56 +0000

Not everyone was a scout in his youth. Most of programmers, however, have probably heard of the Boy Scout Rule in software development. But can you name a few of the activities that are part of that rule? When I started to explore this topic, looking for what exactly needs to be done to say "I just applied the boy scout rule", I only found one thing: "Leave your code better than you found it" - everyone quotes Uncle Bob. But what does it mean? What am I supposed to do exactly?

In scouting it is easier, everyone can see if the surroundings are clean, what can be cleaned to make it cleaner, but in the code? I will try to show you a few examples from my daily work where I try to stick to this principle.

Most of us use some IDE, they are getting smarter and in many cases, they keep the code clean, suggest better solutions, "clean up" automatically with one click. However, it's worth keeping an eye on what's happening in the code and not rely entirely on the IDE.

The campground, not an entire forest!

I am allergic to multiple blank lines. When doing a code review, I also pay attention to what the code looks like. The code must be readable, multiple blank lines, in my opinion, are disturbing. So I sometimes leave a comment in CR like "one blank line is enough (everywhere)". One day my colleague got it a little bit differently than I meant. That merge request before my first review contained 7 changed files. What was my surprise when I saw it after applying the changes - 350 files changed… he removed multiple lines from the whole project. You can not do this, such changes introduce a huge disruption to the code, the MR becomes completely unreadable.

You can't go overboard with cleaning. “Leave the campground cleaner than you found it”, the campground, not an entire forest!

Code cleanup should be limited to the files we work with. If we add a new method to the class and we notice something that can be improved/cleaned up "next to" - this is the place where we should apply the Boy Scout Rule.

Examples in practice

a) deprecations

If you use a smart IDE, it probably detects deprecated methods. The IDE I'm using strikes out deprecated names. Below, you can see crossed-out annotations @ Route and @Method. Something like that is very noticeable, it's hard to miss it.

Inside the classes of these deprecated annotations, I found lines like this:

This is a very easy change to apply. They say what exactly we have to do. Just like in the screen below. A few seconds change and one thing less hurts the eyes.

It was an outdated annotation, now an example of outdated method. More crossed letters below. Method setData(). Just like a moment ago. It cannot be overlooked.

A good scout will not ignore it. It is like a plastic bottle on the ground in the campground, that needs to be cleaned up. So just check this method, maybe the author left a hint. And I did it:

Again, we have exactly what to replace.

And the last one. We're using some vendor class here that is deprecated.

Just open it:

And another quick change

Of course, if you are using a less wise IDE, looking for deprecations is not that easy. Nobody in their right mind opens every class and method they use to look for information about deprecations. We just use what we know, usually without much thought. Therefore, it is worth using tools that support our work.

b) unused code

The code changes very often, especially in the early stages of development. With changes, sometimes you miss to delete an unused import, variable, or method.

A smart IDE detects unused code, for example, turns unused private methods to gray. This also works for unused imports, unused private properties and parameters.

But you have to be careful, I never trust the IDE completely, it is better to double-check that deleting a piece of code won't break something. Of course, your code is fully test covered, so you can be sure nothing's broken ;).

It's not that easy with public methods, they don't turn gray automatically ;). You need to be more careful with them. When you stop using some public method, let's just check to see if it’s used somewhere else. If not and no one needs it anymore, let's get rid of it.

We should remove unused code. That's what we use version-control systems for, so we don't have to see "maybe it will be useful someday" unused code. (YAGNI)

c) naming

We have to name many things in our work. Variables, methods, classes, everything must have a name. What should a good name look like? Not too long, not too short, and clear to anyone who can see it. It is not easy at all. I believe that this is a key part of our work. A badly named variable can mess up a lot and add a lot of work to others who later have to get into our code. It should be understandable without thinking. After reading the name of the method, the names of its arguments, and what it returns, we should know exactly what it does, without looking inside.

When I see the name of the variable $a, $var, $arr or $array in the code review, I immediately get a fever.

And below is an example of a variable with the two-letter name "ac". To know what it will contain, you need to look where something is assigned, it is easy to find if it is a constructor, and not always it will be there. It is obvious to the author of this code at the time of writing that "ac" stands for "authorizationChecker". But not everyone will figure it out, even the author after a while may not be sure what "ac" meant.

A good scout, seeing such a variable, will quickly change its name to clean up a bit. For example, such a change is enough:

Don't save on letters or you'll pay for it later trying to understand what the abbreviations mean.

d) code formatting

The worst thing I have seen about improving code formatting is to use autoformat in the IDE all over the project directory ("not an entire forest"!). Let's clean around the place where we work, but not too far, one file or one method is enough. Someone who reviews the code should be able to focus on important things and not scroll through hundreds of non-essential changes.

"My formatting is the clearest and most readable" - every programmer. Everyone has their own taste and habits, so you need to agree on the details of code formatting in your team. You probably have your standards in the project you work in. However, there is one thing everyone should follow - the PSR-12 (If you missed, the PSR-2 is deprecated).

Let’s see some examples.

one-line IF.

Very unreadable:

Just add a few spaces and new lines

or a short IF syntax

multiple blank lines

I don't know why, but very common

Just be a good scout and remove unnecessary blank lines

strange indentation in the code.

Are you uncomfortable reading it too? When you see something like this in the code, you can easily do the right thing and correct the indentation.

all other things incompatible with PSR-12

Boy Scout is not looking for whom to blame, but clean code himself, leaving the code better than he found (DO NOT apply this rule in code review, such things must be eliminated immediately! ;))

e) complex conditions

How many times have you wasted time trying to understand a complicated if condition? For me - too much. Worse, with many conditions, it is often easy to get confused (if you have tests, you are a lucky scout)

I made up an example below. let's say it's a method that handle some response. It first checks if the response is valid, if so, does something with it.

It is not overly complicated to analyze, but it does take a moment to analyze what is being checked here.

A good scout will find a few things here that he can clean up so that others will enjoy reading the code. But the most important thing is to separate the entire condition into a separate method whose name will clearly say what the condition checks.

Of course, in this example condition, many other things can be improved ;). But the point here was that we took the time to understand what it checks, so let's make it easy for other people not to waste that time.

f) code duplication

Why do we find duplicate code in projects? If something works in one place, it will work in another ;). But there is one problem. If you want to change or correct something later, you must remember to do it in all places where you copied the code fragment. Mindless copy-pasting is unacceptable and no one should do it. But we often see that it happens, all the time. When a good scout sees duplicate code, he just clean it. The smart IDE notices that the code is duplicated, it should alert you.

Here is an example to show what I'm talking about

We have two methods here, even if you search, you won't notice the difference other than the function name.

The first method sends an email with some positive decision, and the second method sends an email with some negative decision. For some reason, instead of extracting common code, someone just copied it.

Then, you have the task to change the title of sent emails, and you noticed what it looks like. Now you have two options what to do. First one is to only change the title in both places. If it works, why not? Well, NO! A good scout would do more than that. He'd clean up that piece of code.

It doesn't take much time, and the code is a bit cleaner and easier to maintain.

g) what else?

Anything that will improve the readability of the code or its maintenance. You are not doing it for others, you are doing it for yourself in the future.
Doing more serious refacotring (eg. to ensure SOLID princinples) may not be a quick job. But all the examples shown above can be done in less than a minute. This is well invested time. It will pay off in the future.

Need further help?

Boy Scout rule is a good practice that helps to keep the technical debt low. But sometimes it is just not enough. If you are no longer able to cope with the code of your web application just contact us. We help our clients fight the technical debt in legacy PHP & Javascript applications.
__

Making sure your website won't crash again

Piotr Gołofit — Fri, 17 Jun 2022 06:55:26 +0000

In my previous blog post, I wrote about situations when an increase in user traffic could cause your website a lot of trouble. Unexpected popularity, instead of bringing you new customers, could cause the web services to go down. Today I would like to share with you a story from my own experience, a lesson learned from the spectacular crash of a popular startup. How did it happen? How did it recover? And how this spectacular disaster hardened the website and made it ready for the future?

A successful startup gaining traction

SzukamLapka is a very popular polish website that advises on purchasing laptops. It helps both IT newbies, and more tech-savvy customers as well. Its AI-driven algorithms review specs, benchmarks and offers to "understand" the industry and generate personalized rankings of the best gear.

Advice on purchasing laptop for non-tech and more tech-savvy customers

As Accesto, we have been their partners since early, MVP stages of SzukamLapka. This year they are launching a global version under the brand NotebookRank, but a few years ago, they were just a local startup, growing and gaining traction on a polish market. But in the late Monday evening of August 2017, this growth got out of control...

Surviving the hug of death

Almost every country has its equivalent to Reddit or Digg websites - places where users share, rate, and discuss useful links. In Poland, it is Wykop.pl, and on that day, someone who considered SzukamLapka to be very useful shared this knowledge with Wykop users. And it wasn’t the only person who found the named service worth using...

In the first hour after being mentioned the number of visitors doubled, but that was just a beginning. The exponential growth continued for the next 5 hours, reaching almost 10,000% late evening. That is a hundred times more users than usual!

Google Analytics: 1,000% increase in day-to-dday traffic, and 10,000% in the peak!

Usually, it is called a Reddit Hug of Death, or a Slashdot Effect, and in Poland... a Wykop Effect. It derives from the names of popular websites that caused many other sites to crash due to the abrupt increase in short term traffic.

So what happened?

Probably you won't be surprised if I tell you that the website crashed. But, to be honest, we were a little bit surprised back then. The website was already prepared to handle quite high volumes of traffic. It was optimized and performed well. Even when we did load testing with 20× more users than on an average day, all the rankings were generated in under 1 second. But sometimes you can't spot the bottlenecks until you see them stuck.

So what may be the bottleneck of a website that displays laptop rankings? The thing is that it isn’t just a simple website. Like most of the modern digital products, it is a complex web application, a multi-layer platform that consists of many services. And the bottleneck emerged between two of such services. The one that does all the complex calculations, and the other that uses these bare technical data and makes them more human-friendly. The question arose, why even though these two were connected via a robust and lightspeed API, the problem occurred?

Both services were performing very well, but sometimes the connection between them was lost for a few short milliseconds. And that was the part that we did not take into account. Although this was a very short break in communication, one of the services, instead of retrying to connect, kept hanging for around 3 minutes. We didn’t notice it in advance as it happened only once every few thousand page views. And of course, we had a few services like this working in parallel. So if one user waited too long, he could easily refresh the page and get the results immediately from another non-hanging service.

But on that day, the volume of users was so high that this quite rare situation of stuck service happened on all the services, and users started to get 504 errors - indicating that the server did not respond in time. The site went completely down.

Solving the problem

The temporary solution was quite simple. When we diagnosed the problem, we quickly increased the number of available services and restarted all the stuck ones. We had to repeat this few times, as new services kept hanging. But in general, that temporarily solved the problem and allowed us to survive till the morning.

The next day, we started by making sure that last night's nightmare won't happen again. We did it in 4 steps.

Step 1: adopt the fail-safe approach in your web application

We already knew that there could be temporary connection issues with the API, and to handle this, we added proper timeouts and retries. So if the connection is lost, service does not wait long, and after a second or so, tries to connect again. And there are few attempts, each with slightly longer timeouts (to get the response even if the network connection is slow for some reason).

According to Murphy's law, if something can fail, it will fail, and it is true also for web applications. It is good practice to take potential failures into account and make web apps ready for them by design. This is known as a fail-safe approach and is especially important if you integrate with some external, third party API’s - which may not always be available, or behave in the way we expect.

Step 2: make sure you calculate same things only once

Although the connection with the API should no longer cause the trouble, we knew that this was the most compute-heavy part of the platform. So the fewer requests are sent to that API, the better the website performance would be. We used Blackfire.io to check how often the web app uses the API and we got interesting results. We noticed that the homepage, the most frequently visited page, used the API twice per each view. Why would a rather static page even require any API calls?

Ranking sneak peak in header was calculated on every page view

The reason was that on the homepage, there was a small sneak peek of the ranking, to engage users. There were also a couple of statistics shown, as the total number of laptops or offers analyzed. But how often did these numbers and results change? Every few hours. And how often did we calculate them? Every single page view. Huh. Adding an HTML cache for the whole homepage worked like a charm, making it just a static HTML resource, that can be served by servers in a quite effortless way.

Blackfire is a very good tool that helps to find bottlenecks. To learn more, make sure to read our recent blog post “My homepage is slowing down” in which our developer describes how he reduced page loading time by 93% in just 4 hours of work.

Step 3: learn your user's behavior and use it to plan the performance

Another optimization became easy when we analyzed data from Google Analytics. SzukamLapka generates personalized rankings based on the individual needs and preferences of the users. But according to Google Analytics, most of the users go for the predefined presets, like gaming, office, or mobile laptops. So why generate them for every user separately? Adding a Redis cache for most frequently selected rankings reduced the computations by almost 70%.

Step 4: use CDN to cache your static resources

Last but not least - we added Cloudflare. It is a service that provides an additional cache layer in front of the whole website and distributes all its static resources in CDNs. It makes the assets, like images or scripts, highly available for users, and light for the server.

Cloudflare reduced bandwidth by 60% and page load time by 80%

Adding Cloudflare saved around 60% bandwidth traffic, making the website significantly lighter for the server. At the same time, the user experience improved thanks to the reduction of the total load time to less than 1 second! To learn more about caching with Cloudflare, check the blog post of our CTO on "Top 5 hacks to fix slow web applications".

Fast forward

Thanks to this lesson learned, the website was adjusted, and right now can handle a significantly large number of users. After a few years SzukamLapka is playing an important role in consumer decision making in Poland, generating millions in revenue for its partners. This year, SzukamLapka is launching its global version in multiple countries around the world. Thanks to the lessons learned, it is prepared to become popular in the new markets.

Current version requires less than 1 second to be full interactive!

How about your web application?

The story of the SzukamLapka startup can happen to almost every online business. If you want to check how your web application can be hardened just drop me a message. At Accesto we look after, monitor, and improve web applications to make sure they are secure, scalable, and ready for growth.

Let us help you

Optimizing website? Careful with lazy loading!

Piotr Gołofit — Thu, 05 May 2022 10:02:30 +0000

A few weeks ago I was asked if Accesto could help to optimize a popular online store selling natural cosmetics. Of course we can! I thought. That is what we do for a living, we improve existing web applications like SaaS, marketplaces, or eCommerce sites. Thus I thought it would be an optimization like every other. But it wasn’t.

Quick wins for website speed

Although every online product is unique, they usually struggle with similar web performance pitfalls. Non-optimal database queries, poor caching, too large images/resources, or unused imports, to name a few. Usually, there are a few things that can be fixed relatively quickly and will result in quite a speed boost. Our CTO recently gathered such tweaks for you in his blogpost on top 5 hacks to fix slow web applications.

Top performance, which will hold the exponential growth of users, cannot be achieved overnight. But if your website is slowing down, and you haven't yet put a lot of effort into its optimization, there is a high chance that it can be refined in a quite reasonable time. Like in one of our recent stories where we managed to decrease website loading time by 97% in just 4 hours of work.

Initial PageSpeed results for online store selling natural cosmetics

The case of natural cosmetics eCommerce seemed similar. The store owner sent me an email on Friday morning with the Google PageSpeed Insights report. It evaluated the overall site performance on 61/100 for desktop, and 42/100 for mobile. Not a tragedy, but indeed a lot of room for improvement. Great! We will apply a few quick tweaks that will speed up the website and I will have good news for a customer even before the weekend!

Let’s start with a website audit & checking Core Web Vitals

We already knew the overall score for this website - our starting point for optimization. This score is a composition of 6 metrics evaluated by PageSpeed, which for that particular site presented like this:

](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/50jualml4g4hqdi74z7f.jpeg)

Quick look at the metrics and we see that 4 out of 6 metrics look fine (Web Vitals), but the remaining two: Speed Index and Largest Contentful Paint (LCP) seem way too high. Understanding these metrics helps to decide where we shall start our optimization, how much we should improve, and whether we can find some low-hanging fruits. Each of these metrics has a different weight (importance). To see how exactly they influence the overall score you can use the scoring calculator.

Although PageSpeed evaluated both SI and LCP as poor ones, LCP has a higher weight (25%), so improving it will have the highest impact on the overall score. LCP is one of 3 important metrics introduced by Google, called Core Web Vitals. Ok, but what exactly is this LCP? In short - it is the time at which the largest visible part of website content is painted. This content could be an image, a large block of text, or any other element that occupies a significant part of the screen when the website loads. And the faster this element is displayed to the user, the better.

Knowing that, we could assume that perhaps some product image or banner is too large, not scaled properly, or maybe not compressed. Or maybe images are served by PHP and not cached? Few basic checks should show us what is going on.

We used a Lighthouse tool built-in Chrome web browser to profile the website. We were looking for any performance pitfalls, but the audit results were… surprisingly good! The site wasn’t performing that bad at all! Server response time was quite decent, images were served in a modern format and with proper sizing. All the site assets were properly optimized and served with proper cache policy. They even used some of the Progressive Web App capabilities to make the site work smoothly.

Lighthouse built in Google Chrome Developer Tools can be used to audit the website performance

Ok, so maybe it was a traffic related issue? Maybe site speed is good as long as the number of users using it is low? Worth a try. It is quite a common situation, many websites are tested only on a small number of users. When the user base grows website starts to clog. More on that topic you can read in my post on why new users can kill you web application. I did a few checks with the website load testing tool k6.io, but nothing, still a decent response time.

We also dug into the code to do some checks, but it only confirmed what was already obvious to us. Someone already did a great job to optimize this website. We weren't asked just to do the basics, they know how to do that themselves. We were asked because none of the popular tweaks worked. Great, finally some challenge!

Profiling the website performance

It was a time to dive deeper and do a step by step analysis. First of all, we had to figure out which site element was taken to calculate the LCP. Performance tool built-in Google Chrome shows a precise timeline of all the elements requested, loaded, and painted. It also indicates moments when LCP and other metrics are measured.

Analysis of this timeline confirmed our assumptions - the Largest Contentful Paint element was one of the product images on the homepage. Why is this image displayed so late to the user? We checked the image format and size, and all looked good. Actually, the image itself was loaded in just 122 milliseconds. So why did this image appear after almost 6 seconds if it loads in just a fraction of that?

We analyzed the timing of that particular image, and what surprised us was that it started to load after 5.7s since the website was requested. But why? Server response time was decent and all images should begin to load as soon as the browser receives the HTML from the server, right? Well…

Lazy loading done wrong

The title of this article already revealed the diagnosis - yes, it was a lazy loader that delayed fetching that image. But why? Isn’t the lazy loader one of the most common mechanisms that improve the website speed?

Lazy loader prevents images from being fetched if they are not in the current viewport. This minimizes the amount of data transferred in situations when only part of the site is seen by the user (eg. user views only the top of the page). Usually, it is good and makes the website load visibly faster. Usually...

Unfortunately, it also has a side effect that not every web developer is aware of. The lazy loader is simply a javascript code, that checks the image position and calculates whether it is in the current viewport. But this means that before the image is fetched, the web browser has to fetch the Javascript code and run it. The user won’t see the image until Javascript decides that he should see it. And that causes a delay.

And of course, there are many ways to implement the lazy loader so that delay is minimized. But in our case, the code responsible for lazy loading used an external, third-party javascript library that had to be fetched first. And what is more, this code was implemented in an onload event handler, which means that it was executed only after all website elements finished loading - including styles, fonts, scripts etc. And that all took 5.7s. It's quite a long time to decide if an image should be downloaded or not, isn't it?

Results of website optimization

There are many ways to solve this problem. We could get rid of the dependency on the external library or execute the lazy loader earlier than in onload. But the quick fix was to simply switch off the lazy loader for images that are always seen above the fold (the portion of the webpage that is visible without scrolling). This simple solution took just one line of code and did a job. Just see how the website speed improved:

It took us a few hours to find the cause of the poor LCP and finally add this single line of code. Website optimization is usually not about coding, it is analytical work of searching, digging, and investigating. Of course, this wasn’t the end of the optimization, still room for improvement. But we were surprised how much Core Web Vitals score improved with a simple fix in a lazy loader. This made me curious so I also checked other popular eCommerce websites and I was surprised. Many of them did have the same issue! Seems that lazy loader is seen as a great, out of the box solution for optimization, but very often added carelessly. And adding it too quickly (too lazy?) may actually harm the overall site speed. So be careful and don’t add stuff to your site just because everyone does it!

Legacy code - strangle or tame?

klobermajer — Mon, 18 Apr 2022 07:51:11 +0000

For me, as probably for every programmer, legacy code is something that I do not want to deal with. It is always not well written, hard to read, and very complicated.

Unfortunately, the world is not a perfect place and we must do it on a daily basis. The first thing we want to do when we are starting to work with a new legacy project is to rewrite everything from scratch. Such an approach in most cases will not work too well, it will take much time to deliver, it will stop introducing new features for a long time and do not bring any value to customers during this period.

A better approach is to rewrite step by step, one module at a time. Let legacy live with a new codebase, arm in arm. It can be achieved by using a strangler pattern. Unfortunately, such an approach is also not always possible. Sooner or later you will face the situations when the requested feature will touch almost every part of the system or there will be no part left that can be rewritten at once in a reasonable time.

From strangling to taming

Let me tell you a story about one of our projects which we started two years ago. It is a task management software with a lot of features and integrations with external systems. This software was developed a few years before we took it. It was used by many customers back then and nowadays it is getting more popular from month to month. Our main goal at the beginning was to make it faster, more robust, and more scalable.

We started as always by collecting as much knowledge about the domain as we can, then extracted some modules as refactoring candidates and get into coding. Refactoring a few modules took us almost a year. Almost a year with no big visible changes for the users.

The big disadvantage of refactoring legacy code is that it has no visible value for customers, even if it is a huge improvement for us, developers. Our hard work at this stage will pay off in the future for sure, but we should also give some value to users during the whole process, not only at the end.

This is why it is so important to properly design new codebase architecture and use possibilities it gives to parallelly refactor and introduce new features.

New architecture

Architecture should be always adjusted to project requirements, each project has specific characteristics and requirements. In our case, because of external systems integrations, and more integrations on the horizon, events were a very important part that we wanted to introduce. Based on that we decided to go with CQRS.

CQRS - Command Query Responsibility Segregation

Probably you heard about this more than once. It is known for some time and a commonly used approach. It allows us to separate responsibilities, to separate domain, and make code clear and easily extensible.

Base principles:

each change must be done by Command
each Command has one Handler
each change can dispatch Event
each Event can have multiple Handlers
fetching data from the database is performed by Query
each Query has one Handler

Taming

At some point in time, we decided to reduce refactoring activities and focus more on introducing new features, to finally make something visible to the customers. And so we did. We introduced a couple of new features in already refactored parts. Unfortunately, quite soon, we hit a wall. It was no longer possible to add something without touching legacy code, and such refactoring will always require too much time and it will probably end up with refactoring the whole system. Too many parts are connected.

Use events

Is the refactoring always really needed? Maybe we can add new features without refactoring?

One of the features that we wanted to implement was the notifications module. It is obvious that notifications are connected with many modules. And it is also obvious that from a business perspective it is not acceptable to refactor all these modules just because of notifications.

Luckily it is not required, we can prepare domain events for legacy code and dispatch such events when needed. The actual job will be done by a new code in event handlers.

Example

In this example, I will show you how we can notify the user when he was assigned to a task in our system.

Let’s start with the code currently responsible for assigning users to the task.

<?php

namespace App\Legacy\Controller;

class TaskController
{
    public function assignUsers(Request $request, int $taskId)
    {
       $users = $request->get('users');
       $taskHelper = $this->get('taskhelper');

       if (!$this->taskExists($taskId)) {
            return new Response('NOK', 404);
       }

       if ($users !== null) {
           $usersIds = explode(',', $users);

           foreach ($usersIds as $id) {
               if ($this->userIsAssignedToTask($taskId, $id)) {
                   continue;
               }

               $taskHelper->assignUser($taskId, $id);
           }
       }

       return new Response();
    }
}

<?php

namespace App\Legacy\Service;

class TaskHelper 
{
    private $repository;


    // … 

    public function assignUser(int $taskId, int $userId)
    {
        $this->repository->assignUser($taskId, $userId);
    }
}

This is just an example code, but you can get the idea of what kind of legacy we are dealing with. Of course, we can inject some service from the new codebase to TaskHelper and use it to create a notification. Such a solution will work but will be less extensible. The solution which I recommend here is to dispatch a domain event and let the handler do the job.

<?php

namespace App\Task\Domain\Event;

class UserWasAssignedToTask
{
    private $taskId;

    private $userId;

    public function __construct(int $taskId, int $userId)
    {
        $this->taskId = $taskId;
        $this->userId = $userId;
    }

    // … 
}

<?php

namespace App\Notification\Infrastructure\Event\Handler;

use App\Task\Domain\Event\UserWasAssignedToTask;

class NotifyUserAboutTaskAssignment
{
    public function __invoke(UserWasAssignedToTask $event)
    {
        // here you can do everything you want
    }
}

Now we have a nice event and handler in the new codebase, let use it in legacy to tie everything up.

namespace App\Legacy\Service;
use App\Task\Domain\Event\UserWasAssignedToTask;

class TaskHelper 
{
    private $eventBus;
    private $repository;
    // ...

    public function assignUser(int $taskId, int $userId)
    {
        $this->repository->assignUser($taskId, $userId);
        $this->eventBus->dispatch(
            new UserWasAssignedToTask($taskId, $userId)
        );
    }
}

Now when we have it all in place, each time when a user is assigned to a task, a new event will be dispatched and handled. We can easily extend the functionality of our handler, we can also add more handlers, e.g. log this in some event log, or propagate this change to some external system.

What if you want to reuse legacy code?

Another new feature we wanted to implement were automated actions. The user can set some rules which will perform actions based on some condition. For example, when a task is finished it should be assigned to the proper user. Not too complicated, looks quite easy to implement.

But what if all actions which should be performed are in legacy (in a non-reusable form)? E.g. Method in Symfony controller handles the whole logic.
Should we refactor all those places? How much time will it take?

Use command

What we can do is to add commands and handlers for all actions we need. Commands will contain all data needed and the handler will wrap up legacy code. We will not refactor anything in this process, just take it as it is and put in a new shiny box called “command handler”. Of course, this will not pay off the technical debt we had in legacy but allows to introduce new features easier and faster. And what is most important, will allow us to refactor smaller parts in the future. One command handler is for sure easier to refactor than the whole legacy controller/service/module.

Thanks to that we can easily use this code in a new codebase, not only it will be reusable but also it will be in line with the new approach.

And this was what we did, code we needed was extracted to handlers, and replaced everywhere in legacy by dispatching command.

Example

I will use code from the previous example. We will refactor TaskController to a new approach. Of course, this example will be shortened to just show the concept. In our project, there is much more logic behind this feature.

Let first prepare the command

<?php

namespace App\Task\Domain\Command;

class AssignUserToTask
{
    private $taskId;
    private $userId;

    public function __construct(int $taskId, int $userId)
    {
        $this->taskId = $taskId;
        $this->userId = $userId;
    }

      // …
}

and handler

<?php

namespace App\Task\Application\CommandHandler;

use App\Task\Domain\Command\AssignUserToTask;
use App\Task\Domain\Exception\TaskNotExistException;

class AssignUserToTaskHandler
{
    private $taskHelper;

      // ...

    public function __invoke(AssingUserToTask $command)
    {
        $taskId = $command->getTaskId();
        $userId = $command->getUserId();

        if (!$this->taskExists($taskId)) {
            throw new TaskNotExistException($taskId);
        }

        if ($this->userIsAssignedToTask($taskId, $userId)) {
            return;
        }

        $this->taskHelper->assignUser($taskId, $userId); 
        // now we can also move event dispatching from TaskHelper to
        // this command handler 
            // (but I will leave this at it is for now)
    }

      // … 
}

Probably you noticed that I moved some parts of TaskController to the handler also, it is always a good idea to make such small improvements boy scout rule.

Now we can adjust TaskController.

<?php

namespace App\Legacy\Controller;

use App\Task\Domain\Command\AssignUserToTask;

class TaskController
{
    public function assignUsers(Request $request, int $taskId)
    {
       $users = $request->get('users');
       $commandBus = $this->get('command_bus');

       if ($users !== null) {
           $usersIds = explode(',', $users);

           foreach ($usersIds as $id) {
              $commandBus->dispatch(new AssignUserToTask($taskId, $id));
           }
       }

       return new Response();
    }
}

Looks quite easy, right? Probably you are wondering why we did this, not much changed in the code, the handler is still the same legacy code but in a different place. TaskController looks almost the same.

Let me remind why we did this. We did this to introduce automated actions.
Thanks to the command/handler approach we can easily do this.

Our example automated action should work as follow: When the task is finished then assign the proper user to this task.

Let first add TaskFinished event


<?php 

namespace App\Task\Domain\Event;

class TaskFinished
{
    private $taskId;
    // ...
}

Then we can add a handler for our automated action.

<?php

namespace App\Automations\Infrastructure\Event\Handler;

use App\Task\Domain\Command\AssignUserToTask;
use App\Task\Domain\Event\TaskFinished;

class AssignUserOnTaskFinished
{
    private $commandBus;

// ...

    public function __invoke(TaskFinished $event)
    {
        $taskId = $event->getTaskId();

        if (!$this->isActionEnabled($taskId)) {
            return;
        }

        $userId = $this->getUserIdForAction($taskId);
        $this->commandBus->dispatch(
            new AssignUserToTask($taskId, $userId)
        );
    }

      // … 
}

This is of course some kind of compromise, we will not get rid of legacy, it will still be there, but tamed. Now you can easily use legacy code even without knowing that in fact legacy code will be executed. Everything will look nice and as good as your new codebase.

You can later (when pressure for new features will be lower) take such AssignUserToTaskHanlder and refactor it properly to get rid of the legacy TaskHelper service.

Working with legacy?

And what is your approach to legacy? Strangling, taming, rewriting? To learn more on that topic, make sure to check our CTO's blogpost on possible scenarios of handling technical debt in legacy applications.

Simple Docker setup for Symfony project

Michał Romańczuk — Fri, 15 Apr 2022 13:43:47 +0000

It is no longer the case at Accesto that we work on projects without Docker. Of course, projects are not born dockerized, someone has to do it. Sometimes I do. I am a PHP developer and I work the most with Symfony framework on a daily basis. In this article, I will present an example development Docker configuration for the Symfony project.

So let's use a Docker in a Symfony project.

When it comes to Docker setup, there is no one-size-fits-all solution. It always depends on particular project needs. But some good practices should be followed, for example, those described in the official Docker documentation

Let's imagine we take over an existing project, a simple one, PHP, Symfony, MySQL database, that's all. But there is no Docker. So instead of installing a local web server, the appropriate PHP version, the appropriate database engine, etc., the first thing to do is ... dockerize!

Why should I spend time on dockerizing first? Because I will do it once, and everyone working on this project will benefit from it. You can read more about why it is worth using the Docker in the article of our CEO Piotr.

I assume you already have Docker Engine and Docker Compose installed, if not, you should do so.

Now let's focus on what we need. This project is currently running on Apache, PHP 7.4 and MySQL 5.7.

Configure Docker using docker-compose.yml

I have added the docker-compose.yml file in the main project directory, and I defined our first container in it - the one with the database. File docker-compose.yml is used by (Docker) Compose to manage and run Docker applications.

At the beginning of the file, you can (from version v1.27.0 it is optional) define the version of the configuration. Different versions of Docker Engine + Docker Compose work with different versions of the configuration, which you can check here.

version: '3.8'

MySql database in Docker container

Let's start by defining the first service, the database. First, the name, I chose “db”:

version: '3.8'

services:
    db:

After that I had to define what db service is. For example, we can use the image option. As an image, I had to select the appropriate Docker image. We can use ready-made images available on the web for this. Most of the tools come with Docker images. And to search for these images, we can use the search engine.

In my case, the project uses MySql version 5.7 and such an image is also available so I could just use its name:

version: '3.8'

services:
    db:
        image: mysql:5.7

As per the documentation for this image, some things in this container can be configured using environment variables.

One variable is mandatory, this is MYSQL_ROOT_PASSWORD. As you might guess, this is the MySql root superuser password. But there are a few other variables that are helpful, I used the following: MYSQL_DATABASE, a database with this name will be created during image startup. If we define MYSQL_USER, MYSQL_PASSWORD, a user with this name and password will be created, and he will have granted superuser access to the database defined in MYSQL_DATABASE.

version: '3.8'

services:
    db:
        image: mysql:5.7
        environment:
            - MYSQL_ROOT_PASSWORD=somerootpass
            - MYSQL_PASSWORD=somepass
            - MYSQL_DATABASE=dockerizeme_db
            - MYSQL_USER=someuser

Symfony Docker image

But there are no ready-made images for everything. For example, there is no ready image for a web server configured according to the needs of our application.

So while defining the container for our web server with PHP, I did not use the image option with the name of the ready image, but I used the build option with directory (.) that contains the file (Dockerfile) from which the image will be built. But about Dockerfile soon.

version: '3.8'

services:
    db:
        # cut for readability, see above
    web:
        build: .

Going further. It would be nice to add a basic Apache configuration. I added the docker directory in the main project directory, where I will keep files related to the Docker environment configuration. Then, in that directory, I added the apache.conf file. This file is a very basic configuration of a web server.

<VirtualHost *:80>
    DocumentRoot /var/www/public

    <Directory /var/www/public>
        AllowOverride None
        Order Allow,Deny
        Allow from All

        <IfModule mod_rewrite.c>
            RewriteEngine On
            RewriteCond %{REQUEST_FILENAME} !-f
            RewriteRule ^(.*)$ index.php [QSA,L]
        </IfModule>
    </Directory>
</VirtualHost>

Let's make our container accessible "from the outside". I used the ports option for this. Port 80 from the inside of the container will be exposed to the outside at port 8080.

version: '3.8'

services:
    db:
        # cut for readability, see above
    web:
        # cut for readability, see above
        ports:
            - 8080:80

Why didn't I put it on port 80 but 8080? Because we often have Apache running locally on port 80, so we would have a conflict and the Docker container wouldn't start.

Finally docker-compose.yml looks like this:

version: '3.8'

services:
    db:
        image: mysql:5.7
        environment:
            - MYSQL_ROOT_PASSWORD=somerootpass
            - MYSQL_PASSWORD=somepass
            - MYSQL_DATABASE=dockerizeme_db
            - MYSQL_USER=someuser
    web:
        build: .
        ports:
            - 8080:80

Dockerfile for Apache and PHP part

Now we need to take a step back. Let's go into the details of our web image. To define it, I added a Dockerfile file to the main project directory. Of course, we will use the ready-made public image as a starting point, and slightly adjust it to our needs. I used the php:7.4-apache image as a base.

At the beginning of Dockerfile, I defined the Docker image which is our base:

FROM php:7.4-apache

Then I enabled Apache mod_rewrite:

RUN a2enmod rewrite

After that I did the classic update, several packages installed such as libzip-dev (needed for zip which is needed for composer) git wget via apt-get install. And some extensions such as pdo mysqli pdo_mysql zip via docker-php-ext-install mechanism, more about that you can find in base image documentation. In the meantime, I also deleted files that are unnecessary in the container, they would only take up space.

RUN apt-get update \
  && apt-get install -y libzip-dev git wget --no-install-recommends \
  && apt-get clean \
  && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

RUN docker-php-ext-install pdo mysqli pdo_mysql zip;

The application uses Composer to manage dependencies in our application, so I installed in the container:

RUN wget https://getcomposer.org/download/2.0.9/composer.phar \ 
    && mv composer.phar /usr/bin/composer && chmod +x /usr/bin/composer

I copied the Apache configuration file to the appropriate place in the container, and our project files to /var/www in the container:

COPY docker/apache.conf /etc/apache2/sites-enabled/000-default.conf
COPY . /var/www

Instruction WORKDIR sets the working directory for other instructions, for example for the RUN command:

WORKDIR /var/www

And last command to run Apache in the container foreground:

CMD ["apache2-foreground"]

To sum up, we have such Dockerfile for web container:

FROM php:7.4-apache

RUN a2enmod rewrite

RUN apt-get update \
  && apt-get install -y libzip-dev git wget --no-install-recommends \
  && apt-get clean \
  && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

RUN docker-php-ext-install pdo mysqli pdo_mysql zip;

RUN wget https://getcomposer.org/download/2.0.9/composer.phar \
    && mv composer.phar /usr/bin/composer && chmod +x /usr/bin/composer

COPY docker/apache.conf /etc/apache2/sites-enabled/000-default.conf
COPY . /var/www

WORKDIR /var/www

CMD ["apache2-foreground"]

Is that all? As for the minimum, yes! Now if I run the docker-compose up -d in project directory in the console, the containers will be created and the whole project will start running.

But wait a minute. Let's see if it really works:

Of course not ;). Our project needs a few more steps. For example, what about composer install? Database migrations? Now we can describe these steps in the Readme of the project. It would be something like “enter the container (docker-compose exec web bash) and run composer install in the container, then run migrations (bin/console doc:mig:mig)”.

Improvements in startup a dockerized project

We can try to "automate" these steps, for example by using Entrypoint. Using Entrypoint is not the best solution, but it will facilitate development at this stage. Let's assume that I want to run every time the container is started:

composer install
new database migrations to be loaded
fresh fixtures (dummy/test data) in the database.

So I added entrypoint.sh in docker directory with a simple script to do it

#!/usr/bin/env bash

composer install -n
bin/console doc:mig:mig --no-interaction
bin/console doc:fix:load --no-interaction

exec "$@"

Then I had to slightly modify our Dockerfile.

FROM php:7.4-apache

# … cut for readability

COPY docker/apache.conf /etc/apache2/sites-enabled/000-default.conf
COPY docker/entrypoint.sh /entrypoint.sh

# … cut for readability

RUN chmod +x /entrypoint.sh

CMD ["apache2-foreground"]

ENTRYPOINT ["/entrypoint.sh"]

I COPY the new script file to the container and add executable permissions to that file. At the end of the Dockerfile, I defined that the file is Entrypoint

Now I had to rebuild the Docker image to apply these changes docker-compose build web, and restart the containers. Let's check our application:

It works! Now, anyone who downloads this project and has Docker can simply run it.

Can you also work with Docker on a Mac? You can read about it in the latest post by Krzysiek here :)

Docker is a powerful tool, I only showed you a minimal snippet that will allow you to start your project in a box. You can find more practical tips and advanced Docker optimization techniques in our free e-book Docker Deep Dive