DEV Community: Damien Pobel

Why do we check the number of external API calls in our audits?

Damien Pobel — Wed, 12 Jul 2023 07:27:19 +0000

On most of the projects built with Front-Commerce, we perform an audit. Without surprise, these audits are conducted on the basis of a checklist. The first part is devoted to performance and the very first criterion is to evaluate the number of external requests necessary to build the most visited pages when everything is cached. The point is to target zero external request to generate those pages. Maybe you wonder why we check that or why we give it so much importance.

This Performance section is introduced with the following sentence:

Performance is essential to improve user experience, but also to reduce server load and thus increase the site's traffic capacity.

So the point of the whole section is not only to increase the performances i.e. in that case, the time it takes to generate a page but also to increase the scalability of the application i.e. according to Wikipedia, the property of [the application] to handle a growing amount of work.

To measure the number of external requests, you can use one of our debug flags. For instance, here I'll use a very basic setup where Front-Commerce is connected only to a Magento2 instance, so I can add DEBUG=axios in the environment to have some information about external requests. Depending on your actual setup, you might need other values to also count requests to Prismic or any other external service.

Also, we are mainly interested in the most popular pages of the site. Commonly, the homepage is most visited page. By default, we also check the category and the product pages. Depending on your project, this list can be slightly different.

Number of external API calls versus performance

Note: Performance is a very wide topic. By performance here, we are looking at the time needed to generate a page server side. This is very easy to measure with a curl based command:

$ time curl -s http://example.com/my/url > /dev/null

On a Front-Commerce setup configured without cache and connected to a Magento2 instance, 27 requests to Magento2 APIs are needed to generate a category page. Each of these requests takes a significant amount of time, sometimes several hundred of milliseconds. While when caches are enabled, if everything is in cache, no external request is made.

Without surprise, the time needed to generate the page is completely different:

without cache, on my local setup, it took between 5 and 6 seconds;
with everything already cached, it took between 200 and 300 milliseconds.

It's 20 times faster! The example is a bit extreme, but I guess you get the point. Also, without external requests, the response time is somehow similar to any external API call. This means that if on a page you have one external API request left, getting rid of it might divide the response time by two. Worth a try, don't you think?

Number of external API calls versus scalability

Measuring the scalability is harder. It is done with load tests that involves running some scenarios to simulate traffic peaks (usually inspired by past events) in a production like environment. That's definitely not something you can do reliably on your local environment in 10 minutes. That being said, we always see a clear correlation between the number of external requests and the scalability of the application.

Commonly, the target of those external requests (the Magento2 instance in my previous example) becomes the bottleneck of the application especially if some popular pages requires several API requests to the same service i.e. one page generated by Front-Commerce entails n requests to one external service.

Depending on how Front-Commerce is hosted, it can also be the bottleneck because it will be busy waiting for some APIs to reply 😀.

The conclusion is simple: when it comes to external request, the less the better. After having said that, it remains the hard work of optimizing the application and the recipe is classic:

is the external request strictly needed ? In some case, it might be an opportunity to discover useless code or to discuss feature;
if it is strictly needed then you need to add more cache to the application either by leveraging the dataloader mechanism or by using the cache at resolver level if your project embeds content from Prismic.

Some challenges of being the editor of a software intended to be integrated

Damien Pobel — Fri, 24 Mar 2023 08:00:00 +0000

Essentially, Front-Commerce is a software meant to be integrated by developers so that a merchant can sell products to its customers in its own online store and even without having to completely change an existing e-commerce stack. While this is probably the simplest definition of Front-Commerce (more or less the one I use to describe my job to my family and friends 😉), it hides some challenges we face every day.

Three targets: developers, merchants and customers

The first challenge is not really technical. As stated in the introduction, we try to address three main personas:

the developers integrating our solution to create an online store for…
a merchant willing to sell something to…
a customer seeking a product.

Anybody having at least a small experience as a software editor knows that properly addressing one persona can already be challenging, so you can guess what it is like with three, even if they don’t necessarily want opposing features, more targets mean more constraints.

Let’s take a deliberately extreme example 😃 They all want a performant store.

The customer:

I want a performant and great shopping experience even in the middle of nowhere with a low to average 3G connection.

The merchant:

Can I have a great shopping experience for my customers? And also, I want to put very high quality photos and videos online. In addition, I want my pages to be always highly up to date with customer specific and very dynamic content. And next Friday is Black Friday! The website needs to scale, it’s the biggest selling event of the year.

The developers:

The merchant wants a performant and scalable website. Is your software doing that out of the box or can it be done by turning on a setting?

I guess you get the idea, each target adds a set of constraints. It’s no surprise that pleasing everyone is difficult but it’s also a stimulating challenge.

Extensibility

As a software meant to be integrated by developers, Front-Commerce needs to be extensible so that it can serve different use cases. The most obvious reason is that each merchant wants its own customized store implementing a dedicated shopping experience.

In addition, each project needs a specific set of features and while we try to support as many as possible out of the box, having an extensible architecture allows the developers to fill the gaps. As far as I’m concerned, it’s always a pleasure to see very unexpected or specific features nicely implemented even if I would never have imagined it could exist.

It’s also worth mentioning that in the world of composable architectures and headless commerce, extensibility is a key feature.

Backwards compatibility and upgradability

Being able to implement a project is nice but that’s only the very beginning of the story. At some point, new features and fixes for bugs will be needed. The challenge here is to be able to deliver those without breaking anything.

On a practical level, that means we try to follow semantic
versioning by regularly providing patch releases containing only bug fixes and every six weeks, we release a minor version with new features. Those minor versions always have a migration guide to make the upgrade process as frictionless as possible. And what about a major version? In the last couple of years, we have not released any, but I’ve heard that something is cooking 😇

In the code, this has a quite deep impact. When changing code, we have to keep in mind both existing projects using our software and new ones. We also have to think about how APIs are being used before we can make any changes to them. This forces us to carefully encapsulate our API’s to reduce their surface as much as possible. This has a tendency to limit the extensibility and the versatility so as usual when it comes to code, the key is to find the right trade-off.

Anything else?

Oh yeah, I could have approached the support, the documentation, the developer experience or the dependency management to name a few. This will probably be the subject of another post…

In any case, all this is a part of the context in which we build Front-Commerce and where we try find the best solutions or trade-off. As usual when it comes to our product, we are always seeking feedback, so don’t hesitate to contact us if you have any remarks or comments. This can only make the product better.