Building a Sentry: 7 years of open-source React

Thank you, everyone, for joining. This is the Building a Century, seven years of open source React. You're going to be hearing from me, Evan Perkizer, and this guy, David Wang. I guess we can start here with some quick intros. So, yeah, who are we? My name is Evan. I've been here at Century for four years now as a full stack engineer. I'm on this team called the Core UI Team, and I guess I can kind of explain in a little bit just what that is, because I think the name isn't super descriptive, but kind of the idea here is that we've kind of noticed as almost any kind of engineering organization kind of natural thing happens where you know you initially when you're small kind of everyone is just working on everything kind of covering all the quarter cases of everything, but as you grow as an organization, you start to have teams that specialize more in like specific things, so the thing that happens when teams specialize is you have kind of these cracks that form within the things that are getting worked on, right? So you know, maybe you start having all these specialized teams, and then little things just kind of start getting forgotten about or like just no one owns them, right? Like at some point, for example, you might have like, oh, no one owns the webpack build. And then it's just like anytime someone needs to do that, they kind of have to like find time to make that happen kind of thing. So the idea of this Courtyard IT team that we have here at Sentry is that we're sort of the team that fills in those gaps, that is tasked with the things that you know, are almost like not thought about. And we think that those are like kind of the really important things to, you know, make the product really good, right? It's it takes it from being like a product that works really well to a product that feels really good. So yeah, so like I said, my name is Evan, you can read about my likes, dislikes and and dislikes. So if you want to like nested conditionals, please only early returns only. And then I'll put it over here to David. Yep. So Hey, everyone, I'm David. And you can see we have this little setup in the corner where whoever's talking is like the bigger, I guess, floating head. So this is really easy to see who's talking. But yeah, I've been here at Sentry for now two years. I'm a Fullstack engineer, and I'm the second engineer on the core UI team. And we only I really have two engineers. So it's a relatively small team. I also have my likes and dislikes here. I didn't really know what to put for dislikes. So I guess I don't really dislike anything specifically. Actually, I like everything. Yeah, I thought pretty hard about this, so I couldn't really put anything down. But you know, that's what I like. So yeah, we're gonna get right into this. So we've introduced ourselves. I think it's due time that we introduce the product that we work on. So this is Sentry. Perhaps you've heard about us. Maybe use us at your own company or maybe on your own projects. But I'm going to go ahead and take some time to explain the justification over why you might want something like Sentry in your application and then go through a quick demo just so you have more context about all the things that we're talking about here today. You have to be clear. It's not an ad. We just want to get some context so that it makes all sense. Yeah. Just to inform the audience. So we have Sentry. The way I like to explain it is typically through a simple example. So we're probably all developers here. Say you have a side project going up and it's a simple checkout page, maybe like an online store, right? Say this online store has a couple of pages, like I said, checkout page, login, authentication, all the basic things that you have, a full stack web app. And you go ahead and you deploy your online store out to the public. And inevitably, you're gonna get some users that run into issues. And initially, if you're just handling a very small user base, what might happen is they'll send you emails and one user might be like, oh, my gosh, the checkout page doesn't work. I have all these products in my cart. I'm trying to get these products, but they just don't check out. I get this big red error on my screen. And then you have to engage in this back and forth with this customer.

There's probably some better channels for it. But say you're just doing it over email, there's a lot of back and forth. And if they're a nice customer, they might send you some more information like what browser they're using, the version of the browser if they can even get that for you. Maybe they can even go into the logs, like the console, if they're really good, and they can send you all these things and it's really nice. You can have this back and forth. But obviously, this isn't very scalable. Say you have thousands of customers. You can't be having these day-to-day interactions when you're trying to build out new features.

So this is where something like Sentry can come into play. So if you put Sentry into your application, anytime users run into errors, we're going to float up an error into a dashboard, and you can view that basically whenever you have time, or you can set up alerts on that. So that's what we're going over right now. So I'm going to flip over to Sentry. We have a test organization. This is actually the sandbox feature that we recently created. And you can get to this yourself if you go to the Sentry webpage. There you go, sentry.io.com. There's a sandbox demo, and you can just register for that. And you can poke around Sentry yourself. So I encourage you to do that if you want to check out more afterwards.

And we have this organization. It's called Peaceful Rhino. This is just like a test name. You know, don't worry about it too much. And also on the right-hand side here, there's my projects. And, you know, say, for example, this is like a full-stack web app. And we also have like mobile application, so you have Android, iOS. You know, we support a variety of different languages through our multitude of SDKs. But because this is a React conference, I'm going to go ahead and select React. And these are examples of issues that users can actually run into. So this reference error, for example, I'm going to click into this, and this is an actual issue. You can see that scrolling down, we have certain contexts that we want. So the version of the browser they're on, for example. Maybe the actual user that you have, their email. So you can look into more logs in the database. You have even the OS. And scrolling down even further, we can see that there is the Strap Trace, which is arguably some of the most important information you can have here. And even you can track breadcrumbs. So if you want to see specifically what happened leading up to this issue, you can look at this through the list of breadcrumbs that we have here. So I'll just scroll through that real fast.

So this is super useful already, and I think typically when people use Sentry, they think of it as primarily like an error monitoring service, but we also offer things in the form of performance, too. So we have performance monitoring. So we're on the React project, so it's going to show us Web Vital data. This is the, I guess, frontend performance. This is like Google Web Vitals. They have FTP LCP, first input delay, bunch of other things that you might find useful for diagnosing the performance of your application. And you can see because it's an online store, we have the checkout and product store transactions that are going on here. And then finally, you can view this as kind of more of like a passive way to consume Sentry. You see issues, you might log in once a day to look at some issues and look at some performance things, make sure the app is working as planned. But if you want to set up some alerts, you can also do that. So I'm going to go over to alerts now.

And this is like a proactive way to you Sentry, I guess, in the sense that you can set up an alert rule. And this can be based on issues or volume, errors, or even some performance metrics. And you can see, oh, maybe the checkout page is taking too long, maybe there's been a performance regression, or there's a high volume of errors on the login, you just can't get into their accounts. So this is all super useful. And maybe now that you've seen this, you have an idea of you know, the next side project you build, you might want to use this. And yeah, ever since I've, you know, worked at, I use Sentry on a lot of my side projects. I can't live without it these days. I honestly can't live without it. It just feels so much safer to deploy things when you have visibility into what's going on, on the user end. So yeah, that's Sentry.

And now that we've introduced ourselves, the product, we're going to give a quick outline of what the talk is going to be going over, right? So what does this talk about? You're going to be learning a couple things. First off, you're going to see firsthand what a large scale React TypeScript codebase looks like. And you're going to hear directly from us two engineers who work pretty closely with it, how we build it, how we maintain it. And you're also going to be exposed to the front-end developer experience here at Sentry. You're going to see all the tooling that we use, the decisions that we've made along the way, what works best for us and why we've kind of made these decisions.

