Tracing: Frontend Issues With Backend Solutions

You are welcome to follow along. It's a two-hour workshop. We will take a short break in the middle. We will have instructions for you to be able to follow along. Since you're here a little bit early, if you want to just make sure that you at least have, we're going to be using Visual Studio code. You can use whatever editor you want, Python and Docker. So if you make sure you have those things and a GitHub account, then we should be good to go.

And I'll apologize if my voice gets a little raspy. I got sick yesterday. I don't know from where. My kiddo went back to school after five days of not being there and must have picked something up. So, you know, what are you going to do? So we're going to go ahead and get started. We've got kind of a slow ramp-up. So if folks are joining, thank you. If folks are joining a little bit kind of on a rolling basis, that should totally be fine. But welcome. My name is Sarah Guthals and I lead DevRel at Sentry. We're going to give you a quick introduction to Sentry and then we're going to get into a live demo where you get to follow along. Like I said, I'm based out of Washington State, a little outside of Redmond. And this is my colleague, Lazar. Hey, everyone. I'm at the office today, which is pretty cool. Nice. I am also at an office, but it is my home office. All right. So let's go ahead and get started.

A couple of housekeeping. As I mentioned, the chat is open. Feel free to let us know where you're tuning in from if you haven't already. Let us know any questions that you have and just kind of impressions or comments or things that you might have there as well. Okay. So what are we going to do? We're going to do a quick monitoring deep dive. We're going to show you this app that we, well, we, Lazar has built, which has a Next.js front end and a Django back end. We're going to debug this app together. You can just follow along and watch. All of this is freely available. So you're welcome to try it now or try it later. And then we're going to give you time to actually try it on your own and kind of share what you've learned. Okay. So let's get started.

First of all, you know, Sentry is a monitoring platform. However, we want to kind of push what that means. What monitoring, APM, observability, like all of these terms, just like the words themselves, imply a sense of passiveness, and that's definitely not what we are trying to build. What we are always trying to build is something that is more proactive, not even just active, but proactive. So we want to encourage you to not just observe, but to debug. And what does this really mean? The way I like to think about it is that platforms that support developers throughout their debugging workflow should help you in three key areas. They should help you contextualize, prioritize, and trace. So what do we mean by this? Well, contextualize. Understand the context about what went wrong. Is it happening on every single browser or is it only happening on Chrome? Is it happening on every single device or only on Android? Is it affecting, like, you know, every, like is your app completely crashed or is it only affecting this niche area of the app that not a lot of people are using? This kind of information helps you contextualize, helps you understand where the problem might be, and helps you understand the next step, whether you should prioritize the problem. And in addition to that information, prioritizing is not just knowing kind of how important a problem is in and of itself, but knowing how important a problem is compared to all of the other problems. So do you have other problems that are escalating that are affecting your checkout versus one that might be affecting some smaller niche area of your application or your website? Do you have a bug or a slowdown that is affecting one of your key user groups and the ones that are maybe paying more and so you want to prioritize those fixes faster? Or is it affecting folks that are on a free plan that maybe are just kind of giving it a trial? Obviously, in an ideal world, we would fix all of the bugs as quickly as possible and have a perfectly running app, but that's not the reality of what we're faced with every day. And then once you've been able to kind of understand what the problem is and prioritize based off of that those insights whether or not you should fix it, we want to take action. The contextualize and prioritize is kind of that more passive, you know, observe or monitor kind of feel. The trace is really where that active piece comes in where we are actively debugging.

So rather than sifting through mountains of logs or looking at user feedback that just says it's broken and you're like I know, but can you give me more information? Can you give me a screenshot? Can you tell me kind of anything that will help me be able to figure this out? We want to help you be able to trace down to the root cause of the issue. Ideally, that line of code or that database query that's causing that issue. Be able to make that fix quickly, deploy that fix quickly, and make sure that that doesn't regress again in the future. So again, we have kind of three main areas, contextualize, prioritize, and trace. And this is what it means to have a platform or a tool that helps you debug.

Any questions about monitoring or debugging, please feel free to add them into the chat. Otherwise, I think what's more important is that we actually see this in action, because I can tell you all day what's going on. Let's actually see what's going on, though. Right? So we're going to debug some bad code. Again, to get started, make sure that you have Docker and Python, some kind of editor. We're going to clone this repository. We'll throw links in the chat. And then you need to start your Docker container. Now, I'm going to do this with you. So, you know, you don't need to, like, super rush, but we're going to do this together. We're going to get this going, and we're going to try it out.

This application that we are debugging is a flashcard app. Like I said, it's got a Next.js frontend and a Python Django backend. So let's give this a try. This is the repository. This is open source. It's our flashcard repository. And I'm just going to grab this here. And I'm going to open up VS Code. And I'm going to go ahead and clone this. So we're going to go here and clone repository from GitHub. Awesome. And you know what, we're just going to put it in documents for now. Sounds good. Okay. So we're going to clone this, and now I've got it on my local machine. So hopefully you've done the same. Let's take a look at what we have here. Lazar, you built this.

Lazar, you built this. Do you want to walk us through a little bit about what we have in this repository? Yeah. So at the root, we only have one folder, which is the packages folder. Think of this as a monorepo, but it's not. It is a structure that holds two different types of projects. One is the API, which is in Python Django. And the other one is the web, which is in Next.js. We also have a compose file at the root of the project. There we go. And this basically ties everything together. It's going to start a Postgres database for us. It's going to run some migration scripts for us to set up the database after we run it for the first time. And then it's going to boot up the API project, which is the Django one, and also the web project, which is the Next.js one. So technically, we are starting three different servers and one migration script with this. And the home folders for the projects are API and web. Each of them have their own Dockerfile, which I made it work so that even if we change anything, it should technically restart the container. If not, it's a matter of re-running the last command that we run. So, yeah, this is how the project is set up and we can dive into specific details later when we are going to get into code.

And here's the thing. When is a platform that helps you debug useful? Obviously, when you're just trying to fix a bug. But more importantly, maybe when you're on call and a critical bug comes in or a performance slowdown comes in and you haven't actually touched this part of the code before. You're not a part of that team, let's say. Even if you're not going to actively debug it, you need to understand who you need to tag in next. That's one instance. Another instance is if you're onboarding. So, I haven't explored this version of the Flashcard app a lot before. We had previous versions. This time we're using a Django backend and Lazad has completely rewrote and refactored this. So, this is a fairly new code base for me. So, we're going to be learning this code base together and we're going to be leveraging Sentry to be able to do that.

Okay. So, great. I've got my repository cloned. Yes. And I do have Docker running. There it is. I mean, nothing's running, but I have it open. So, let's go ahead and open up a terminal. And if I recall correctly, on your readme, you have this as well, right? We just have to run Docker compose. Wow. It was the first command in the getting started section. There it is. Yep. I just totally missed it because my brain said, that's a different color. I'm not going to look at it. Compose up dash dash build. Perfect. Yep. So, we're going to run this command right here in the terminal NBS code. And we're just going to see kind of what's going on. The dash dash build, we have here the arguments might not always be required. But I just added it for good measure because sometimes the hot reload doesn't work and it doesn't pick up the changes. So, some of the changes might not be reloaded. If I add the, when I added the dash dash build, everything was working perfectly. So, yeah, have that in mind. Yep. All right. So, we have it running. We have it running. Booted up. Did we actually check it out? Oh, this was from when I was testing it before. Oh, let me just go ahead and, so, I'm going to, go ahead. I was going to say, these are in dev mode. So, it's going to be pretty slow because we are running basically npm run dev, at least for the next JS site. So, it is going to be slower. If we build it and run it, it's going to be much faster, or is it? We'll see. I hope so. Because that was pretty darn slow. Okay. Now, we don't have Sentry installed in this yet at all. We're going to do that together. So, if we do run into bugs, we're going to see what we can try to figure out, but it's probably not going to be a lot. Especially since, you know, you all who are attending and myself, we're not super familiar with this entire code base. So, Lazad might be able to see something happening and say, oh, I know exactly where to fix that. We're not necessarily going to be able to do that. So, looks like we've got some categories. We've got flashcards. We can manage them. We can practice them. And then we have this nice handy dandy populate database because, you know, in this case, we are just kind of doing a local demo app. Sentry is most useful, though, when you actually have it in production and you're using it out in the wild. So, we're going to populate the database, assuming someone has already populated kind of their flashcards. We can also just create one by clicking on this. Oh, maybe not. Hmm. Okay. Interesting. Actually, I think I know. Maybe because we don't have, oh, no, I don't know. See, maybe we've got some bugs.

