I'm currently setting up a testing pipeline at work and keep coming across the term 'sidecars' in the context of using Playwright and Puppeteer in containerized environments. From my understanding, both of these tools can run natively on Node.js, so it seems unnecessary to use a sidecar for the core testing itself. It seems like sidecars are more beneficial for specific scenarios, such as observability with monitoring tools like Datadog, service mesh configurations like Dapr, or centralized logging systems. For basic E2E tests using Playwright in CI, a clean Docker setup seems to suffice. Introducing a sidecar might add unnecessary complexity unless there's a compelling infrastructure need. Additionally, the testing approach is evolving towards minimizing architectural layers in favor of reducing maintenance overhead. Self-healing frameworks that adapt to UI changes appear to be a more effective investment than adding more infrastructure. I'm curious if anyone has found solid reasons to use sidecars outside of those specific observability or service mesh contexts, or if they truly serve more enterprise needs that don't fit smaller teams running basic CI pipelines.
2 Answers
From my experience running Playwright in CI for a couple of years now, it seems like sidecars often solve problems that many teams don't actually face. The main issue with E2E testing isn't the runner or the container setup; it’s actually the maintenance of selectors. We tracked this for a quarter, and engineers were wasting 3-4 hours a week fixing tests after things like class name changes, even if those didn’t impact behavior at all. A Docker image with Node and the necessary Playwright browsers already included likely covers about 95% of what teams need. The real return comes from tools that can cut down on the need to constantly rewrite selectors every sprint.
You're not mistaken that Playwright can run directly on Node. That said, there are definitely some upsides to using a sidecar. For one, the bundle size of Playwright along with any browser engines can get pretty hefty. Even if you're not concerned about disk space, downloading everything each time can slow down your CI/CD pipeline. Caching helps, sure, but you could opt for a pre-built image with everything you need, which avoids the hassle of constant rebuilding. This way, you can also easily share that image among different projects if you’re testing a few apps. It’s a balancing act; both sides have their merits!
Good point about the build times. Those browser binaries (like Chromium, Firefox, and WebKit) add up quickly when firing up parallel CI jobs. Having a stable pre-built image that skips the reinstall hassle really makes a strong case for setting up a sidecar.
Yeah, managing disk space can be a headache, especially with multiple test suites. We've faced similar challenges with our CI setup where browsers were downloaded each time, consuming a lot of time. However, for smaller teams, managing separate sidecar images may become more trouble than they’re worth. If you nail the caching with your base images, those download times can become less of a problem. Plus, debugging can get tricky with multiple containers involved instead of just one setup.
Totally agree! The selector maintenance becomes the real time drain. All this debate over architecture feels pretty pointless when you're battling flaky tests every time there’s a frontend update.