Originally published at https://www.checklyhq.com/guides/api-monitoring.
Application Programming Interfaces (APIs) are used throughout software to define interactions between different software applications. In this article we focus on web APIs specifically, taking a look at how they fit in the JAMStack architecture and how we can set up API monitoring in order to make sure they don’t break and respond fast.
The trend of declaring infrastructure as code has been picking up steam over the last few years, offering a way for DevOps teams to transparently manage and scale cloud infrastructure. Why should the way we manage monitoring be any different? In this article, we address this point and illustrate it with a practical example of Monitoring-as-Code on Checkly.
Historically, IT infrastructure has been provisioned manually, both on premise and in the cloud. This presented several challenges, including fragmented workflows, lack of transparency and scalability issues. …
Our recent speed comparison of major headless browser automation tools, namely Puppeteer, Playwright and WebDriverIO with DevTools and Selenium, received a very positive response. The single most common ask from our readers was that we follow up by including Cypress in our benchmark. In this article, we are doing just that — with some precautions.
Note: In case you haven’t read our first benchmark, we recommend going through it as it contains important information on the hows and whys of our testing which we have decided not to duplicate in this second article.
Table of content
Originally published on theheadless.dev
Puppeteer and Playwright can be used to create PDFs from webpages. This opens up interesting automation scenarios for tasks such as archiving, generating invoices, writing manuals, books and more.
This article introduces this functionality and shows how we can customise the PDF to fit our needs.
After loading a page, we use the
page.pdf() command to convert it to a PDF.
Note that we need to pass the
path option to have the PDF file actually saved to disk.
This feature is currently only supported in Chromium headless in…
While automation tools are fundamental to modern software development, they also have the innate potential to be used for malicious purposes. This applies to Puppeteer and Playwright, too.
As a consequence, some user flows are made purposely hard to automate to defend against threat actors. Some examples:
There are several means through which automation is made more difficult.
Captchas are a popular measure many websites take in order to counter automation for sensitive user flows, with Google’s ubiquitous reCAPTCHA being perhaps the most…
When we decided to build Checkly’s browser checks, we chose to do so with Puppeteer, an open-source headless browser automation tool, later adding Playwright, too. We wanted to support users with synthetic monitoring and testing to let them know whether their websites worked as expected at any given moment. Speed was a primary concern in our case.
Yet, determining which automation tool is generally faster is far from simple. Therefore we decided to run our own benchmarks to see how newcomers Puppeteer and Playwright measured against the veteran WebDriverIO (using Selenium and the DevTools automation protocols).
Among the results of…
The need for fast and responsive applications has never been greater because of the move from desktop to mobile. Still, web applications have been increasing in complexity and size, with rising load times. It is therefore clear why the topic of webpage performance is more popular today than it likely ever was.
This article aims at giving a practical introduction to the whys and hows of web performance, without getting lost in the depth or breadth of this massive topic.
The time it takes for a service to become usable, as well as its general responsiveness, bear a lot of…
We recently optimized the hell out of our Lighthouse score, and one of our landing pages went from a low 70s score to a cool 96 and above score. Below I describe what started as a quick lunch break peek into the Google Search Console — maybe some of it will help you optimize your own page!
One of the most common tools to measure your page performance is Google Lighthouse. The advantage of Lighthouse is that you can run it against basically every public site out there. You can easily measure how others are doing and compare yourself.
As we go about our day-to-day on the web, our browser automatically exchanges small amounts of data with the websites we visit. This way we get to have them recognise us and remember our preferences, the contents of our shopping baskets or the fact that we had just logged in to our account.
These bits of information are called cookies, and they allow the otherwise stateless HyperText Transfer Protocol (HTTP) to keep context consistent over the course of a session.
When we browse the web, a series of HTTP requests and responses are exchanged between our browser and the pages we are visiting. There are scenarios in which it is useful to monitor or manipulate this traffic, instead of letting it happen as-is.
Request interception enables us to observe which requests and responses are being exchanged as part of our script’s execution. For example, this is how we could print them out when we load our test website.
We might want to intervene and filter the outgoing requests. For example, when scraping web pages…