We'll have to figure this out. So, we're going to do a hard refresh just in case. And I'm going to populate the database here. Again, this is meant to be buggy, but not all bugs were intentional. So, we will see. As with all code.

So, we've got some flashcards that have been created. Lazat, how did you create these flashcards so quickly? AI. I'm using AI. Just like everyone else in this world. I love it. Awesome. I found a free LLM that allowed me to just ping it with a specific query and get the information back and parse it. Newsflash. If the LLM generates a lot more than it can transfer, it's going to give me an invalid JSON. So, the whole populate database operation will just simply break. And I won't be able to fix that. So, in case you're trying this out right now and populate database does not actually populate the database, just click again.

We're working with LLMs. They're not always complete, etc. But, yeah. The flashcards and categories, as you can see, categories are super stores, mega stores. And the flashcards, they have a question and answer. The question is a product that can be found in the super store, that it's being sold by the super store. And the answer is a department. So, think of it as like you're joining... You get hired by one of these mega stores and your job is to learn where every product is. Right? But there is a... I mean, who wouldn't know where the burping bicycles are, though? Come on. Yeah. They're in the motorcycle store, right? Yeah. The mental mountains. Don't ask questions. They're in the travel agency, right? So, yeah. So, we can practice this and choose one of the mega stores. Let's choose Wonderworld, start practice session. Hmm. That's pretty slow. So, that might be something we want to look into. Luckily, we've got something to drink. Wow. There we go. Flying shoes. Flying shoes. Are they in the shoe department? They're in the bookstore. I should have known. Okay. So, this is what the app is. Whispering wallpaper in the paint store. Obviously, forgotten feasts in the kitchen. I don't know. Restaurant. I was close. Okay. You get the point. Hopefully, we've stalled long enough for you to not only get this cloned on your local machine and get it running with Docker, but also understand kind of what this application is and kind of what the scope of this application is. Fairly simple. No counts. No kind of keeping track of anything. Just creating categories, creating flashcards, and being able to practice them.

I have a feeling that we should probably just set up Sentry now, because we've got some down. I don't know what's going on. I just want to be able to contextualize, prioritize, and trace. If you do not have a Sentry account yet, then let's – where did that go? First tab, right? There we go. This is the QR code and or the link. You can see it right here at the top. Try Sentry, and we also put it in the chat. This will give you three months free of basically unlimited spans and transactions with Sentry. You'll be able to try out basically every single feature for three months for free. We encourage you to do this if you are evaluating whether you want to use Sentry for either your own personal projects or for your company. This is critical for a couple reasons. When you do set up Sentry, and we'll see this right now, you do set sample rates for your errors, for capturing transactions, for capturing session replays, et cetera. We'll get into what each of those are. These three months is your opportunity to see what kind of sample rate you might want to set those to. Use this, use it as much as you can, so then that way you can actually see how to set it up properly. I do want to mention Sentry is fair source. If you haven't heard of the OpenSource Pledge yet, you can go to OSSPledge.com and check it out. That means that Sentry is available on GitHub and you could self-host it if you wanted to. In addition to that, we have individual developer plans that are free. If you are just using this as an indie developer, you can use it completely for free. Our team plan starts at less than $30 a month. That's not per person, that is total. Very affordable, something that you should definitely give a try. If you do want to follow along with what we're doing today, sign up for those three months for free either using this QR code with that code or that link that's there at the top. That will give you that same code in that same three months. I have a Sentry account and I've got some other projects running, but let's go ahead and install Sentry. We got two projects. You gave us some code here to set up Sentry.

We got two projects. You gave us some code here to set up Sentry.

So first of all, we need to set up Sentry for the front-end. Now, the way that you instrument your application with Sentry is it's just a bunch of SDKs, basically. We want to set up Sentry for the Next.js front-end side and we want to set up Sentry for the Django back-end side. By doing this, we will be able to trace issues that maybe appear on the front-end, like a slowdown or a user saying, hey, something's wrong. We will be able to trace those issues all the way back to the back-end, like maybe there's some database query happening in the Python that is causing the slowdown. We will set this up for both the front-end and the back-end, and we highly recommend that you do this for your projects as well.

Sign up or sign in to Sentry and we're going to create a new Next.js project and then we're going to run the setup wizard. This is the commands for the setup wizard, but you don't even have to remember this because once you create a new Next.js project in Sentry, we will share that with you. We're going to go to projects. This is Sentry. If you haven't seen it before, we will dive into this and explore all of the things shortly. We're going to create a new project, we're going to create a Next.js project. Did I mention that Sentry supports over 100 languages and frameworks? It's ridiculous. These are some of the popular ones that a lot of our customers use, but you can do anything, really. It's insane, all of the support we have. Find whatever you need, but for this instance, we're going to be using Next.js. We'll choose Next.js. We'll keep this as is for now because I want to try to figure out what I need when I'm making this project. Like with any tool, just like with the sample rates, you want to see what alerts are useful for your team, for your project, for the way that your application or website's being used, and you can adjust these at any point. We're going to just stick with alert me on high-priority issues. I trust Sentry to identify whether something is high-priority. We're going to do that for now. We're going to have notify via e-mail. You can also notify via any integration that you have. We could also say notify me in Slack, but for now I'll just do notify me in e-mail. Let's change this one. I'm going to call this flashcards React server. We'll keep it in this team. Create project. Get the slides for future reference. Honestly, the slides, this information here is all in the repository, and everything else is going to just be on the docs or in Sentry. But yes, we should be able to send you a link to view them. Maybe if you want to make the link accessible to just view and share, that could be useful. Then we can run the wizard. This is a large, long command. This is longer than what we showed here. That's because you can actually just run this command right here, npx at SentryWizardLatest-i Next.js. However, when you do that, it's going to ask you a series of questions. For example, are you self-hosting or are you using SAS? Which org are you trying to find the project in? Which project is it? You can just run the front half of this command, but if you don't want to answer all those questions, you can just run the longer version. Since you can just copy it, fairly simple. We're going to go ahead and just copy this command right here. I'm going to open up VS Code again. I'm just going to run a new terminal. I'm going to go into my web. Now I'm here and we're going to paste that. Here's the command. This will set up Sentry for me automatically. Let's go ahead and do that. Can it install the following packages? Yes. Oh, no. What happened? The file exists. I thought we removed Sentry. Yeah, maybe. It's in the cache. It's in the cache. Oh, no. It's in the home cache. Yeah. As if you already had the wizard installed, is that the case? Can you run this again? I think that might be the case. I think it's that I already had the wizard installed. Run it again. Who would anticipate this? Well, okay. If it's just the cache, we can just remove it. I'm just going to also try this because I'm wondering if maybe there's just like... Yeah, I guess it's going to be the same. Can you do like rm-rm? At least you know it's live. Yeah. Well, we didn't pray to the demo gods. We didn't pray to the demo gods. Well, we didn't pray to the demo gods. We didn't. That's what we get. We wanted to get into it. All right. Rm-rf. Let's do tilda slash npm.npm slash underscore CA. Underscore C-A cache. C-A cache. If it's cache, yeah, there we go. Or the same. Yeah. Permission denied. So we need to sudo it. Yeah. Ctrl C and tries to sudo this. If it's cache, we can delete it then. It's going to populate it again. But this time, hopefully, it's going to be correct, right? I hate when you're in terminal and it doesn't show you how much you've typed because...

At least like stars, right? I know, right? Or at least tell me when it's been totally deleted, right? Okay. No, no, no wait. It's deleting. Oh, it didn't work. Okay, okay. Yeah. Let's try it again. Okay. Let's try this again, JK. And yes, go ahead and run that or install that package for me. I appreciate it. Wonderful. Look at that. Thank you. Yes, the struggle never ends. This is true. This is the part of being a developer that I hate the most, but also it's like what makes it... What keeps us humble, let's call it that.