And then you're also going to see a couple interesting, or rather growth, parts of the Sentry codebase. You're going to see some stuff that probably you shouldn't replicate. And we'll talk about it in more detail. And feel free to ask any questions about that. And finally, hopefully, after all that, you can step away with a working knowledge of techniques that we've used in Sentry to keep the code base modern and attainable, despite how long we've had a history with React here. And you will be looking at actual code in our editors, not going to look at it a lot, but we'll show off some cool things that we like. So you're encouraged to follow along here at github.dev. You don't know about this feature. It's super cool. You can see a web editor for VS Code in here. And you can just kind of follow along. And you're encouraged to ask any questions in Discord along the way.

So, basically, what's going on is only one of us is going to be talking at a time. So the other person will primarily be looking at the Discord, make sure, you know, any questions are flagged up and we'll pause every now and then. And, you know, we'll get these questions answered. So definitely don't save them for the end. We want to interact with y'all as much as possible. And with that being said, I think it's time to hand it back over to Evan. He's going to go over our tech stuff. Thanks, David. Yeah, like David said, definitely ask questions whenever. We kind of wanted just to sort of be in and maybe a little bit more of the form of the discussion. Just, you know, ask about decisions we made, why we made them, stuff like that.

Okay, so I want to talk a little bit about just kind of like stuff that we use, why we use it. Things that we like, just within our tech stack. And, you know, like I said, a lot of the stuff you guys have probably seen. It might just be kind of nice to hear why we use it. So obviously this isn't a back-end talk in any way. This is definitely all React front end. This is a React conference. But I did want to mention that Sentry is powered by Django, the back-end side of things. Mostly these days it's Django is the back-end API. And the React front-end app is more or less almost a single page application at this point. So most of when you're using Sentry you'll be in React land where it's making API requests to Django. We're not real fancy. We're not using GraphQL or anything like that. We're kind of still using kind of the classic REST patterns for things. But we found this works pretty well. That said, it's not always true. Like I said, we've been using React for quite a long time, seven years now. Actually it was like trolling back through the commit log just to like validate that we've been using it that long because React was introduced I think by Facebook in 2013. So we have been using it for a pretty long time. The point I wanted to make here is that, it's obviously not always true that it was a single page application or at least it wasn't born that way. For a pretty long time, it was kind of the classical Django rendered views. I put Jinja here and I feel like some people in the Discord are going to be like Django views aren't Jinja but to me they're very similar.

But yes, so even today we're actually still not 100% completely a single page app where we still have a number of views that do render in the back-end and we have to have some code in the way that we handle the front-end app to make sure that it can delegate back to pages where they don't render the React views. So one of those pages that is probably maybe not obvious, but is the most obvious, at least to us, is the login page and the authentication page. That stuff is all still not in React and barely uses any JavaScript, actually. I think the only JavaScript that we use is for the tabs, where you can swap between sign-in and single sign-on. I think there might be a little bit of JavaScript that we inject for like a password strength meter. So, yeah.

One of the first things I want to mention here is that we're really big TypeScript fans. So we just finished our migration over to just being completely, 100% a TypeScript app. I think our tests are still mostly normal vanilla JavaScript. But we've been converting our test over to TypeScript as well. We have a really, really great blog post about this that we put up. It's on our blog. Definitely go check it out. We'll probably talk more in this talk a little bit more later on, what we like so much about TypeScript. But we won't talk too much about the journey for getting over to TypeScript. It took us about, I think, a year and a half, maybe close to two years? Two years. But we definitely kind of found the benefits were very, very much worth it to get there. So want to mention that in terms of how we actually kind of, like, compile and build the application. It's kind of all the usual suspects. You know, we've got webpack, we've got babel. We do still have a little bit of using the LES compiler for CSS. I guess I probably should have put the next slide after or before this because we used some style component stuff, so that's why we don't have quite as much LESS. But I was going to mention that babel kind of does most of the work here. So we actually don't use the TypeScript compiler at all. We only use the TypeScript checker to, you know, obviously, do the type checking. But I think the way that it works is that it runs as a forked background process. So when you start webpack and Dev Server mode, it will kind of fork off and run a TypeScript checker, but it actually doesn't use the compiler at all. So we have Babel configured so it kind of strips off the type of annotations. So Babel is doing most of the work. That said, we also kind of have a pretty... I think kind of a unique webpack configuration. And the reason that we kind of have this unique webpack configuration is because of the fact that Sentry.IO exists. So Sentry, for a very long time, has been an open source product. And because of that, when you run a SaaS version of an open source product, you inherently have to have probably some closed source code. So the closed source code for Sentry is mostly the completely uninteresting billing code. Like the Stripe integration type stuff. But we do have a number of things on the front end that need to be basically in the Sentry.IO app. So what we've done is, we have GetSentry slash Sentry on GitHub, which is the open source has I'd say 95% of the code that runs Sentry.IO. And then we have this other closed source repository that just has things like upsells and other billing related UI elements. But Webpack is kind of, we've configured it in such a way so that it can compile both Sentry, the open source stuff, and then GetSentry actually augments Webpack and adds a few more entry points that way. Oh, sorry. Yeah, it's actually repo. That way, it can compile all together into one thing. For a long time, it actually worked in such a way where Sentry would be compiled, and then GetSentry would be compiled as two separate bundles. And then for them to interop, we had this really, really janky, like we would export a bunch of stuff onto the global window objects. And then that's just like how they would communicate. I fixed that, maybe two and a half years ago. Because the other problem with that is you couldn't in GetSentry import any components from Sentry without exporting them onto the window object. It was really bad.

It was really bad. Yeah, don't do that. All right. So, yeah, so I mentioned, we don't use too much Lust anymore, we use Emotion. I know that the kind of CSS and JS thing can be a little bit of a hot topic. Maybe not so much these days. I'm not sure. But I've definitely talked to people that are like, why are you doing that?

So, we found that in kind of a larger codebase, which Sentry is, I think in maybe the description we calculated, Sentry has like 230,000 lines of code, or something like that, of just front-end code. So, yeah. So, we kind of found that using some type of styled component thing, where you can kind of maintain your JavaScript right next to the CSS, that is, you know, powering the UI elements, has been really, really valuable in terms of maintainability. Just codiscoverability, to be able to understand that this thing is coupled to this thing. That said, even though, you know, we're kind of using these styled components, I think one of the kind of biggest pieces of hate against them is kind of, like, oh, you're not using the cascading part of CSS. I did want to point out that you actually can still, very much take kind of, like, use the cascading stuff, even when you're using these styled components. One example of that, that I've found really powerful, is using CSS variables with styled components. So, to be able to still, like, basically, you know, have a bunch of styled components set up, but have these CSS variables at some top level that easily control things, without having to have a bunch of JavaScript variables that are passing around. The nice thing about CSS variables, if you didn't know, is that they cascade, which is great.

