Bundle Size matters - this is something we SDK engineers at Sentry are acutely aware of. In an ideal world, you’d get all the functionality you want with no additional bundle size - oh, wouldn’t that be nice? Sadly, in reality any feature we add to the JavaScript SDK results in additional bundle size for the SDK - there is always a trade off to be made. With Session Replay, this is especially challenging.
Have you seen this problem? Or maybe this one? You’ve most likely seen this: Hint: they’re all the same. The first image is Sentry’s Event Details page, the second is Chrome’s Network tab, and the code snippet is what causes it. If you can answer yes to any of these, then you need to keep reading. If not, you still need to keep reading, so your future self can thank you. This is called “fetch waterfall” and it’s a common data fetching issue in React.
Your images are 404ing all over the place. You’ve got an angry email from a client. Their site is “broken”, images aren’t loading, cumulative layout shift is running riot, and everything is messed up. The crowds are mocking your broken code on Twitter. A fun GIF loaded via a Giphy URL no longer exists. And someone has accidentally deleted an image from the CMS.
Grab your favorite mug, fill it with some warm chocolatey goodness – it is hot cocoa season after all –, and check out our most recent product updates to Sentry.
A long time ago I worked on a project called Django Debug Toolbar (DJDT). It was a local development plugin that would give you a debug overlay within Django’s development environment, helping you diagnose things like the SQL queries being made, environment configuration, and what templates were rendered. In general, it made the local dev experience much better, helping you prevent or more easily fix things like N+1 queries.
Sentry started life in 2008 as an unlicensed, 71-line Django plugin. The next year we began publishing it under BSD-3, and ten years later we switched to the Business Source License (BSL or BUSL). Last year we purchased Codecov, and a few months ago we published it under BSL/BUSL as well. That led to some vigorous debate because of our use of the term “Open Source” to describe Codecov, from which emerged this helpful suggestion from Adam Jacob, co-founder of Chef.
It seems like these days there’s a new exciting framework or dev tool launched every week. The challenge is that even if you’re ready and able to use new products, your existing tooling might not be up to the task; it could be months or years before your developer tools add support for the burgeoning platforms you want to use.
I know, we’re Sentry the error and performance monitoring platform and we catch production issues. But as you (hopefully) saw during our Launch Week announcement, some broken experiences simply won’t throw an exception. So we built a way to detect when your users are slamming their keys on the keyboard in frustration, and to even let them contact you directly when that doesn’t go their way.
Extracting relevant insights from your performance monitoring tool can be frustrating. You often get back more data than you need, making it difficult to connect that data back to the code you wrote. Sentry’s Performance monitoring product lets you cut through the noise by detecting real problems, then quickly takes you to the exact line of code responsible. The outcome: Less noise, more actionable results.
Since 2020, I’ve been working on an Express (Node.js framework) application to power viewer interactions and events that happen whilst I’m streaming live coding on Twitch — my Twitch bot. Since using Sentry for error monitoring and crashes using the Sentry Node SDK, I’ve already squashed quite a few bugs that were entirely a result of my own terrible code.