Okay, yes, I already have a Sentry account. It's just going to verify. So even though we specified which project and which org, obviously, it needs to verify that we were in the same org. Obviously, it needs to verify that we are allowed to access that, so it needs to do a verification. And if you don't specify the project and org, you get to pick that in the browser. You do.

Do you want to route Sentry requests in the browser through a Next.js server to avoid ad blockers? This is going to be a personal preference for you, depending, again, on your application and kind of what you're doing and how things are set up. Note, though, if you do say yes, that will obviously, potentially increase your server load and hosting bill. But you will get all of the things that are kind of causing issues, so regardless of ad blockers. So we're going to say yes for now, because we're just going to be running this locally anyways. It doesn't really matter in this case. What this does is basically it sets up an API route for you, so that instead the Next.js browser SDK, which is when you install the Next.js SDK, installs the Node.js on the server and also the browser. The browser one is not going to send requests to Sentry. It's going to send requests to the server and the server having the API route will basically proxy. It will take the inputs and then just send it over to Sentry. But ad blockers, when they see this request, they're going to see that it's sending the request to the same origin, right? It's the Next.js server. It's not like a third-party server. That might be analytics. That might be ads. That might be something else. So it's not going to block it. That's how we get around that. But yeah, it does mean that the server needs to handle that, and if you're running serverless on Vercel, that means you might even, you know, you are going to get a bit bigger bill. But yeah, have that in mind. This is true. Also, just to note, Sentry is extremely privacy-first, and so we will call this out in a lot of areas. But as an initial call out, for example, even on our marketing pages, we do not have cookies. And the reason is we don't want to track you. We don't want to track your customers. We want to help you debug, and that's the limit to which we gather data and information and store data information. So you do have a lot of control over that, as well. We do have EU data residency, in addition to the US. So if you do need to have your data stored somewhere else, and then, of course, again, you can self-host.

Do you want to enable React component annotations to make breadcrumbs and session replays more readable? I'm going to say yes, obviously, because when I'm debugging, especially if it's a new kind of code base, this is going to be interesting. Now, I think this is most interesting when you're running, like, a React native app. But I haven't had, like, an issue when I'm running just kind of an XJS app. But we're just going to say yes in case we ever want to make some changes in the future. Keep forgetting that I've clicked away from my terminal.

Keep forgetting that I've clicked away from my terminal. Okay. Do you want to enable tracing to track the performance of your application? So, again, as we mentioned, because we're going to be instrumenting our frontend and our backend with Sentry, we will be able to not only trace kind of through each individual layer, but also across the layers and in particular be able to trace kind of performance that is happening. So, within one trace, we'll be able to see when this was initiated, it went all the way back to this database query and back, and here's kind of those parts that are slowing down, and we'll show you that visually. So, yes, definitely, this is going to be a part of this demo. So, if you are following along, make sure you click yes there.

Do you want to enable Sentry session replay to get video-like reproductions of errors during a user session? Session replay has got to be, like, my favorite feature of Sentry. It's a DOM recreation. Like, it's a recreation of the DOM changes. So, we are not capturing video and sending video across to Sentry servers in any way. Don't worry. We also are obfuscating all text and images on the client's device prior to sending it to the Sentry servers. And you do have controls over that, but you're essentially being able to see when there's a slowdown, when there's an error, what was happening, what was your user, your actual user, actually doing on their actual device when this happened. This can be particularly useful for those really hard-to-debug issues. There was one, for example, that I was talking to a customer about where there was, like, it was seeming to be that the user was rage-clicking. This is when the user's clicking multiple times on one element within a short period of time. We call that a rage-click because they're likely very upset. And the developers, like, looking through logs and could not figure out why in the world this would be happening. Why would a user be doing this at all? Turns out there was, like, a pop-up over it. And that pop-up was, like, not working properly and not clickable. And so, their application was actually grabbing the click. It was just a wild bug. It really had nothing to do with where they thought in the codebase this issue was. And without being able to visually see what their users were doing, they were able to resolve that. So, we will show you session replay as well. And we do recommend that you set that up.

Do you want to create an example page to test your Sentry setup? I do recommend that you do this when you're running this on your own. Just so that you can kind of start to get the feel of how Sentry works. How, you know, user interaction happens. And then going into the Sentry dashboards and being able to actually see what's going on. In this case, I'm going to say no because that's what this whole demo is about.

Are you using CI-CD tool to build and deploy your applications? Again, we support over 100 languages and frameworks. We have integrations with things like Slack and Teams. We also obviously have integrations with the entirety of the rest of your developer tools workflow. So, if you're using GitHub Actions or GitLab or Jenkins or Vercel, whatever you're using, we probably have some kind of support for it. In this case, we're not even deploying. We're not going to worry about this for now because what we're going to do is just run this locally. But we do highly recommend do this. Yes.

So, in what form is the image video going to be shown to the software developers with session replay? We're going to show you that it will look like a video. It's a video-like reproduction. So, we reproduce what was happening in a video-ish. You'll see.

Okay. So, we've successfully installed Sentry Next.js SDK. Wonderful. However, that's not the end of it because we have a back end. We're not just dealing with the front end. So, we'll head back over here. And Lazar has shared some instructions for now how to get the Django project set up. So, I did actually install this only on web. Should I have done that or should I have installed it kind of all up? Now, we need to go into the Python project now. And you can install it with Pip if you're running Python managed by run server. But because we're in a Docker environment, technically, we can get into it, right? We can get into the container and run Pip ourselves or run Python ourselves. But it's better if we just add it to the requirements.txt file so that when we rebuild the Docker container, the Sentry SDK will automatically get installed. So, yeah, we can just add this wherever here. There we go. Hit save. Done. And this is how we install it. Now, we need to go and paste that thing right there into the settings.py. So, settings.py in Django is like NextConfig.js in Next.js. It's in source. It's in shared this time. Okay. So, I'm doing a little DDD, a little domain-driven design in this project. So, yeah, infra. That was correct. It was infra. Django, yeah. There we go. That's why. All right. So, anywhere here above at the imports, you can, yeah, below the environment, for example, below the env. Let's load that first. And then we are going to initialize the Sentry SDK. Now, this means that we need to provide either a DSN, either like hard-code the DSN or pull it from the environment variables. For the demo, we can just hard-code it. So, once we create the project, we're going to get the DSN. We'll just hard-code it into the project. And DSN, by the way, is basically how you tell the SDK, this is where you need to send the telemetry data. What you capture needs to be sent this. Here, on this link, right? Under this organization. Which means we also need a Django project. Yep. We also need a Django project. Yeah. So, we're going to create that Django project. There we go. And we're going to call this Flashcards Django. Here's those instructions if you did want to run it. As a standalone application. Here is my DSN. Don't worry, I'll delete this afterwards. And then you can verify with that.

Okay. There we go. So, as you can see, it's basically a weird URL that tells where your project is. Right? As Sarah mentioned, because Sentry is a fair source, you can put it on your server. That means the DSN will need to point to your server and your server's URL. Right? So, that's the DSN.

We have traces sample rate and profile sample rate. And what this does is, if you set it to one, that means 100% of the traces and profiles captured during a session will be sent to Sentry. And for development, that's fine. But I would strongly suggest to lower that to like 15% or 30%, at most, like 30. Depending on how much users you have and how often your application is used in production. So, if you're testing, send everything. It's not going to be too hard on the quota. But if you're pushing this to production, you have to scale down.

When you're thinking about Sentry and how Sentry is priced, like I mentioned, we have multiple plans. You can also self host. So, then, you know, whatever. But this is really important to understand. We do have certain quotas for certain parts of the application. Like error monitoring. You can have up to 5,000 errors a month. On the free plan, up to 50,000 kind of elsewhere. Tracing, you get 10 million spans across. Session replay, you get 50 replays across, et cetera. But as you scroll down, what you'll find is that if you do need more, you can actually increase to, I don't know, 10 billion traces a month. Obviously, none of us need that. That's a ridiculous number. But for the majority of us, it's not just about the quota or the cost. What it's about is whether it's useful or not. So that's why, again, we highly recommend that you set these sample rates. When you're first in production, set them low. Set them very low to start and see if you need more information to be able to debug effectively.