We're using Emotion. We're not using styled components. As far as I can tell they're more or less the same thing these days. Maybe there's some subtle differences that I don't know about. At the time when we chose to use Emotion, two years ago, styled components were not as performant. That's kind of why we ended up with Emotion. I think Kent Dodds, the author of React Testing Library and a number of other things also had this tweet. I found this when I was trying to validate our reasoning for using Emotion. Other important people say it's good. Yeah. We use React Router. This is kind of like a little tip I wanted to point here. This is a very kind of classical tip, don't fix what's not broken. We're still on the third version of React Router. If you're familiar with React Router, you probably know it has undergone a bit of churn in terms of structure and how to use it. With React Router 3, you would put all of your routes in one place. With React Router 4, you put your routes into your components, and then other components that are rendered have their routes inside of them. It's kind of like this... You put your routes kind of everywhere in your app. We certainly considered migrating over to React Router 4, but we kind of determined that it would be harder to maintain, probably harder to navigate, and a lot of this kind of came from our own experience using React Router 4 for side projects or other projects. And I think what's almost maybe kind of funny to point out here is that, because we've waited so long to migrate, and because we made this consistent decision not to change anything, because it works fine, it works great for us, I think maybe the biggest problem might be that our routes file is like 2000 lines long. Though I did recently reorganize this, so it's quite a bit easier to navigate. This is where all of our routes are is in routes.tsx which is really nice when you're an engineer coming in and you're saying oh, I need to figure out what is rendering this page to be able to just come in here and say where is the discover stuff. Here's the discover routes right here and then you can easily navigate to the thing, oh, here's the landing. You'd have to traverse through a tree of like okay, where does the organization tree, where does the discover tree render, where's the landing. What I was going to say is because we've waited so long React 6 is going to be coming out pretty soon and they've actually returned to the all routes in one place kind of structure of creating your routing setup. Because we managed to wait so long, hopefully, we can migrate from 3 to 6. And we'll probably have to fix a bunch of like types. I think we use the with router stuff heavily and I think there's no longer an HOC. It's only hooks, which is something else that we're kind of moving towards. Yeah. A few other kind of like little things here. I'll talk about the bottom one first is we just use fetch these days, so this is actually kind of recent but we killed off jQuery's AJAX along with maybe like three or four other usages of jQuery that we still sort of had floating around. I think I introduced like a old jQuery compatibility thing where I just reimplemented.

It was like two things that we were using jQuery for and they were really simple but I don't remember what they were. But that works great, I highly recommend it. You honestly almost don't need other fetching libraries other than fetch, as far as I can tell from our usage.

The other thing that we use is reflux, which is a very old flux state management library. It's not redux, don't get confused with that. A lot of people do tend to get confused with that, but we use that as our global state management. And when I say global state management, I mean like asynchronous states, or like server states, like when, for example, if you have two components on the same page, and they're both, you know, fetching the same thing, you want to use some kind of global state thing so that you can de-duplicate those requests. We use it for that. We're looking to replace it with something else, something, for example, like React, ReactQuery, which kind of does that, but is newer. So the fact that it's kind of older kind of inherently has some problems. A lot of it has to do with, like, testing. So it's actually kind of hard to use reflux with, like, things like React testing library when you're using functional components. Mostly because it happens all outside of the React rendering cycles. So like, you know, reflux, it's basically, like, I said, it's like the flux thing. So you have a store and then you can listen to that store and then you can have, like, actions that cause updates, and then all the subscribers will, you know, that are listening will re-render, or, well, they won't re-render. They will be notified and you have to implement the re-rendering logic yourself. Which is sort of what we've done. In fact, I think we recently managed to turn it into, like, a pretty simple hook, kind of recently. So you can pass in one of these stores into this hook. And because of how nice hooks have been, you can simply listen to the store and have it basically set state. But the annoying thing here is because this happens outside of React's lifecycle, you have to make sure when you're running tests that you're telling React that you're acting when you update your store. Otherwise the set state will happen without any sort of act. And it will get confused, or really, it will yell at you. I'm sure we've all seen the missing act warnings. Or maybe you haven't, if you're just using a bunch of newer stuff that handles all that for you. But yeah, this is something we're trying to get rid of. We also use it for global state for things like, I don't know, we have a sidebar that you can open and close. It probably shouldn't be used for that. Something like React Contacts would probably make a lot more sense. Yeah, and obviously we use Sentry. Hopefully, at this point in the talk, you know what that is. David gave a really great demo earlier. But it works really well to be able to, you know, see if we've broken anything. Yeah.

I'll pause you right here. We got a question from the Discord. We got M. Hayes. He asks, for your reps. Do you have any kind of helpers for generating URLs within your components? We don't actually. That's a good question. That was actually something that I thought about when I joined. I was like, hey, why don't we have this? And I actually thought it was going to be kind of like a problem. Because we do it on the backend. We use Django. So we have all the Django helper stuff for generating routes based on route names. So we don't do anything on the frontend. I think it hasn't been a problem for us, honestly. Because... Well, we haven't moved routes around quite at all.

If we do move routes around, we're pretty careful to make sure we have redirects. We haven't run into that scenario, where we need to migrate where a route lives, and it's frustrating to go back through the app and try to find all the hard-coded paths. Which is what we do. We do more or less just hard-code the paths. But it hasn't really been a problem, I guess. I think it's been okay for now. Yeah. Perhaps in the future. Something to revisit. Yeah, we definitely have a number of kind of like... Where are they? The legacy redirects routes. So we have this whole route tree of just things that are redirecting to other paths, that are just because we move things around. But I don't think... I mean, when we change stuff in code, usually it's not... We don't use these redirects anymore. I think this is typically for people who have bookmarks. Yeah. So I think we're pretty good about refactoring. So everything uses the new routes. So yeah, this is what we've been doing. Yeah, that's a good question though, thank you.

Cool, okay, let's keep going. So we kind of talked about kind of what we use to build Sentry, like, some of the tooling. I did want to talk about kind of a few things that we particularly like at Sentry, in terms of just like... You know, being a front end engineer, and like thinking about how do we... How can we scale front end engineering at Sentry, how can we make sure that as we've grown as an organization, how do we, you know, keep being productive. So I mentioned earlier that we really like TypeScript. I personally also really like TypeScript. If you read my likes earlier, I think the first thing I wrote was TypeScript. I'm a big convert. You know, before we migrated over, I hadn't actually used TypeScript, and we started using it, and I'm like, seems like so much work, but at this point in my life, my development career, I don't know, I feel like I'm just like writing TypeScript all the time. Older and wiser. No, so, let's see, yeah, I don't know, why do we love TypeScript so much? So TypeScript is really valuable for when you have, it's very valuable for when you have like a larger app, right? And, you know, Sentry, obviously it's like, you know, we've grown our code base quite a bit, but it's like, not only have we grown like how much code we're writing, but you know, we have more and more people writing code, right? And I mentioned earlier, like, you know, people are specializing more in like front end and, you know, the teams are kind of like doing specific things. And so maintainability becomes like a very, very real kind of priority. And so the idea that we can use something like TypeScript to have like static checking and to be able to basically eliminate whole classes of bugs, you know, no more, you know, objects does not have a property on undefined or whatever type things, it's really, really valuable and it's very much true that we have eliminated those bugs, like, you know, obviously And so it was very easy to see like, the kinds of bugs were introducing before, versus the kinds of bugs we introduce now. Where, honestly, it's, you know, we don't have too many front end bugs these days. I think we used to, we used to have things like that, where it would be like, weird object types floating around and stuff like that. But ever kind of, since we had kind of completed our migration or TypeScript, where things are correctly typed, just like, 100% of the time, it's, it's kind of eliminate all that stuff. But the other part of it is kind of like, the kind of very appealing part of TypeScript is that not only does it kind of stop you from writing code that is buggy, but you also can end up being like, more productive. And especially, you know, like making, it's really important to, you know, make new contributors productive quickly. So, yeah. So it's more than just like a correctness checking thing, right? It's more than just, just like, oh, like, we know that the code is not going to break type thing. It's also that, like, TypeScript offers these really, really great features that you almost might not even think about if you're just like, you know, in VSCode all day and already using it. But things like, you know, for example, like near always correct auto imports where we'll almost always know how to auto import like something that you need. Right? So if I'm just like floating over here in some file and it's like, I need, this thing and we'll see if my LSP works here or not. Yes. There we go. So it's like, if I needed to use projects, right? I can click this hit enter and it correctly imports it. Right. So before we use TypeScript.