What it's about is whether it's useful or not. So that's why, again, we highly recommend that you set these sample rates. For this case, yes, set it to 100 so then that way we can actually capture these as we're doing this and make sure that we capture all of them so that we can trace effectively. When you're first in production, set them low. Set them very low to start and see if you need more information to be able to debug effectively. You do not need every single instance of someone running into the exact same error to be able to debug effectively, right? You need a few instances of that to capture the variety of your users and their network, you know, reliability and their devices and all of that. You need a few examples of that to be able to debug, trace, and resolve issues effectively. When you're thinking about this, again, in my opinion, when you are leveraging tools like Sentry, when you're leveraging AI, whatever you're leveraging within your developer workflow, use those to be able to allow you to kind of elevate your thinking and become engineers again and not just kind of code all day and think about like, how is this going to be used? How is it going to be used by my users? How is it going to be used by my team? How am I going to use this debug? And set your sample rates and set up your project to match that. Okay, I'll get off my soapbox now. Awesome. So we have Sentry installed. Should we just show also what changes were made with the, we do have that global errors but what are the global errors? The global error is like an extra stuff. It's basically how you handle errors that bubble up from any component in the UI tree and Sentry adds that. That's like stray errors. We also want to make sure that we send those to Sentry. That's the global error basically. There it is. The instrumentation.ts file is still an next JS thing. There we go. And this is basically how we register the server and the Edge SDKs when we deploy and run this. I don't know, for example in our servers it's going to be the Node.js or if we deploy as a serverless on Vercel, it's going to be the second if the runtime is going to be Edge. So we want to set up the Edge config configuration. Which are those at the bottom there? We added three. So we've got the replay integration was added because we said yes to including replay. We have a traces sample rate of 100% as well. Replays session sample rate and replays on error sample rate. So this is the likely, this is set to 10%. You can again set it to 100% while in development, which I'm actually going to do. Just so then that way we can kind of see everything and then every time there's an error, we're going to also get a replay for that. Yeah, so that was like 10% in case, just like 10% of the sessions if you want to see how people generally use your application. But if errors happen, then we definitely, yeah, in case of an error, we definitely want to see a reproduction. Awesome. And then we have the Edge in server and these are also important because we are missing something. Okay. These two, when we, as I mentioned, when we deploy either on our server, on a VPS, or in Vercel, or Netlify, or whatever we're deploying the next application, this is how the backend part of the Next.js application, the backend SDK will be configured. So in order to, because the app I built it as like the content Next.js browser site sends the request to the Next.js server site and then the Next.js server side sends the request to the Django API. So the communication happens between the Django API and the server part of the Next.js, not the browser part. And in order to connect the traits, we need to add one more property here because if we don't add it, when we start the trace, the Next.js part will simply want, it's not going to propagate the started trace to the backend because it does not know what the backend is. And if we don't explicitly tell it to, it's not going to leak out our trace for us. So we need to add a trace propagation targets property here in Edge and also server, depending on where we are deploying. And I'm going to open up docs, so then that way we can, you also know, because I don't know about you all, but I'm not good at remembering what people just randomly tell me when I'm in a workshop or I'm watching a video. Rather I want to know where I can go figure that out later when I'm alone and I'm trying to figure it out on my own. And so, this is our, I'm going to Zoom out a little bit because I'm very much Zoomed in here, which is making it look a little strange. Okay. So, this is our Next.js docs at the kind of high level here. And so, what we're saying is that we need to add in that trace propagation and I think we want to do some, it's not in manual set up, is it? It should be here. If you search for it, you should see it. There should be like a property here because this page is basically here's all of the properties and how you can use them. All of the different ways. Yeah, so you can like, I'm going to find it here. Nope, it's not here. It's going to be in tracing set up tracing. Why don't we just search the docs? Exactly, yeah. Yep set up tracing. Okay, so we've got set up tracing. Here we go. Trace propagation targets right here. Yeah, it's an array of either temporary or long-term logs request site and we can go to data source from our Next.js Docker here. So, we have a data source here that we need to yeah, it's an array of either strings or regex matchers and what we're going to put inside of the array is going to be two strings localhost and just API. Yeah, so localhost instead of my project, but this is going to be your URL when you deploy it. I'm just like literally just localhost without HTTPS, without anything. Yep, and then the API just grab the whole thing and just put it into a string. I am not used to, oh my God, stop pretending to think you know what you're doing. Okay, sometimes our editors get too smart for us. Yeah, so we need this line in the server config file as well. Just in case we want to deploy this on serverless versus sale in both cases, we want to propagate the trace to the django site. So then when we open tracing in Century, we can see the whole operation flow. Beautiful. That's it. Perfect. Yeah, so now it's running and we should just stop the Docker and rebuild it. Yeah, we have new stuff in the requirements of txt.js. In package.json, so just rerun the builds command. If you want to stop it, you just Ctrl C to stop it and we're going to rerun Docker compose up build. All right, in a few minutes we're going to make sure that we can actually start tracking an error and I'm going to show you the Century interface and then we're going to take a short break. So if you have any questions before that short break, please feel free to start asking them in the chat now and during that short break, you'll have an opportunity to kind of just explore Century now that we have it instrumented. So yeah, just wanted to kind of give you that fair warning. Alright, we're going to back over here. Oh, was there an error? I wasn't paying attention. Try to refresh, but I think I saw something. OK, yeah, very nice. OK, let's see. Let's debug this then. Module not found in the app next config. Can you scroll a bit up? Oh, there's an error. Well, it's not an error. It's at the top, but it's going to be a type error because it's a js. Yeah, we don't worry about that. Can you open the terminal and scroll up a little bit so you can see what's the actual error? Century next js. That should have been loaded because we did add Century next js in the package.json.

So recreating this Docker container, install Century next js. There we go. OK, let's try this. Can you open the Docker? Can you open the Docker application?

Yeah, there we go. So we need to probably say Docker compose down to stop this container because right now it's like it's paused. Yeah, let's just make sure that we recreate the container. So Docker compose down. So go back to the Docker app. It shouldn't be nothing. Yeah, there is nothing there. Let's just run the build command again. This setup in particular is just tricky also because we're using Docker. As you saw, setting up Century on just the front end was just using the wizard on that back end was just adding in to the requirements and then, you know, adding in the init for the Century SDK and then the only other thing that we did was add in this trace propagations here. So it so we connect the two projects. But it should work now because I didn't see the module not found.

All right, good point. There we go. There we go. OK, so here is our flashcards app again now with Century running. So there was a couple of things that happened when we ran this the first time and I want to just show off a little bit about kind of what's going on. So one thing was when we went to go practice, it was kind of slow if I recall. I think that was one of them. So we'll click on practice. That was a little bit slow. In general, we'll say start practice session. That's slow for sure. So this might be an issue that hopefully will capture something about sleeping smartphones. Of course, I almost said the, you know, bedding department. Same thing. So we've got that. And you know what? I just want to play around with this app a little bit more before we open up Century, see if we can find any other issues. First of all, I I don't know if you know this, Lazard, but I actually opened my own store. Oh, yeah. It's it's it's so, you know, without the H. It's actually it's actually just called Dr. G. Yeah. Yeah. So I go by Dr. Guthals elsewhere, but Guthals is a hard name to say. So a lot of people just call me Dr. G. And I think that's that's that's the name of my my superstore. You can find it on the on the side of the river that I live by. So we'll go ahead and create it. OK, cool. Category created. And I'm going to just open up a flash card and I'm going to say, like, you know, where where we're going to have to say where right we're just doing this. So maybe like salmon. Where are you going to find that? Well, obviously, on the big rock to the left. Right. And we're going to add this to the Dr. G category that better be a bug because I'm OK. Apparently that did not get added. Yeah, well, fine. Category created. Still it did. It did. So that's that's kind of annoying. I want more, more things. I'm training a whole new group of people on my super stores. So I'm going to add a bunch more flash cards so that they can practice this in their free time, because that's the kind of business I write. I'm just kidding. I would never actually do that. But let's go ahead and just, like, add a bunch more flash cards and and make it look like we've got so many products in all of our super stores. I'm going to wait for this last one to populate and I'm just going to like scroll down to the bottom. Let's see what we have to say. Oh, do this. Right. Rooks. You know what? This is not in science supplies. This is actually on the river. I don't know why. But just keep them there. OK. Is that a bug? Looks like it. There we go. Oh, I mean, that was slow. It did update it. Whoa. Whoa. OK. Sorry, I rage clicked for a second there. Sorry. OK. I think I think we've found some bugs, hopefully. So let's let's just go ahead and and go into the school. Yeah. Let's.

Let's. You know what? I'm going to. Oh, look at that. So we already have a couple of issues. So we're going to do that one. And I'm also going to show off this one here. So we're going to select both of these projects. Notice that here in the issues view, you've got the ability to select which projects you want to be looking at. You can also specify which environments. In this case, we only have one environment. We're not specifying environment. So that's fine. But you could have a development environment, a staging environment, a production environment, et cetera. And you can also specify your time range. So we can say the last 90 days, even though we've only been doing this for the last hour. But that's just kind of the default.

Another thing that you can do is you can filter or search so we can look for things that are unresolved. We can look for things that are high priority. And Sentry allows you to do any kind of kind of custom tagging, which you can also then search for specific tags here. But even just with the defaults, what I'm seeing here is that we've got two issues happening. Oh, category name too short. I bet that's what happened with my category. So that's interesting. And then we also have this value error. And then we also have the syntax error. So I don't know. Let's refresh also, see if anything else has popped up. No. I don't know. Should we start with the syntax error? That one has this like skull and it says unhandled. Yeah. Yeah. We can get into it and let's see what it says. What it's, you know, what kind of data it gives us. Yeah. Okay. So this is our issue view. We can see that, you know what, did we not update, upload our source maps? We did not. Oh, cause this is not looking super useful. This is not looking super useful. So I definitely want to do that. But we do have like a little bit of breadcrumbs. I think we need to update our source maps. Yeah. It's going to give us a lot more. Let's do it. Guides, source maps. All right. So source maps is going to actually enable readable stack traces for your century errors. This is obviously going to be really important because I don't know about you all, but just kind of reading this not super useful. And also this is what I would get if I was just debugging locally. Right. And I just opened up the DevTools in Chrome, like this is what I would get. And so I want something more than that with my debugging partner, AKA Century. Okay. So let's go ahead and use the CLI maybe. Yeah, we can do that. We just need to tag the release. Yeah. Yeah. But I'm thinking because we are running the Docker with NPM run dev. Right. When we are actually building the application with NPM run build, the Next.js SDK will automatically upload the source maps for us. So I guess what we need to do is either modify the Docker file if we wanted to for the Next.js or just do build and run locally. But let's actually try the Docker. So the last line in this file, NPM run dev. We don't want to do that. Let's do NPM run build instead of dev. And then append more strings. And then we'll do and ends like a double ampersand. Yeah. And then again, NPM run starts. Instead of that, we want to do start. So this is going to do that for us. You know, it will invoke the build command and then it will start. The build command will get all of the source maps and upload them as artifacts. So let's try this. We do have the dot env, sentry build. That's important because that's the API key. It's going to authorize the computer to upload in our name. Yes. Yeah. So again, compose down. And then rerun the command. One thing I want to mention with our Docs is again, you can search all of the platforms. So even if we don't have necessarily like a specific SDK for one of the billions of JavaScript frameworks that exist today, the basic JavaScript SDK supports all of these different ones. So you can jump in and get Docs that are specific to whatever you're using. And that's just the JavaScript here. We obviously have others as well. So you can hop in and see if you weren't using Django specifically, but you were using, I don't know, fast API or Flask, then you can specify those here as well.

So let's retry some of this stuff and see what's going on here. I'm going to retry adding in Dr. G here. It's still loading. Can we look at the logs? Yep. Oh, it's still actually building the... No, not again. Okay. But at least it showed us. Okay. Go back. That is the logs. The category name too short that we just saw. And that's fine. Can you go back and like, yeah, restart, refresh the browser again. Yeah. And try the same process. Yeah, it's pretty fast this time. Dr. G. Yeah. So it says it's created, but it's not created. Now let's go and see the new sentry error and hopefully it will have source maps. So eight minutes ago, okay. And there we go. So just by adding in the source maps, we actually get the code versus just... This is on the Python site. We do have the source maps on the Python site, but we also have the source maps on the... That should have been the other error. Yeah. Which... We didn't actually run into it yet. Yeah. Yeah, we don't have... We need to trigger an error on the... Let's see. If we have one that's recent... That wasn't it. This one was the popular... That's an old one. Yeah. Yeah. So when we click on the popular database, sometimes it fails because the LLM model doesn't return us valid data and we can't really parse it and it breaks. So that's how it's causing that issue. Depending on the LLM model itself, we might be trying to cause an error, but this might have actually worked. There's that slowdown again. Yeah. That is very slow. Yeah, but yeah, basically... Okay. Yeah. We need to create... We need to cause an error to happen in the browser in order to see the source maps in action. And the popular database one was... I think it's... Yeah, it's on the river. We did the popular database, but nothing happened, right? Let's see if we can see a new error. Okay. Beautiful. Look at that. That's still in the Python one. Yeah. Sorry. Why does this keep... 57 seconds ago. No, try to select the latest error. That was good actually. No, it's in that one. And try to select not the recommended, but the latest, see if we get it. But this is just a weird error. I don't think it's a good representation of what errors look like. But okay. Yeah. This is unrelated to the codeways and stuff. We can check it out later if we have time. And it's also... It has nothing to do with the category creation. Right. Yeah. But we did get this. Interesting. That tells us something. So we did get... This sounds like it might be a slowdown. We've got an N plus one query issue. We're getting information here at the top for where that is. So just kind of showing flash cards, it looks like. It is happening in production, because that's the only environment that we have specified. We're getting that proceeding span. And we're also getting what the repeating span is.

So we're able to see quickly... Like this is the N plus one. We're doing this way too many times. 237 times. Why would we ever do that? That's insane. A couple other things that I wanted to point out. Over here on the right-hand side, we're gonna get some information. So this is an issue that if you are a Django developer or you are a React developer and you have any kind of Django or Python back end, you might be familiar with seeing this and maybe you didn't know about it. Or didn't ever know kind of what was going on. You're gonna get some information here with some links to docs. You can assign this. One thing that I really like able to set up code owners and being able to automatically assign things based off of where the code is... Where the error is in the code. But you can assign things here. This information here is particularly useful if you are dealing with issues that are like going across multiple releases and going on for a long time. So we can see that it was last seen... In the last 24 hours, we saw this six times. In the last 30 days, we saw this six times. It was most recently seen four minutes ago, but it was first seen 11 minutes ago. And in this case, we only have one release. We're not getting release data here. But in other situations where you are doing something that's more... Like something that is built out more, which I'm going to show you here. So for example, if we have some kind of checkout page, we can see that this one is... Was first seen two months ago and released 24.9.2. But it was most recently seen two minutes ago and released 24.11.2. So we can see that this issue has been happening across multiple releases for months at this point. And so that might be something that you would like to prioritize. As we mentioned, we integrate with all of your different developer tools that you might be using. So you could immediately just create a GitHub issue for this if you've set up your GitHub integrations. We have all of the tags. A lot of these are going to come out of the box. Things like which release it is, where the transaction was happening, et cetera. But you can also specify some specific... Or sorry, some custom tags as well. We've got our suspect commits, which allow you to see where the error is likely originating from. So this error did not show up until this commit happened in that pull request. And with our latest update to our GitHub Copilot extension, we will actually help you identify that root cause, create on the pull request itself. And so we will add a comment to that pull request that says, hey, this pull request is the likely originator to this issue. If it is, you want us to find the root cause and suggest an auto-fix for you, which will create a draft PR. You get a bunch of contextual information here at the top, which is similar to the information that we saw here on that sidebar. You get your stack trace. This is going to look different from when we are making database queries over here in a backend. In the front end, obviously, this is going to look more like just showing you where that code is. We get our session replays, we get our breadcrumbs, and then we move into just additional data. So this is a super high level view of what an issue looks like on the front end and on the backend. We can jump into a full trace to see what was going on. We can look down here even to see just kind of any time. I think it was this one maybe right here. It's like this. It's the one that was selected. Sorry. The one above. Yeah, that one. Yeah, this one up here. I mean, in any case, the point that I'm trying to make that you can trace the issues and you can see like, okay, there's this 15-second slowdown right here. So what is that actually kind of representing? This is the tracing thing that we mentioned. Because we can see the Next.js logo and the Django logo in the trace, that means we connected these two with the trace propagation targets. So starting from the Next.js server, Sarah, can you click on the one above that one, the HTTP server on the flashcards? That one. Yeah. So we can see that the Next.js server sent a GET request on manage. Actually, the browser sent a GET request on slash manage. And everything that's happening in this trace or in this span is happening on the Next.js server side. And then we have a page component, a page server component, which is a React server component that sends the HTTP GET request to API on port 8000 slash categories. And that's how we get categories from the Django back-end. And if you look into it, you'll see the Django logo, right? So now from this point on, everything that's happening is happening on the Django server. And we can actually see what's happening on the Django server and also what happened on the Next.js server. Both of the projects contribute to a single trace, right? And the auto-grouping there, you can see, we have, there we are, basically the request jumps in between the middlewares that Django has defined. And then it enters the GET all categories in the API, right? So that's basically how we can look at a trace and literally follow it from the browser to the Next.js back-end, then to the Django back-end, which is a totally different programming language, even, right? And then we can also go back and see what happens from that point and how the request is returned to the browser. But yeah. And as you click through different spans in this trace, you'll be able to get additional information. So for example, when we do click on this DB query, which is that select category, we're able to see the query right here. We can even copy it so that if we needed to run it elsewhere to kind of test something, we get some general information about what's going on. And you're able to kind of decide how you want to debug this further. You also get things like web vitals. So you'll see up here, here's our LCP, and you'll get kind of all of these web vitals as well listed right in here. Yeah. Especially important, for example, if the page load is slow, you're going to see what happened on the back-end that caused the page to be slow. And if the page is slow, that means probably the TTFB is going to be a big score, et cetera. So yeah, that's why it's important to have those two. We're going to call out some of this slowdown. So 7.9 milliseconds isn't horribly long, but it is something that we do have like an error associated with it. And so we can follow up with that error. I do want to give us a short break. You know something that we never tried? What happens if we don't have any flashcards yet? No categories, no flashcards, cords, no flashcards, nothing is there. Okay. But I try to practice. Oh. I don't know. Did you think about that when you were building this? Because I like to break things.