I remember I specifically had like editor plugins for auto importing JavaScript modules like because I was just tired of like having to be like, Oh, I need 90 views projects like let me come up here and pour and use. And right. Like I just, I didn't want to do that anymore. And I think VSCode if you're using JavaScript kind of does something similar. But I think at this point it actually might just run the TypeScript server for you, even though you don't have like type annotation, it would be mostly correct. But yeah, I remember using plugins that that were like specifically around, like auto-importing based on like heuristics of like matching the file name to like what you're importing. And like, it kind of worked, but it just wasn't very good. So things like that, I think one of the kind of like biggest, like productivity, like advantages of TypeScript is how easy it is to navigate.

So to be able to like do go-to definition to be able to find all references of a user of a used like export. Right. And like all these things are like really, really incredibly valuable and like things that like very much you take kind of like grant for it to be able to just jump around code really fast and like do that correctly. Right. Like to be able to just be in here and be like there's nothing to understand here, but like, Oh, like, where's this common store interface thing used? And it's like, Oh, here, here's the definition for it. Right. And then to be able to say like, Oh, well what's, what's using it. Right. And to be able to just like hit a keyboard, like keyboard shortcut and see like, oh, here's all of the, all of the the usage of this common store interface. This is related to our reflex thing. This is like how how this hook has like its own interface for using, using, using the stores. Yeah. I don't know. So that's, that's like a very, very valuable thing that like, I think that people kind of like almost take for granted. The other thing that I wanted to mention this way I put it in bold here is that it makes refactoring things really, really safe.

I think David kind of as an example a little bit later here about just how you can be sure that if, if you are changing something that you've changed it all everywhere. Right? Like, you know the way that question is going to go about the URLs and it's like I almost actually kind of wish that we had type-checking on our on the URLs. Right? Like to be able to like, say, like if you've changed your URL, then it's no longer valid in these places. Right? Like that's basically what TypeScript does for you. And then, again, like object types are changing, you know, removing properties, you can immediately know that like, you're, you're not using it somewhere that you didn't expect, which without TypeScript you honestly don't know. You have to like, kind of like search through the code and especially with languages like JavaScript where it's dynamic, it's not uncommon to, you know, like have weird indirection where you're like doing it some other way. So like, you know, just searching through the code base might not work. Yeah. I want to briefly mention too. The this is kind of like a sort of behind the scenes thing, but this is also like something that I put like in my likes, but the thing that powers editors is language server protocol. I think it's also built by Microsoft. It's really, really cool because, you know, TypeScript, basically what you do is TypeScript has this little language server thing that runs and it implements this protocol and then all these editors, all they have to do is implement this protocol and they get all that kind of like semantic, you know, navigation, semantic importing, all that stuff for free, which is in this case, why I'm over here running NeoVim. I think a number of people at Century or are in NeoVim land, like three or four people, most of you, I would definitely say are over in VS Code land. Yeah, like me. Yeah. But but it's really nice that you can just install a plugin here and then get, you know, correct, correct, like semantic stuff like in your editor and be able to like type stuff on NeoVim and have it all complete. Kind of neat.

Do you have a question, David? Yeah, I saw some steps falling on the screen there. We do, we do. We have M. Hayes back at it. He's saying, do you use TypeScript to check your API requests and responses? That's another great question. Oh man, him as with the hard ones. I actually wish I could say yes to that. This is something that we were kind of like talking about and it's sort of maybe like up in discussion a little bit. But no, we don't yet. We do in some places, but we don't do it in a sort of like automated way.

Like I said, we don't use GraphQL or anything like that where a lot of times it will auto generate all that stuff. We are kind of still just in kind of the old school rec style APIs. We do type them sometimes where we'll type the responses. That said, obviously it'd be very easy for those to go out of sync. Yeah. It's definitely a topic that we've talked about, but we haven't particularly taken any action on it quite yet. We would definitely like to. If you have the opportunity to do that, if you're starting fresh on a new project and it's a project that you anticipate becoming a little bit larger, do you think it would be worth it? I think TypeScript is worth it on any project, even if it's small. I mentioned it's really valuable in Sendry cause we're big, but I use it on all my side brushes now. Same here. Yeah. No, that's a good question though. Yeah. Thank you.

One other thing I want to talk about here, and I'm going to kind of start moving a little faster because I realize we're taking longer than expected to talk here. One cool thing that we built kind of recently is Deploy Previews. This is kind of another valuable thing, I think, for the frontend developer experience. I think we built this during hack week, maybe twoish years ago. Time's unclear now because of COVID. But the idea of this is, you know, we kind of found that people would go and build code or go and build features in the frontend. A lot of times, you have to pull those things down from a branch and verify them locally, set up test data locally. And so it was actually me and a couple of other people worked on this project for hack week, where it's like, hey, can we just like... You know, we almost have a frontend SBA here, or a single page app. We almost have this just JavaScript thing that talks to a backend API. Can we just rip out a bunch of the tendrils that are touching Django code and make it so that it runs on its own? With obviously the advantages of being, you know, if we automatically deploy pull requests to some, you know, server somewhere, then you can easily verify things, right? I'd put a little note here. It's actually, I realized this kind of recently, but it's actually especially useful for things like the Panda bot automatic PRs. So if you configure Panda bot to just open PRs every time like packages update, it's actually really nice to be able to just like let that happen and then see like, oh, it updated, it updated. I don't know, like the react, like tool tip library or whatever that we're using. And then, you know, you can just click it and make sure like all the tool tips to look right and make sure all the tests are passing and then feel pretty confident that that upgrade it's probably okay.