Not really. All right. So let's see how this goes. So I'm going to go to practice. There we go. All right. There we go. So you definitely hard-coded something in here without any kind of catches. So maybe this might have been something fairly simple to kind of catch, but you know, like it doesn't really like, okay, not a ton of information. You're not going to miss anything. You're not going to see this in production. Plus it's not going to be your computer. It's going to be your users computer. And they're not going to send you a screenshot. No. They're just not going to practice. And then you're going to have a bunch of employees who don't know how to do anything. It's going to be horrible. Okay. So let's go ahead and go back to our issues. Hopefully we found something in that. So I'm going to go ahead and I'm going to open up our flashcard one for the front end now. All right. So that was that old one, but we did just 57 seconds ago, get this type error. So let's look into that. Okay. So we've got some information here. So we've got a full trace again, just like we saw with our backend error, we have that it's unhandled, that it can't read properties of an undefined something. We have that it's actually in development and that it was on Chrome. And we do now have our stack trace because we did upload those source maps. So we can actually see this right in here. So this is something that we were able to see with that other error message in the browser, but we can set up code mapping and actually be able to open that inside of GitHub right away, which I absolutely love and highly recommend. And we get our replay. Our replay also gives us some, or we also get our breadcrumbs, et cetera. So let's jump into this replay real quick, because we had some questions about that. Okay. Like I said, replay is one of my absolute favorite features of Sentry because it is that video like reproduction. So we're going to kind of scroll back over here. We're just going to click play and we're going to watch this a little bit. Notice, so this is what was happening before we ever even got the error, right? I clicked on that delete, you know, wipe the entire database. And one thing to note is you're getting a lot of asterisks here, right? And as I mentioned, we are privacy by default. So that means that when you set up session replay, you're going to have all texts and images obfuscated by default. This is to reduce the likelihood of accidentally like seeing or sharing or releasing or putting onto Sentry servers or having your developers look at any sensitive information or PII, personally identifiable information. We don't want things like credit cards and stuff being shared out. Notice though, you can actually configure a replay and this element masking, blocking, this is going to, we can open this into kind of a new tab here, and we can see that it's very simple within that config file, you can actually specify like, you know what, none of my text, this is a static site, I want people to be able to like use it, but there's no way that there could be any sensitive data in my text or my media. So I'm going to go ahead and just allow all of that to be unmasked. And specifically, if you are using the latest version, you can have like specific information as well. Okay. So those are classes that you can add to specific elements. So if an element has the Sentry unblocked CSS class or the data Sentry unblocked data attributes, the session replay is not going to obfuscate that with like, with stars or asterisks. It's just going to give you the full text. That's how you can selectively pick. I want like, this is not a PII. This is part of the layout or the UI show this, for example, wipe database. There's nothing personal about wipe database and it's constant, right? So we can do that or the labels that we see here, we can add those classes to those elements and they're going to show up as the text, but that's on our responsibility. So if we add those classes to an element that could be PII, that's a mess. Yes. Also obfuscation is happening on your client's device. So we are not sending that information to Sentry and then obfuscating, we are obfuscating on before it ever gets to Sentry. So because this is a part of, this is an SDK, that's a part of your application, we can do that. Notice that as we were doing this, we're getting things like the replay started, users were clicking, we're getting navigation, we're showing kind of where they're clicking. So that's great. We can continue to kind of scroll through this. We can fast forward through inactivity if we want to. And as we're doing this, we're seeing the breadcrumbs follow along with us. So at this point, when we clicked on the practice, we got a bunch of different types of errors that were happening. So it looks like we tried to like make a few different calls. It's not working. And kind of that's what we're seeing here. And then we're getting that error message. So this is again kind of giving us that high level overview of exactly what was happening on your user's device. We also get what you're used to, with local debugging, like your console output, so we're getting some like, I think this is just kind of anywhere. But we're getting, like if you were to be able to debug this locally, but the issue is you're not always debugging locally, right? The issue might only be showing up when your users are on a really poor network or when they're using a really, really old device. One of my favorite folks who talk about performance in general is Henri, he goes by Henri Helvetica, and through kind of the RUM archives. And he's been talking about kind of this issue with the number of really old Android devices that exist in the world that are being actively used every single day is incredible. Like, you should look this up. You should be informed by this, because not everyone is using the latest devices. Not everyone is using the latest operating systems. Not everyone is using, you know, high-end networks. So being able to understand kind of who your users are, what they're actually running on, and recognize that you will not be able to recreate every single one of your user's issues. Works on my machine doesn't work in this world anymore. We also get all of the network calls and responses. So we can see here, we're just getting a bunch of, you know, good things and then we're getting kind of this, we don't know what's going on. We're also getting all of the errors listed here. We can get a preview of the trace view right in here with that error. So we can start to debug more and see, like, oh, what was actually happening here? Okay. We were trying to resolve, we're trying to do a response, and then maybe we try it again. Maybe we go back to the back-end and try to get something and we're recognizing all of these issues. And then we've got... What's cool about this section, can you go back to the trace to show you my favorite feature? There is a play head that follows you.

There we go. You see that when you hover on it? There's a play head that goes into, like, on top of the trace and it shows you what happens on the back-end and you actually see what happens on the screen. So, like, this screen right here is, like, And that's actually happening across, right? Like, yeah, whichever you're on, that play head's going to be going to be following you. Yeah. So that's, like, the craziest thing. Like, on the left, you see what's going on on the screen, on the user's monitor. And, again, this can be any user on any part of the world that's using your application. But on the right, you actually see the trace and what happens on the Django side. At the same time. So this is, yeah, this is debugging superpowers, if you ask me. Yeah. 100%. Okay. So that's session replay. We have... You know, you've got your full trace here. We've got all of that contextual information here. We've got the stack trace. We've got the session replay. We can probably debug this now and figure out, kind of, what's going on. Yeah. Well, we kind of know, technically, right? Because on the front end, when we tried to create the category, it said category created successfully. But we also saw that issue, category is named too short. So it's... That tells me that we're not really handling the response from the server, or the server doesn't respond in a specific way. We can dive deep into it and actually fix it on this workshop. But I think that's, like, enough information right now so we can get into it. We don't have to do that at this time, but when you connect the dots, this one says name too short, this one says category is successful, then it's the communication between those two. So I would just go on the client site and go to the place where I'm making the fetch request, when I'm making the post or patch. I don't know what it was, but I'll go there and I'll see how I'm making the fetch. There's most likely A couple other things I just want to point out, we do have insights, performance kind of insights, we split them up between front end, back end, mobile, AI, so we can see that our front end, which is this project in particular, we get a lot of insights from that front end. So we can see that this is our front end, which is a project, and that front end is our back end, which is a project. But we can see that our back end, so we can see that our front end, which is this project, in particular, we get some best opportunities to make some improvements on our performance. So that practice page, every time we went to go practice, we either got a bug, like an error or crash because we didn't have any flash cards, or if you recall, it took forever every single time. So we could start to look into that being an opportunity to explore making improvements. Our manage was meh, like it is not great, but it wasn't horrible. But that practice one is absolutely horrible. And then we also had this for when there's that error. You get your P50, your P75, you get your P95, how many users are being affected by this. And you also get this, which is user misery. User misery is basically our metric for how upset your users likely are, how miserable they likely are because of these slowdowns. So this is if you, as I said at the beginning, monitoring, observability, these things imply a sense of passiveness. We want you to be more active. So if you are just getting a lot of reports that don't have a lot of detailed information about things just running slowly, this might be somewhere where you start. You might say, okay, let's just find the lowest hanging fruit. Where is the biggest opportunity for us to make a performance improvement? And you might start from kind of these insights here. Yeah. So let's check out this slowdown that we saw when we tried to do a practice. And it was like spinning for a longer time. In order to catch that, I would take that to in two different ways. So first we saw that we got the N plus one. The N plus one told us that there's something going on. N plus one means we are requesting the information for N number of resources on the backend. For example, if we're asking for flashcards, we're asking for details for 237 flashcards, if I remember the number correctly. So we're asking for 237, but then plus one, which is give me all of the flashcards, right? And most likely, there we go, 237. And most likely these are being invoked in a waterfall fashion. So Sentry already notified me as a developer. Look at that. You see that waterfall? Yeah. It's like one after the other. It's so long. We need to look at this in the trace, but yeah. Look at that. That all happens in a waterfall. Exactly. Yeah. So one way is Sentry telling us, you have a terrible mistake in your code and it's causing N plus one issues. Go and go and fix it. Right. And if we go into the trace, we're going to see where we are. So can you go into the trace? View full trace. And there we go. That is the flashcards. Expand that one. No, the one that's blue selected. Yeah. Yeah. Dig into it. And there are the 237. You see? Select category, select category, select. That's what's causing the slowdown. But let's figure out where it is because right now we have no custom instrumentation, right? This just tells us that there's a lot of database calls. And I don't think there's a valid scenario where an application truly needs to create 237 calls. Unless it's like Cron job that does something that complex. Yeah. But what tells me, what I can see here is I can see the view dot render methods from Django that says, get all flashcards and it's in the API. You see that? Three spans above the currently selected one. You can see the view render. Yeah. Get all flashcards.

So we can, we can dig into that. Right. We can go into the Django project, the Django project, go into the API source that's going to be shared. Presentation and then the rest and then the API. So this is where all of our routes are defined. And there are the two routes of categories and flashcards. What was the again in century? Yeah. Basically this is where we define the routers flashcards. So if it's a flashcards that we, we should look into the flashcards directory or the flashcards router. Go to the definition. Yeah. You can do that as well. There we go. So what was the get all flashcards? There we go. So inside here, this is where things happened. We can see that we have a flashcards query and we're invoking the get all flashcards method. This is CQRS. Let's get into it. And as you can see, we are missing instrumentation. We are invoking a bunch of stuff, but we need some instrumentation. So let's actually supplement this part right here, Sarah. So if you can import the century SDK at the top. Do the import. And I'm going to open up our docs so then that way everyone can follow along that way as well. And we're talking about Django now. Yes we are. And we need to go to tracing. We need to go to tracing somewhere. Set up tracing. Set up tracing. Nice. Custom. There are two ways. So first is we can import the century SDK and we can use the ContextManager. There we go. We can use the ContextManager if we want to wrap multiple areas of a single function using the with keywords. So if eat pizza contains multiple units of work. Let's say not the U of W design pattern, but just like multiple units of work. We can use the... We have to use the ContextManager here. But there's a better way, at least to me, and that's using a decorator. So instead of doing that, we can just add the century SDK.trace on top of the function. And that's going to be the tracing function. So we enabled tracing for this function. But if we want to add multiple spans in a single function, we got to use the ContextManager. So yeah. Let's just go and add the century decorator to all of the methods here. Just copy paste that and instrument all of these. Instrument all of these and because the issue was in the get all flashcards, right? Yeah. Let's get into the flashcards repository.findall. Let's get into that one. There we go. And add the instrumentation on here. Add that and also import the century SDK at the top. So we're going to do this and then we're going to go back and add instrumentation to the rest of these methods. findall, findallById. While we're here, let's just instrument all of them because it has to be someone here. What else do we have? findById, and that's a static method, delete. If we want to do that, we need to add the decorator above the static method. What did the doc say? Yeah. Let's see. Static and class methods. When tracing a static or class method, you must add the century after the static. Okay. So we are wrong. We need to add the century trace after the static method decorator. Otherwise, it's not going to work. There we go. Okay. So this should be enough. Right? We should be enough. Let's just save it and rerun the Docker setup. And just as a reminder, so we were in here and this is where we saw that. So we're hoping to get some additional information here. Yeah, we want to see where exactly. We need to re – we don't need to re-Docker. Hopefully. But I'm not super comfortable in the reload mechanism. Let's just not rely on it. So what we're showing here is Century does do auto instrumentation out of the box. You're going to get a lot of what we already saw. So that was already fairly useful. We already get some information. We're already able to debug a lot more. Not only because we're getting that additional information and contextual information from Century. Sorry. Zoom just told me that it thinks that I'm speaking French now. Oh, me too. I thought it was my accent. Okay.

Sorry. That was distracting. Anyways, you do get that auto instrumentation. And actually, this is the Doc I was trying to show. You do get a lot of auto instrumentation out of the box for the majority of our SDKs. However, We saw the DB spans, right? Those are automatically instrumented. Right. However, again, because we're leveraging a tool that is so rich with insights like Century, we are able to stop worrying about all of the little bits of auto instrumentation that Century is setting up for us and instead think about how our app is going to be used and how our app is built so that we can apply some custom instrumentation that will be most effective for the types of bugs we anticipate that we will be debugging in the future. So, while getting started with Century is fairly simple in terms of adding in those or rather instrumenting with the SDKs and getting that auto instrumentation, we do highly encourage that you take a moment after you've run it for maybe a month to see where are your bugs, where should you add that custom instrumentation, and send those additional spans.

Okay. So, I think we are ready to go. Let me refresh this now. What was the operation flow that we were tracing? Can you go back to the trace view and see what we need to do on the front end to trigger this again? I'm pretty sure this was just where we were Get slash manage. Yeah, on the next side, that's the get slash manage. So, we need to go to the manage page and do a few refreshes or something like that. And this is probably cached now. Interesting. It's going to be fun to see if this shows up. But yeah, you see how fast it is. It's probably because it's cached. Also, yeah, our numbers didn't reset. Interesting. Okay. So, let's go back into here. All right. Let's see if we get a new event here. If we get the n plus one, we might not get it. If next JS keeps everything cached. I'm wondering if we write and then repopulate. Let's try that.