Yeah, how do we build this? So this, this did require quite a bit of untangling in terms of like the the way that like the the back end rendered HTML would like boot the react app. Yeah, so kind of like like I mentioned, like at the time, we're still kind of coupled to dingo. So we had to introduce a few new APIs, things for like, like really early boot configuration. So think things like locale or like user details, or even like the sentry configuration for, you know, the sentry DSN that needs to know to send errors to, we had to add authentication pages, like I mentioned, our authentication pages are still in kind of like Django land. Our authentication pages are actually quite complicated. This is a number of different ways that you can authenticate. So we built those just for just for the play previews. And they're like, kind of dumb and basic. But then, yeah, so Webpack learns to produce HTML, you can tell Webpack to build, build this kind of like, you know, single page mode version of the app, and it will produce an HTML file that has, you know, all the JavaScript and then kind of like a little bit of the secret magic sauce is, you know, where can we put this stuff? So that's easy. So we did this during a hack week, and we wanted somewhere that this stuff could live where we didn't have to do a bunch of like, you know, like, a deploy server and then have to set up an automatic subdomain and then it has to, you know, connect over to the century API somehow. We found Vercel to be really, really nice for this. So it kind of handles all that magic, where, you know, it automatically will, you know, CPRs, automatically deploy them, automatically put them in a subdomain, you know, automatically build all the Webpack stuff. And that actually kind of just works for it. It's like that was actually kind of a big unknown when I when I had started that project and it just worked, which is great. But it's nice to have like, you know, real, real data that you can test again. So it talks to the production API. So basically what it does, it will proxy through the the Vercel page that it's on and then it will talk to the real century API. And the other nice thing that it gives us is I think it has some nice like permission controls so that outside contributors can't like make a PR with some malicious thing and then, you know, send people links to these to these pages that sort of look like century. That's nice. That's nice. Developer previews are really cool and really useful, I think. One of the things we thought about I think not too long after we built this is like, hey, like, can we do more with that? Like we did this, you know, we basically separated sentry out. So it's kind of like a full, you know, SBA over here and then backend thing over here for the most part. So we thought like, hey, can we actually do this where you can only run the front end locally then? So the question was, you know, can we just do what we did with pull request previews and just do that in the development environment, right? Like why have to wait for Docker to boot all this backend stuff and you can just have your local development environment just talk to the production API? So the answer obviously is yes, yes, you can't do that. And so we introduced this WI command, which I've actually used quite a bit since I've mostly just been doing front end these days, and I think a lot of people use quite a bit. And it's really nice because it it boots fast. You don't have to wait for bunch of Docker stuff to run. Your machines are running less things, which is nice, especially in a scenario where, you know, you have a TypeScript compiler that has to keep a bunch of stuff in memory. And it can be really nice to use the Brechtian API locally to test things where it's already have real data. So, yeah, that was one of the kind of kind of thing that we had built locally or built kind of like for our development tooling that we really, really liked. Yeah. So I think from here, I'm going to hand it over to David. He's got some kind of like war stories to tell. Before that, we actually have one question from Reema. How many hacks week we have like in the duration? I guess like how frequently we have it. So I just say it's once a year and it's one week, typically in the fall. And yeah, hopefully that answers the question. Yeah. Once once a year it's it's a lot of a lot of cool stuff gets built. We think we built that. Another one of the years we I didn't talk about this. I want to talk about this. But we built a whole kind of visual snapshotting tool. So we generate screenshots and automatically compares them on Polar Quest. It's kind of similar what Percy does. But our own version. But our own version. Yeah.

But our own version. Yeah. Yeah. We build a lot of cool things. But back to this story time. So this is how we use Century for Century and basically describing how we've been able to get some performance wins and how we use Century Performance products specifically.

So in order to understand the context here, I'm going to flashback to 2019. This is, you know, when the app basically had a couple of performance issues that we're going to talk about, and one of them is caused because on App Startup, the organization details is fed and this is all happening in one end point.

So the organization details is composed of a couple of different pieces of information. So we have the organization information that's like the slug, the avatar and the plan, maybe some features that you had for like early access organization that you can turn on. And then we also have set of all your teams in the organization and the set of all your projects and the organization. And that is stored as, you know, normalized field within this organization object. So it's organization.teams and organization.projects and this stored, this is stored in reflux. Like Evan talked about, we have reflux. So it's not the greatest right now, but we have this to store API data since typically you don't want to be fetching this multiple times. It's a rather heavy payload. So we don't touch it multiple times. And the way it's accessed as we store it in this store and then downstream components will go ahead and directly access teams and projects from the organization, you know, so now bigger and bigger customers started using Century in 2019. And obviously at any company you'll start to get bigger and bigger customers. And we started to see that the organization details endpoint is becoming very expensive.

So expensive. In fact that some customers are subjected to 50 seconds a little time, which is a lot. It's like really a lot. And this is nowhere near acceptable. I feel like typically they would just see this loading spinner for 15 whole seconds. So obviously this is huge problem. It's not so bad. Like it's not every single customer, but it is a select few larger customers that obviously would care a lot about. So this is something that we definitely need to get to the root of and how did exactly did we do that? So, as I mentioned before, we have our own performance and distributed tracing product, and it collects a variety of metrics like throughput latency and transaction duration, which is something we'll be looking at today, which is how long a transaction takes maybe like an end point or like a page load transaction. And then we've also recently introduced web vitals like you saw. So LCP, FCP, which are also pretty related to this case because ultimately we're trying to reduce those numbers as well. So let's go ahead and click in the century and this is some screenshots of actual data that we have. I blurred out the customer name. So that's why you see like a little bit of white out here. It's not like a visual glitch. So we have a page load transaction, and this is specifically for like any page load that we have. This, I think this is for the issues page though, this is the most typical page load, and you can immediately see a very long bar.

This is the span view. So this is showing kind of the operations that take place in the front end. And all of these are like HTTP get requests or like, you know, rendering something or getting, you know, a script. You can see we have a seven seconds end point. So it's not as bad as I talked about, but there are some very bad cases. This is probably not the worst seven seconds, just loading this, having this loading indicator and loading this end point, get API site zero slash organizations, right. And this is the specific organization that they're requesting details from. So because this is distributed tracing, we can connect the front end to the backend so we can click into this and see that the backend transaction and Django looks a little different. And we're gonna open that up right now. And we have basically the culprit right here, right? So we click into the backend transaction and we see that part of the reason why it takes seven seconds is because most of it is constituted by the 6.6 seconds project summary serializer operation. So as you heard before in this organization end points we basically have all the teams and all the projects. And for this specific organization, they have a lot of projects. So serializing all of them and sending that over the network is going to be very, very costly.

So sweet. We've kind of found out that this project summary serializer is a huge bottleneck performance. So what is the solution here? We're going to go ahead and try to split the organization details and point into multiple parts. And even though we're doing the same amount of work, the important thing to note here is that in the previous, I guess, so we saw that the whole application was blocking on that one, really heavy end point. But if we split it up into multiple pieces, we can block on just the one lightweight organization details, which only composed of like strings and numbers and ideas. So it's super lightweight, as the name implies, and then the all projects and all teams API call. It can still happen in the background, but it shouldn't be blocking any of the app from loading, right. We want to render as much as we can with as little information as possible to make it feel, you know, a snappy as you can. I think the thing is also that Century, like a lot of the views don't actually require all projects and all teams to render, which is something that we're currently tackling. We're going to talk more about later, but we really don't need all this information just to load, you know, simple issues page. Right.

So in order to do this migration, took quite a bit of work. So you have this incremental migration in place. We have tons of files that use the organization of projects and organization teams directly. So first we have to separate those two constructs into their own stores, right? We have to fetch them separately. And then we have to ensure before we can migrate these views to use this new pattern, it has to use these new stores and they have to be eligible for migration. And this is something that TypeScript made a lot easier. But this migration is also happening in the midst of the TypeScript migration. So this did end up taking like a year long.