Yeah. But it needs to be a page load. It was on get slash manage. So, it needs to be a page load. That's the case. And then? I have a solution for that. Yeah, it's going to be fast. Yeah, this is next JS, basically. Let's go and let's check this out through the second approach that I mentioned. So, go back to the Sentry dashboard. And we're going to go into the performance page this time, not the issues. So, we'll go into the performance and we're going to try to find the get slash manage transaction. So, click on the all transactions, and we should see it in the list below. There we go. It's the second one. So, go to sampled events. And this is going to show us a list of all of the events that those are only the slow, the slowest events. Those are not like the latest events. We can change that. But if we go to the tab sampled events, yeah, there we go. We can see a list of them, a whole list of them. And the timestamp is UTC and we're not in UTC. So, I'm not sure if that's the one that we're looking for. So, just like click it anyways. Let's see it. November 14 is from today or maybe it's just all, I don't know. Okay. So, go to flashcards, the second one. Drill into it. It doesn't look like it's there. Yeah. So, this is definitely next JS caching. Let's try to do something about it. Go to Visual Studio code this time. Go to Visual Studio codes. What can we do? Go to the manage slash page.tsx. You can just like search for it. It'll jump into the file directly with command B. I know. Hang on. Just let me find it this way. My brain doesn't work that way. Okay. Yeah. It's annoying. You want to do manage flashcard? Yeah, but it's going to be in the web, not the API. Yeah. So, source app manage page. So, let's see. We do have cache no store and that's where the fetch is happening to get the flashcards. So, this technically should cause that, which is weird that it didn't, but maybe we're missing something. So, it says cache no store, right? Yeah. Something is caching. And if we had, if I had put in a proper caching mechanism, I would have figured out what the issue is. This is the right project, right? Yeah. So, I don't remember we had the slowdown in this one. Let's see. I mean, we had to slow down here and start practice as well, but we weren't- Yeah. Maybe we should trace that. So, it's more intentional.

No, it's not going to show up as a, probably it's not going to show up as an N plus one. So, we need to see it. We need to go to the performance, go to the performance page. Now, we need to find that transaction and that transaction should be either get on slash practice, or let's see, that's a page load. The page load itself might not be slow, right? It's three seconds, not the slowest, but it's not the fastest as well. In order to figure this out, can you go back into the flashcards application and, no, no, in the tab in the application.

Go to practice, open the inspect element just so I can see what we're doing. Yeah. And now, go to the network tab so we can see what request we're doing. Click on this start practice session. This on the button, start practice session. Oh, sorry, my brain. Yeah. Just go back to the network tab. Flashcards. Okay. Is that the request that we sent? Probably not. Clear up the request and try to pick a different category, because that's where the slowdown was. Pick a different category from the list on the left. Yeah, that's the slow request. You see the flashcards one that is still pending. So, click on that one and let's see which one, which request is that. Go into the headers and that's going to be API categories, the category ID, and then we have the flashcards. That's what we need to look for in the performance right here. There it is. So, in the sampled events, we should see some events there. Oh, yeah. 12 seconds, 11 seconds. Yeah.

And by the way, what we just did here, that's just because we're running a demo app and trying to force us to be able to see a simulated slowdown in the last few minutes of this workshop, not because you would need to do that while you're actively debugging. These would show up if they were actual problems. I just want to call that out. And if we had more than one user as well. Yeah. So, let's just make sure, G, that we're actually selecting the latest one after we traced it. So, that was not the latest one. Go back and go to the sampled events. These are not the latest. Yeah. There we go. So, this is from 6.04. I don't know, maybe it's that one. No, I think it's this one. It's based on the timestamp, right? Yeah. Okay. See if we can find one that has been... That does not look instrumented. Click on the timestamp on the header. Yeah. On the header itself. Yeah. There you go. Which one is the latest? 6.50. Okay. Yeah, that's the one I just found. That one also has... Okay. And the selected one is the last one. Okay. Good. Try to... That's the only thing. Well, we're not even making the request there. Oh, we are, but for some reason, we're missing the trace. That means the backend, we didn't actually rebuild the backend. Because we should have seen it there, just like we can see it above in the older... Yeah, it's a Docker configuration. Again, I'm really sorry. Let's just go ahead and try to rebuild it and rerun this. And actually, we didn't even instrument this one, right? This was the instrument in the get... So, let's go ahead and add that in real quick. So, that's going to be on... It's going to be an API source in category, actually. Thank you. Category, yeah. Presentation. REST API, scroll all the way to the bottom. Will we want to import now? Not here, because we already have this. Yeah. So, that's the getFlashcards for category. We have two. Firstly, we have the getCategory, and then we have the getFlashcards by category. So, both the category query. Did you see that? That's not the one, that's a delete. That's the one I'm talking about. Yeah. GetCategory, and also the getFlashcards. Yeah. These are not instrumented, you see? So, we need to do this again. That's why we're not actually seeing anything.

What are you looking for? Anyways, it's fine. I just... Underscore as a game. Thank you. And we need to add the... There we go. Now, it's smart. Okay. What else do we have there? We had this query, but then we also had another one, right? We had the... Oh, it's the category query. So, it's automatically... Yeah. Already there. Yeah. Okay. Okay. So, this is the Flashcard repository. We also have the category repository. Which one did we instrument? Category. No, from the repositories. You see, these trigger the repository methods. So, get into one of these. This one is. So, this is the Flashcard repository. Let's go into the category repository as well, because we are using... There we go. So, we need to also instrument these, right? And this is basically drilling from the API, all the way to the place where we communicate with the database. So, this is going to set up that whole trace that we actually need. Nice. Alright. So, we got to rebuild now and let's make sure that we are rebuilding. Compose down. We did decompose down. Okay, cool. Let me... Well, let me make sure. Okay. Okay. You see that cache? You see that cache? Yeah. So, it did not send everything, but let's just say that it didn't send stuff that we don't need. Yeah, see, it's the app. Okay. Alright, let's see if it works now. So, we need to go and trigger the slowdown into the practice session. So, not the page load, but when we click on the button or change the category. Yeah, it's building it in the background. Yeah, there we go. Alright. Alright. Let's go to Dreamcatcher. Alright. There's that slowdown. So, hopefully, we'll get to see the trace if we connect everything correctly. Okay, nice. So, now if we go, we should see another one that ends on 57. There we go. 56, 57. There we go. Alright. So, let's drill into this one. What do we see? That is very weird. You see that we have an HTTP GET that sends the request to that one, but we don't actually see the Python side to it. That's weird. What if we approach it from the backend side? Like, go to performance and select the Django project, not the Next.js one. Okay. What do we have here? Do we have the one that we're looking for? Nope. Right? There's GET CATEGORIES and FLASH CAS, but we don't see the one which is CATEGORY slash CATEGORY ID. That's why we're missing it. I guess something happened in our build. Well, in any case, we're pretty much out of time. So, if you have any other questions, please ask them in the chat, but, you know, essentially, the custom code that we need to run. So, as a reminder, our trace view allows you to not only trace within a single application, but also across multi-service applications. So, from frontend to backend, you hopefully got to see that and got to play around with that a little bit, and you're able to do that without losing context and without having to switch in between different things. Let me just close out Slack, because that was annoying. Okay. We also have things like session replay, which allow you to get those video-like reproductions of your user sessions. Again, obfuscated out of the box for privacy reasons. Something that we didn't show off today is our user feedback widget, which is a very simple widget that you can just include. You can also customize with your own colors and verbiage, et cetera. But those user feedback widgets are going to be contextualized within Sentry completely. So, you can see that widget popping up there in that GIF, and yes, I say GIF with a hard G. And that's going to be contextualized. It's going to be a part of your replays. It's going to be a part of your bread crumbs, and you're going to be able to see traces based off of user feedback from right inside of there. Another thing that we alluded to but did not show off in this workshop today was our leveraging of AI. I mean, what kind of tech company would we be if we're not putting AI somewhere? In particular, we have a couple of things. One is autofix. So, if you give permission to Sentry to use AI, we have autofix, which will determine the root cause of issues, suggest a fix, and even open a PR on GitHub for you. And we also have the Sentry Copilot extension, which I mentioned, which can be used inside of Visual Studio Code as well as, if you do have it set up, it will comment on the PR that is likely the root cause of the issue with a suggested root cause analysis as well as a PR, a suggested autofix, which will open up a draft PR in GitHub. So, basically, whether you're in Sentry, in GitHub, or in Visual Studio Code, you can leverage the AI that we've included with Sentry out of the box. So, we are out of time. So, I do want to say thank you so much for joining. Again, there's that link. You can either scan the QR code, just go to sign up and put in that code, or go to that bit.ly link, all of which will give you those three months free of Sentry so that you can give it a try. Also, head over to our blog and check out our latest blog posts. We're going to be having launch week next week, which is basically just a series of blog posts and videos to describe some of our newest features. So, stay tuned for that and reach out to us on GitHub, on Discord, on social media, anywhere, everywhere, if you have any further questions. We really appreciate you all joining us. And I hope you have a great rest of your week.