And especially because we didn't have TypeScript for some of these verifications, but the way this works is we had two routing trees. We had a lightweight and a heavyweight routing tree, and I'll go ahead and switch over to an actual pull request that this one that I did a while ago. And you can see that we have this lightweight organization details. So this was the very introduction of this lightweight pattern where we had a component that was responsible for fetching this lightweight organization, all projects and all teams, and then put those all into the stores so that components could actually interact with them, right? So that's just the history right there. It's really real. We had this lightweight and heavyweight thing. And so after we were able to get some of those high traffic views in, we started seeing performance gains.

So again, this is another example, obviously really bad 13 second, load time. You can see we have the same thing over here, the same get requests and it's pushing all these spans over to the right, right? Nothing else can happen until this huge endpoint is done loading. So this is super bad. And then we have the new world where the equivalent request is quite a bit faster. So it goes from 13,000 milliseconds to 281 milliseconds and you can see everything else is not blocked anymore. Though you will notice that there are some very bad examples of these called to all projects and all teams. These two long bars are those endpoints. Obviously not great that we have those. But it's unfortunate for now, but at least you can see that the app is able to render, which is a huge improvement. And then what did we do after we performed like some of these migrations? Well, we need to continue the process, right? So we got this initial gains, but we need to migrate everything over into the lightweight organization. And during this cleanup phase, I feel like this is kind of like a two phase thing. We no longer had to maintain this construct of heavyweight and lightweight, which was really nice. Obviously having this in, you know, the code is not the clearest because engineers would come on and be like, why are there two versions of this organization? I didn't even know what lightweight was like. You did it. And I was just like, why don't we have two organizations now? Yeah, there's definitely the issue of education. I remember people would ping me like they'd get blame. And they'd see this lightweight thing. They're like, what the heck is going on here? Which one do I use? So having that in for a year, not the greatest, but we're super glad to be able to get rid of it. And Evan can talk more about how he's TypeScript there if you have any questions, but yeah, we use TypeScript. We got rid of all these organization dot projects, organization dot teams. And now we're focused on even further composition or further decomposition. Really. You're probably thinking why the heck are you even fetching all projects and all teams is probably not necessary to a super big organization. And you're exactly correct. We definitely shouldn't be doing that. So we're trying to even move away from that. A lot of the time we have these components that just get the user teams, for example, or just get the users projects, but they ended up filtering that from the side of all projects. So this is not that efficient. So what are some of the tools that we can use to make this a little bit nicer? And this is where we introduced the idea of hooks more readily in our application. So we have a really old react code base, right? So a lot of our components are in the old style, like just class components. We even had like three react class that we recently got rid of. So super old stuff. How can we even make use of this hooks, which can only be used in functional components? Well, we have some examples here. So I'm going to fire up my editor real quick in this VS code. Um, you can see, we have this use teams hook, and this is right here, and it's supports a number of options, which is, you know, a limit for the number of teams that you want to paginate to maybe specific slugs that you want and whether or not you just want the user teams. And this is where we abstract away all the fetching and interaction with the store. They scroll through. This is a bunch of code for interrupting with a store and providing the right stuff. And how do we end up using this in a class component? Well, we have this kind of thing, this render props, teams utility, and it really has no logic within it, which I think is really nice. So we have all the logic separated into the stuff. All it does is it just forwards whatever you get from use teams or a hook and it gives it to the children as an argument. And so this is a way that you can use it as a render prop style, which is a little bit older. Obviously if you can just use hooks, it's great if you're using a new project.

But I thought this was a cool way that we were able to kind of integrate hooks slowly and have this new path forward. So we're kind of on a, you know, like a more modern path and we can still have all the old class components using our new logic. And of course there's stuff that we've already highlighted before, like use legacy store, which has been super helpful and kind of abstracting away all the reflux stuff. So eventually when we make the switch over, it is not as jarring, right? We can kind of put this all onto a little box and you know, abstract away the logic.

So yeah, that's what's going on there. And of course tools that made it easier. TypeScript, that's a given. And following up with the actual, you know, some more performance gains, more taps, pats on the back. We have recently migrated over the settings view from the heavyweight to the lightweight organization. And this was kind of the last step. This is not a very heavily trafficked view. Not a lot of people are like going into this page from the start. So we kind of de-prioritize this to the very end, but as you can see, we're able to get 61% speed improvement is using the performance trends feature, which takes a time period, splits it in half, looks at the before and after does some statistical methods and basically tells you whether or not there's a real trend here. And as you can see there is a pretty clear trend for faster load times. And it's pretty cool too, cause this is like, we didn't have to like go in specifically look for this. This just was one of those things where we did it and then we looked at the performances trends page and it was just there and it was like, Oh look, there's that thing we did. Right. Yeah, it's actually pretty, I was, I was like it was one of those moments where I was like, man, our product's really good. Oh yeah. You know, it's, it's quite useful, I'd say. Definitely be able to go in here and just view at a glance what's changing is very nice. So yeah. That's how we do performance here at Century. I think bring it all together. I'll just talk about one last thing. So I mentioned at the very start that we're two engineers on, you know, a team of maybe like what? 80 engineers total. And we're not the only people who interact with the front end obviously. So how do we actually go in and do all these changes that are kind of like wide sweeping, cross team, cross organization we have something called the front end TSC. And what does that even stand for? Well TSC stands for technical steering committee. And it's a bi-weekly meeting that anyone can join if they're interested in kind of influencing the direction of the front end code base. So if you have opinions, you can come here and talk all about them. You can just represent your product team and you can talk about the specific issues that you've been facing and then propose debate and approve initiatives. And it just ensures that we're building Century and basically, you know, in a cohesive manner, right. We have, we're we have some harmony here in the front end and we don't have like really clashing patterns everywhere. And this is actually the birthplace of multiple initiatives, right? So we have the TypeScript thing. This migration was something that we gathered all the TSC individuals and we really had like some good spirit about it. We're all participating in this. People didn't want to do that for us. I was like one of the people I was like, Yeah, we don't know if we really need that. Right. It was like, Oh, we use it in the SDK cause those are like consumer things. But and then I don't remember, I think someone did it. I think like TypeScript literally came out as a hackery project and then like someone just started doing it. And then like they, then they came back to the TSC and they were like, Hey, look, we converted this whole like party app over. I think it was like the initial version of discover. Yeah. They can, they can bring that all the way over to like TypeScript. And then like they came back to the TSC and they're like, all right guys, check this out kind of thing. Right. Yeah.

And I think that's how a lot of it goes at the TSC. We kind of have these initiatives. I feel like, Evan, you're hearing someone who's like, Oh, I got to see it to believe it. But we'll end up doing things that we're like, you know, have a floor quest up that's like, this is how good it could look, you know? And that's how things like react testing library got in, hooks was also something that we talked about in the TSC. We removed a lot of old code as well. We have initiatives for that. So removing rack bootstrap, that's out of their reflex box. We're done with that. And then the ESLint rules many are born and they also die here. And many, many more. We have a whole like notion board. That's what we use internally. They can see the whole list of everything that we've approved, rejected. It's not really the whole list cause you can scroll and there's like tons more. But you know, this is everything that we're working on here.

Yeah. Yeah, no, the front end TSC has definitely been like super valuable. I think I remember, I remember like when we just started the TSC, I think it was, so when did we do this? It was like, maybe three and a half years ago. It was pretty early on in my tenure here that we like formed the TSC. I remember like one of the first ESLint rules that we added was just like always use const or it was like use const over let kind of thing. Where it's like only use let if you have to. And even that I remember people were like, Oh, it's like another extra character. But then it was once you managed to get the ESLint rule and everyone just stops complaining, it's the same thing with like Prettier where it's like, as long as everything's consistent, like no one's gonna complain kind of thing. So it's actually been really nice to have a formal working group for that, where we meet and talk about it. Sometimes it really does get into the nitty-gritty details of like, um, you know what, I don't, I don't know. Like we've talked about color is pretty in-depth there too. There's a lot of things, very small decisions that take up a lot of time, but I think they're super useful and I, I think we both recommend having this kind of meeting, you know, at any organization that has like a, you know, a growing code base like this.

Yeah. So, you know, I had to bring it back to the people here right at the end. Of course, yeah. Thank you to all the people. Yeah. And I think, I think that's pretty much it, what we had in this talk when we were putting this together. We kind of, you might, you might notice that kind of intro was like, are we going to talk about like so much code stuff? And then we realized, Oh God, we only have an hour here, so we kind of reduced it down to just like, you know, kind of how we, how we build things. And, you know, here's kind of a pretty interesting story. But yeah, if anyone had any more questions or wanted to ask the same thing, we're, I think we're here for another five minutes and we can certainly, you know, talk about stuff, you know, feel free to type things into discord and we can answer them. Yeah. We can unmute on zoom. Yeah. Maybe, maybe. I don't know. I don't know if that's like allowed or not. You're brave enough, right? I don't know. Otherwise we'll just like, you know, hang out here and talk, talk more about, I don't know. What are, what are some, someone's typing something. No, let's see. We got no pressure, no pressure. Yeah. Yeah. Thanks so much for coming to the talk.

Hopefully you learned something about how we do coding here and maybe took away some, some good lessons, right? We don't do everything perfectly, but we're always trying to evolve and maintain things properly. Definitely like, you know, being proactive about about maintainability has been like super valuable here. Like I've certainly seen places before where maintainability becomes more of like a reactive thing where things just start to become like really hard to like to.

Oh yeah, I guess people are, oh shoot. Did we miss things in the zoom chat? Should we open that up? I don't know if we don't open that zoom chat up. Let's answer these 40 questions okay. Other plans to include local variables in the stack trace and jobs for SDK. That's a good question. I don't know the answer. So unfortunately neither me nor David worked too closely with the, with the SDK teams. I would recommend hopping in the, there's a century discord where a lot of our SDK engineers hang out and kind of like talking about all that kind of stuff. I actually don't know why we don't have local variables. It actually honestly might be a limitation of the kind of like JavaScript runtime. So it actually might be really difficult to capture that stuff. The I know the Python, the Python SDK does it pretty well, which has always been really nice. Yeah. What's the question we got here? What client library do you use? Are you moving to, are you talking about state management? Yeah. Same. Are you talking about state management? Are you talking specifically more about things like like react query? Rusky. Ruskies. We'll get the reply to that. Yeah. We'll get the reply to that and we'll answer another one here. Any difficulty testing hooks with react testing library. So we, we kind of recently have started like introducing hooks and using hooks. So I think over the last, like maybe like five, six months now, we've been kind of introducing hooks into our code base. I think I introduced the react hook testing library, which is a part of the react testing library. And I've really, really liked it. Actually, I think it makes it really easy to test hooks. Whereas like kind of before, when we had anything that we've been sort of like hooks where it'd be things like HRCs, you always had to like, set up mock components and stuff like that. I haven't had any, I haven't had too much difficulty setting like testing books. The thing that has been annoying actually is like testing components that are using books, I guess. So testing components that, that, that use hooks, it's kind of like well, a lot of it, like I said, kind of has to do with the fact that we're using these kind of older reflex stores, which don't integrate with like the react life cycles. So that's been annoying. Are you doing integration testing? Yes, we are. So we have, we have a whole suite of kind of integration tests that are run by Selenium on the, it's part of the back end code code-based tests, but basically it runs the whole application and then it does it. It does a number of things. So not only does it do like integration tests where it like, you know, clicks around and verifies things but it actually also takes screenshots. And I mentioned earlier that we have built out kind of our own visual regression testing thing where it did, it will compare the screenshots from the master branch to the screenshots from your branch. And you can actually see like visually if anything is different. It's really, really nice to be honest to be able to like, see like if you change some component, like if you change like a global component and that changes some styles somewhere, it might change somewhere weird. I think I mentioned like we use style components, so we don't have too much like, you know, CSS where you change one thing and then it changes like a hundred different things, which is kind of what the visual regression is test against. But yeah, we do have integration tests. We also, we also, I guess have some like kind of JavaScript integration tests where we test some components that use, you know, that are just using a whole bunch of components all together. Most of our JavaScript tests or unit tests, though, yeah, we have them for the larger components. Definitely. And then how do code reviews work for the front end? Also, what's the process for deploying friend code to production. So deploying questions. Actually pretty good when the kind of myths of changing that as well. Yeah.

But so how do front end code reviews where I don't know he wants, and you and you want to take this one day, I mean, front end code review. It's like it's, it's, it's, it's the same as any code review that we have. We just put up a pull request on GitHub and then we have, we actually have GitHub owners. So we have like the, basically whenever you do a pull request, which if you modify any files that are owned by another team, then it'll put them on as a reviewer. and then you just do the, I guess the review that way you just, get the comments and revise. and then for the front of production deploys, we actually have something we're recently trying to split up and deploys into the front and backend. So typically if you make friend and co-changes, you actually have to deploy both the front and the backend. but now we're changing it so that you only have to deploy the front end if it's just front end changes. And that makes it like a lot quicker. and that's something that that's the person who is responsible for a lot of like the visual snapshot and the preview builds is working on right now. And we have that, I think that we're internally testing it right now.

All right. I've opened up the zoom chat. I see that we've got a few questions over here. How do you measure page load consistently? It's from Giorgio. How do you measure a page load consistently with sentry in a single page app, IE making sure all the requests you consider to part of the page load or waiting for to be part of the page load or whatever. I can, I can take this. So I think this is a problem that I encountered when I was doing some of the performance work before. And this is something that you can manually instrument, which is something that I did initially. so you just manually instruments so you say, okay, once the application has reached this state, so once it's got a return from all these API endpoints and you know, it's rendered either in like the component did update or like something like that, that's like a bit older. But once you got all the information, you can put like a mark and connect that up with Sentry and you can do it that way. you can also just rely on like the Google web vitals, which I think is kind of what we're trying to lean towards. We're trying to make it more automated like that. So things like FCP and LCP, I don't know if you're familiar with those web vitals, but you can see the strategy that, you know, the browsers used to actually determine when that point has been reached. I think for LCP, which is largest contentful paint, typically it's correct for at least things that we're trying to measure. So it won't say that the loading spinner is like the largest content, full pain. It will usually say like the biggest block of text, which happens once you load the issues page and that kind of correlates strongly with user experience. So we try to lead more towards that because we think that's like kind of like the, like a semantic way to represent performance. I'm saying that once the largest thing has loaded, then consider it loaded and usually the largest thing is the actual thing that we want these just to see. Yeah, that's like kind of the way that we've tackled that. Yeah. And it is like a little bit. A lot of that kind of stuff happens over in the SDK. So yeah, definitely the FCP LCP stuff. Especially now it sounds like, I think, I don't remember when this happened or if it's, if it has already happened, but I think Google had, was changing their page rank algorithm where you'll get ranked lower if your LCP is, yeah. So that's part of the reason that this has become like kind of important, Yeah. If it actually takes a long time for your your large pain, I can't remember if it's LCP or FCP. It might be, it might be a combination of both. I can see that. Probably FCP actually, since you know, the first pane is probably the more important one.

Sure. Let's see, we got another question over here in the chat. Do you only use React with the client side or do you, do you only use React with client side rendering? Do you mix old templates with React? So yeah, so right now we do only use React on the client side. Like I said, we, we have kind of a Python Django back-end. There probably is actually, I can imagine there might be some like crazy like integration thing where you can like run node to like render you know, like render the server-side stuff through Django with like some node instance or something. I imagine that might be a thing. We don't do any sort of server-side rendering. It definitely does have performance benefits to do that. It certainly could make things a lot faster. That said, because of the fact that we're well the, you know, the tech sacks are two separate things. I think it would be probably a lot of work to integrate something like that. Yeah. I'd be right, honestly. I might be right. I don't know. Maybe, maybe, maybe it is kind of easy. Maybe chat knows but, but yeah, so right now it's, it's pretty much all just client-side. So kind of as I sort of implied where it's like we have this kind of front-end single page app and then we have our back-end thing do we mix kind of template abuse with React stuff? Mostly no. So the way that it works right now is that Django renders this, this I think the file is just called layout.html where it's like really pretty bare bone. It used to have a bit more stuff in it. It used to like render like things like alert bars at the top of the page. It doesn't do that anymore. That's all delegated to the front-end app now. But it is the thing that, that loads the, that loads the app and actually runs the app. I think we literally export like one or two things to the global window now. And I think one of them is like render app. Though even some of that might've changed kind of with some of this front-end deploy stuff that you mentioned that we're doing. But we don't, we don't mix things for the most part. There is, I think there's like maybe one or two places where we have, I think we have like that. There's one thing that I can think of where we have the registration page, which is the, this is, this is Sentry on-premise only by the way, the registration page for sentry.io is completely different because it's on the marketing website. But the registration page for the open source for this entry has a, it has a password strength indicator, which is a rack component that we export onto the window and then is rendered in that HTML view. So there is a little teeny bit of mixing like that, but it's you know, it's pretty self-contained.

Let's see. Got a few more questions over here. I'm like internet client libraries. What method and requirements were you considering to create it now? So internal client libraries. I guess I'm still not exactly sure what internal client libraries means. Can you clarify a little bit more Rusky?

See, we have a clarification. What version of my webpack are using? Oh, I see there is, there is a clarification. What libraries? Well, he's typing right now. Let's wait for it. We are, we are using webpack five. It was maybe a little bit of work to migrate over to it, but it wasn't too bad. We're one, the latest versions of most things. Yeah. We try to keep it latest except for select things like react router and reflux.

What is the UT template code? Maybe I'm still confused. I mean, someone said that, that, what client libraries would we use now? Like say, for example, like we talked about how reflux was bad. Oh, Oh, I see. I see what you're saying. Sorry. I think that's what, I mean, we could talk about that, you know, we can talk about that. I guess. Yeah. I mean, I feel like I can speak kind of just like to my own experience if, if we were to rebuild Sentry today, I guess it's, it was a little bit more difficult. I mean, I, I, I don't know if that's a bad thing, but I think it's, I mean, I rebuild Sentry today, I guess it's, it would certainly be kind of all of the sort of mindset. So, so one of the things I guess I can specifically talk about is like, you know, we want to get rid of this, this reflux old thing. We probably wouldn't use Redux. I, I, my, my personal feeling of, of Redux is that there's a lot of boilerplate code there. And it's kind of a little bit too much. We would probably use a good bit of React context I think. Though I think there's also maybe some performance implications of using too much React context. But one of the libraries I've been super interested in recently that I, that we've started to kind of like experiment with is React query, which is kind of like a asynchronous data fetching library, though it doesn't actually do any of the fetching. I think you probably just need to search for that. But it kind of handles the deduplication requests. It handles the caching, it handles reloading of data. There's a few more things, I actually don't know too, too much about it, but it looks very interesting to me. In terms of like other client libraries, I mean, I think like React's great, what other, what other stuff? I personally still like React Writer 3. I mean, I don't know, there's a whole bunch of cool stuff and we can even just like kind of look at our like package.js, we made it, we made a joke earlier how it's like, oh, we just walk through the whole package.js with everyone. You can just switch over to your. Oh, you're right, you're right, you're right. But there is, there is some, there is some kind of neat stuff in here that I think that we like, we have mobX in here. I think actually mobX is kind of like, it's a pretty nice like library for, for kind of reactive things. I've actually used it in some of my side projects and I quite like it, but I will say it's a little bit harder to document than it is something like Reflux, which I think, or Redux, sorry, which is, I think pretty good at document itself despite being like tons of boilerplate code. One of the other things in here that we use this kind of cool is like React Popper is a really cool library for doing like pop-over and things like that. I also really like React Select. That's a really nice library. We use e-charts for all of our chart visualizations. And I think, I think that's actually been impressively good considering how hard it is to do charts. Yeah, I think, pretty solid. Yeah. Oh no.

We're just like talking about, talking about cool libraries these days or now. Um, let's see, do we have any more questions over here? No. Yeah. I think we'll probably wrap it up. Um, I think we're yeah, a little, like 10 minutes over time here. Um, cool. Um, like I said, definitely hop in. There's a Sentry discord. Um, me and David are also in there. We can certainly answer more questions about front-end, how we build front-end. Sentry's totally open source. Go, you know, read the source code. Um, I've actually been adding quite a bit more like kind of comments recently to like, kind of big core pages. So like, for example, I added a, um, I added this whole big comment to the app index file, which explains just how the app even boots. Um, even though like literally this is like all it does. Um, but this is actually kind of nice if you're just like, if you're just like looking at Sentry code or like browsing through it, this is kind of like a nice introduction to just the way it works. Um, and yeah, same thing with like the routes file, I added like a whole Comment in here about like how the routes file is structured. This is kind of like another pro tip is like, you know, add lots of like, kind of read me documentation and deer and your code because it's really, you know, people will read that stuff sometimes not, but a lot of times they will, and we got some props. Thank you. Alicia. Bye. API. Cool. All right. Um, thanks everyone for joining. We really appreciate it.