Jed Bartausky:

Welcome back to another episode of the React Native Radio Podcast, not brought to you by Mazen. He's gone at React native universe giving a talk if you want to watch it. Details are in the show notes. Episode 306, react native plus Century, A match made in heaven with Christophe Woolrich.

Robin Heinze:

Welcome back to React Native Radio. I'm Robin Hines, I'm your host for today All Alone. I have no mazen and no jamon, but I do have a lovely guest. I'm joined today by Christophe Wildrick, who I will introduce in just a second. But you know me. I'm Robin Heinz, I'm the director of engineering at Infinite Red and I live west of Portland, Oregon with my husband and my two kids, and I've been doing React Native since 2017, so what's that, seven years. But yes, I'm joined by my lovely guest Christophe, who works for Century on the mobile team. He's focusing on primarily the React native SDK, and he's joining us from Vienna, Austria. Welcome Christophe. Thanks for joining us.

Krystof Woldrich:

Thank you. Happy to be here.

Robin Heinze:

We are going to be talking about Century and React Native, but before we get into it, I do have to mention our lovely sponsor, infinite Red Infinite Red's, a Premier React native consultancy located fully remote in the us. We're a team of 30 plus senior level React native developers and support staff and have been doing this for nearly a decade. If you're looking for React native expertise for your next project, hit us up at Infinite Red slash React native. And don't forget to mention that you heard about us through the React Native Radio podcast. Alright, let's talk about Century or as the title of the episode says React native plus Century, A match Made in heaven. Let's start with a bit of background about you Christophe, and how you ended up at Sentry and how you ended up in React native in general.

Krystof Woldrich:

When I was preparing for this episode, I looked up when was the first app, first React native app. I did and funny enough, it was year shorter than you. It was only six years ago and

Robin Heinze:

Yes, I win.

Krystof Woldrich:

Yes, yes, you win. And do you remember what version of React native would that be? Because I was thinking that's funny thing to look up. How

Robin Heinze:

Far back is it? I'm pretty sure the first version I coded on was like 39, 40, somewhere around there.

Krystof Woldrich:

Wow, that's so far. Now we are at zero 70 and my first version was 0 55 and Expo 27. It's like, wow, I wouldn't want to upgrade that to the current version now.

Robin Heinze:

Oh my gosh, no. Yeah, I think when I started Expo didn't exist or if it did exist, it was still called Exponent, so it's been a while.

Krystof Woldrich:

Yeah, but bit about me, I'm about two years at Century. Before that I was still working on multi-platform SDKs, but it wasn't React native specific, it was a JavaScript SDK for smart TVs. And before that I just finished university in Czech Republic where I come from and I moved fourth century to Vienna, Austria.

Robin Heinze:

Oh, cool. So you've worked primarily on SDKs. Would you say you've done more work on SDKs than you have on production apps?

Krystof Woldrich:

Yes, that's actually true, I would say unusual or interesting part, but the SD case took me quite early in my career. I would still consider myself being early in my days, but yes, I went straight to SDK almost from day one if I don't count side jobs and things during university, but after it. Yeah.

Robin Heinze:

Very cool. I also want you to tell the audience a little bit about what Sentry is if they're not familiar with Sentry and maybe what some of your favorite features are so that they can get an idea of what Sentry is.

Krystof Woldrich:

Yeah, so Sentry is errors and performance monitoring, but more importantly we focus on debug ability for developers being able to debug their apps. So monitoring and observability, all these fancy words are just the start. We want to provide you with the correct context and actionable data so you can actually go and fix the issue. Not only try and catch the error on the front end on the mobile app, preventing it from crashing, but showing a sad smiley. We want you to go all the way and fix the core of the issue, be it on the server or somewhere else in the app.

Robin Heinze:

I can tell you as an app developer, there's nothing worse than finding out that something is broken on production that's not broken in dev and you're like, what am I supposed to do now? And so having really good crash reporting and analytics is a lifesaver in those moments when the client is unhappy or the customer's unhappy and you just want to get it fixed

Krystof Woldrich:

In a way we brought you to said news that something went wrong, but it's

Robin Heinze:

No one wants to, no one wants to hear from Century, but you're always glad that sent exists.

Krystof Woldrich:

Yes, exactly. And we try to make it as enjoyable as possible and should be quick in and out like, okay, this is happening here, it's it's happening. This is how I fix it and I'm out and back to my work.

Robin Heinze:

So how much of the developer mindset are you thinking about when you're developing features for Century? Because obviously you know that you're going to be primary audience is developers who are stressed out. How do you plan that into your features?

Krystof Woldrich:

It's one of the first, if not the first thought. So we are always thinking about the person of developer and they are at Century or they're using Century because something's going up, something's wrong. We want to surface right away the most relevant information. It should be very simple both on the SDK side and in the ui, so we don't take assumption or try not to take assumption. It should be same for Novus or Experience Dev Now no one should get lost.

Robin Heinze:

I like that.

Krystof Woldrich:

That's the thought.

Robin Heinze:

I like that a lot. It's really easy. I mean I remember as a junior dev how lost I felt in logging into analytics services and you're like, I don't even know what I'm looking at. This is supposed to be helping me fix this problem, but I can't even find my way around the debugger. As a developer, we really appreciate the developer first user experience.

Krystof Woldrich:

Yes, I can feel with that as well when I was starting up. And it's also think, which we keep in mind when creating, for example, the Century Wizard, which supposed to take you through the journey of setting up the SDK all the way up to sending your first error. And so when you start the first error, it's not everything we can offer, but it's like a taste of it where, okay, I said the SDK correctly, and from there you can explore more and connect more services to your front and backend and enhance the experience.

Robin Heinze:

Awesome. So I mean as a developer who has used Sent, it always feels like Century is pretty invested in first class support for React native. I mean there are lots of services out there where you'll see React native listed in the platforms that they support and then you go to install their SDK and it's pretty obvious that it's kind of an afterthought. It's just maybe a convenience wrapper around their existing native SDKs, but they're not really React, native Focus and Century definitely feels like they put effort into knowing the React native ecosystem and community and building for them. How did that come to be? Was that always the case with Century or how did they come to have that sort of React native focus?

Krystof Woldrich:

So that definitely predates me. The origin of the SDK is far back. Oh, she took credit

Robin Heinze:

For it.

Krystof Woldrich:

Cannot do that. I'm sure my colleagues will listen to the podcast, although I would love to. No, but Reactive was always strong for Century as far as I can scroll. The graphs years back, I don't know really what made it so popular, but it always benefited from the strong JavaScript background from the browser and what we call JavaScript code that works also on Node. And as you mentioned that other solutions as well combine Native SDKs and the JavaScript SDKs. Well, our architecture is similar in that way. We also try to use as much of our native implementations to offload things from the JavaScript thread, but it never was just a simple wrapper. We implement features that are specific for React native, taking it in mind that the JavaScript thread is running asynchronously from the main rendering thread. And as you for sure things can happen where these things get out of sync or while better thing in a way they're never in sync. They are two separate things.

Robin Heinze:

Yeah, it seems like they behave as if they're in sync, but it's a facade. They're really kind of doing their own things that happen to be lining up

Krystof Woldrich:

When you start as a novice or when I started, I had no clue honestly that oh, there are multiple threads and what are they doing? I just took it as typical.

Robin Heinze:

Right. You're very insulated from it, just like putting views in texts and stuff on the screen. You don't really think about or need to think about what's happening in the background until something's going wrong.

Krystof Woldrich:

Yeah, exactly. I mean I cannot speak for the React native team, but in my opinion, and from how I understand it, that's the goal. You just go in there with your all web knowledge and you're able to create a super quickly, easily a mobile app. All these things about the threats and things, those are things that we as SDK developers are trying to solve. And when you're extending your application beyond what the JavaScript can offer to you, you get into that as well. But at that point it shouldn't feel scary anymore when you're that far with your app.

Robin Heinze:

It shouldn't feel scary. It might still, it's okay. So with Sentry being pretty focused on React Native, I'm guessing you probably have a close collaboration with the React Native Core team on certain things. Can you talk a bit about what kinds of things you work with them on and what that collaboration looks like?

Krystof Woldrich:

Yes. I have a great example from a few months, maybe already a year, time flies very fast back when the new architecture was introduced and developers from all around the world, not only Meta could try it out and then use it. So I'm talking about reactive 0 68, 0 69, where we as a error monitoring first and foremost noticed changes in the turbo modules and the way that we capture the JVM Stack trace and some information was missing and we weren't sure if we need to change the way we capturing it or if it's oversight on the framework side or what's going on. So for me, that's the first time of me being in Century where we got in close contact with the team with Nicola Corti and Ricardo.

So we were discussing this, what's going on, and eventually it got resolved and we were seeing nice Java stick traces and all was good. And while we were exploring the changes and what the turbo modules bring, there was a question that stand out to us and it was question that also our customers are bringing to us. And that is, well, it's nice to see JV M Tech Trace, it's nice to see objective C Stack Trace, but I haven't touched objective here or Java. I just wrote some JavaScript code and I want to know which part of my JavaScript broke it, what would happen there, something that I can touch and remove this line to fix it. So that was a point where we did a bit of a research and proposed what we call mixed stack traces where you mix the native stack trace and the JavaScript stack trace React native already does it in some cases, but at the beginning of the turbo modules it wasn't capturing the errors thrown in the function calls of the turbo modules itself.

So if you would've a native call and wrapped it in JavaScript and the native code throws drawable into JBM, it wouldn't capture anything inside of your JavaScript actually, which was very, very strange. And primarily myself and of course the reactive team implemented is wrapping basically triage on the native layer and capturing the stack trace, passing it to the JavaScript layer. So in the error object that you capture, you actually see the geos script part as you would expect it, but there's also extra properties where you can see the addresses on iOS side or the actual stack trace on the JVM. And of course then we are adjusted reactive SDK to be able to read this and send it to the Century servers. And that was super nice collaboration for me and actually also one of my first commits to the React native repository.

Robin Heinze:

Yeah, you can call yourself a React native core contributor.

Krystof Woldrich:

Yes, yes. I think actually last week finally, it's more than two hands of comets merged in. So yes, I'm proud of that. It feels

Robin Heinze:

Good. That's pretty impressive. That's it's small. It's a small club of people with that many commits, so that's very cool. So I would think in the same vein as dealing with stack traces and figuring out where errors are happening, there's got to be some involvement with Metro. I'm guessing. We did a metro episode a couple months ago and that's the extent of my knowledge of Metro. It's usually kind of a run it and forget it, but what sort of intricacies do you have to contend with in making Metro happy with stacked races and such?

Krystof Woldrich:

Actually quite a few. At this current version, there are three things that we change or three main things and some upcoming changes that's quite new part of the century React native SDK, where we have this sub export called Century reactive Metro. Sometimes we refer to it as a century metro plugin. And yeah, the question is like why do you need it? Right? You run in the runtime, you capture the error all good. What do you change in metro? So when you go back in history of the comets, it wasn't always React native slash metro. Originally it was react native slash metro slash tools slash, how is it called? Custom sterilizer. And so there was the first time we felt the need of extending or adding something to the bundle that wasn't possible just to write the code inside of our package and use it like that.

And the reason was debug IDs, which is a concept invented or create and propagated by sent, but it literally targets every JavaScript developer. Everyone who needs source maps will benefit from debug IDs. And what it is, it's a simple unique identifier of your bundle of the file and it creates a unique link between that file and the source map. So you cannot ever lose the two. If you would imagine having a website and you generate your source maps, you a small change source, maps get regenerated, you forgot to save the previous version, you just blindly take the folder you have and you would end up with a funny looking stack trace because of the source maps. That's the overall message. So that was the first thing that we felt like, okay. And so to make the debug IDs work and make the debug ID being able to compute it and inject it into the bundle, we use this serializer property of metro because that's the step where we already know the whole bundle, everything that will end up inside of it, but it's not yet serialized and written to the file. As we had this metro integration, things started moving forward. Actually one of the React core members reached out about an issue where he was seeing century stack traces in the red box. The red box property where

You get an error,

Robin Heinze:

Everybody hates

Krystof Woldrich:

The red box. Exactly,

Robin Heinze:

Exactly.

Krystof Woldrich:

And you would hate it even more when Century would obstruct your view and you wouldn't see actually your code. That's another reason for using having this metro export because Metro has a property which lets you specify the frames that you would like to hide in the default red box view. And so we automatically add all our frames. So when you have metro, sorry, when you have sensory running in development, in production, doesn't matter, we won't be standing in way of seeing your code similar as we do in our product where we highlight your code primarily because that's where you can take the action. We also ensure that we don't obstruct the traces and your code when you're seeing the error in the red box.

Robin Heinze:

Yeah, that's an interesting problem. You want to see Sentry sometimes, but

Krystof Woldrich:

Not, but in different ways.

Robin Heinze:

Yes. When you don't want to see sent very,

Krystof Woldrich:

Not when you're trying to get to your code, you don't want to see, oh, it was logged by sent and then it went to this React native courting, right? Like React native heights, their frames by default. So we basically extended this list with our frames that shouldn't show up, and there is actually many more use cases for Metro. We are adding our components annotation plugin, which is actually a bubble plugin, but thinking about developer convenience, we don't want to tell our developers and users, oh, you should now go into the bubble config file and change things there. We already have this metro plugin that can do things for you and Metro enables you to change the bubble settings. So we do that also with that plugin automatically to enhance the experience. It

Robin Heinze:

Is, it's a good, I know personally I cringe every time I have to do anything with babble. So if you can wrap it into your metro plugin then that's great.

Krystof Woldrich:

Yeah, and there are upcoming things that we are working on right now. If people would go to the prs, they would already see it there. And that is optimizing the bundle size because there are some dependencies of ours that we know in certain cases we don't need, but they cannot be tree shaken yet because Metro doesn't support tree shaking by default. But we actually can during the resolution phase, when we know which platform we are targeting, we can drop them out. And so that's another thing we are adding to this metro plugin. So it's growing and growing and it's all for the developer's. Convenient. It would expect. It doesn't have to do much with the runtime itself, but it's all these little convenient stuff to make the experience very smooth and pleasant.

Robin Heinze:

Well, we appreciate it. I want to make sure we have time to talk about the latest coolest greatness in Century React native and if you were at Chain React, you got a preview of this, the really cool new feature that is in beta now is called Session Replay. Why don't you just tell us a little bit about what Session Replay is and then we'll go from there.

Krystof Woldrich:

Session replay is basically having a phone of your user that miles away, having it in your hand, looking at their screen, seeing what they're touching, what's being locked into the console and fixing the error because

Robin Heinze:

Like what button they pressed,

Krystof Woldrich:

Exactly

Robin Heinze:

What screens they went to when their app crashed.

Krystof Woldrich:

Yes,

Robin Heinze:

Wild

Krystof Woldrich:

From just one beautiful interface. It's basically a Chrome dev tools, but for your React native app that's running into production.

Robin Heinze:

Amazing. And I know it's been out for a while for browser based applications, but what was the process like of adapting it to React native, which is like browser ish but not,

Krystof Woldrich:

Yeah, in this case the native really stood out because funny saying React native is native. Well, that really confirms when we started developing the session replay and coming from the browser where there is very efficient way of recording the dome changes and then replaying them. So you have a small file size that's being sent because you're not capturing your actual video. It's what we would say video. It looks like a video. It's not a video that wasn't possible for the mobile platforms. So it's a podcast for developer. Technically it's possible, but in our testing

Robin Heinze:

Develop is going to be like, well actually

Krystof Woldrich:

Yes it's possible, but when you try it out, it's not scalable, it doesn't perform the way we would expect it and it did not have the fidelity of what we would expect to see on our laptops when previewing the replay compared to browser, it's actual video, we are actually creating an MP four that's being compressed and sent, but that likely brings many questions, how do I remove the text? What about images? What about animations and other things?

Robin Heinze:

Yeah, so what about all of those?

Krystof Woldrich:

And of course if you've been at Chain Direct as mentioned before, you've seen that it wasn't an issue. And that's because we at the moment of creating a screenshot, which is roughly once a second, we also capture the view hierarchy and that gives us the detailed information about there is a text and it's a disposition, there is a image and it's a disposition and there is some other text somewhere else which is not visible, so we don't have to care about it, but these items are visible. So we combine the screenshots and the view hierarchy to remove all the private information before we save it and send it. So nothing private leaks the device going towards Century.

Robin Heinze:

Interesting.

Krystof Woldrich:

You might ask what you consider private. Well, we cannot make assumption. How would we know this heading really is a heading and someone didn't use it just to make text bigger and just put their address of the user. Yeah, there are definitely interesting GitHub issues you can find where we are talking about should we out of the box send or not send accessibility labels. The result of this is not sending them because again, assumption would be in general way, there won't be private information is some sort of description of okay, this is a button to proceed to checkout. But in reality, especially when you want to make good user experience, you might say there, John, this is a button to proceed to checkout

Robin Heinze:

And

Krystof Woldrich:

Nothing you have there all of a sudden private information. And the same approach we take with replay where all text, all images and all SVGs are removed, redacted by default. So you really don't see any text and images because that's the only way we can be sure. Okay. Now there is not private information.

Robin Heinze:

Yeah, I can see it being the primary concern that companies would have using something like this. So it's probably better to be extra safe. Mean as a developer, if I'm looking at a replay, I know what the app I built looks like. So even if all the texts and images are redacted, I'm still going to be able to get the information that I need to debug it. Yes. So you mentioned screenshots plus the view hierarchy. So does that mean you're creating a video by stitching together screenshots? Is that what's happening?

Krystof Woldrich:

Yes. Yes, exactly. So we take the screenshot when it's possible to detect that nothing change on the screen we optimize and not taking it are not taking it. But when there is an animation or something actively changing on the screen, it's roughly once per second, which from our testing was a good rate to perceive the animations that are happening in the application even when you don't know the app. And also performance wise and overhead wise, this was acceptable.

Robin Heinze:

Yeah, that was going to be my next thought. It was like what kind of performance implications would this have if this is happening in the background? And is it only when errors happen or are you having to do it all the time

Krystof Woldrich:

Actually seeing the replay? In Century there are two options. One is from beginning of the session when the app was open all the way till the end. And then what you mentioned about errors then is the error or what we call it the buffer mode where we still record all the time. And the reason for it is showing you what happened leading to the error. When you enable session replay, it's always recording.

Robin Heinze:

It reminds me a bit of the black boxes on airplanes where it's always recording but it's always like deleting stuff after a certain amount of time if nothing has happened basically. So then something happens and it's like, okay, we can keep the buffer that we have right now, but we don't need any of the other stuff before that.

Krystof Woldrich:

Yeah, that's actually a great analogy. It's a black box and when your airplane crash, your app crashes, there you go. You go and retrieve it and see what happened.

Robin Heinze:

Basically. That's how I see it anyway. So is there any implications for letting the user know that this is happening? Does it have to be reported to the app store? What kinds of implications are there for the end user?

Krystof Woldrich:

So there are no changes when it comes to your privacy manifest and things like that. When you're enabling the session replay, if I compare it to app with sent without session replay, there is a list of things that you need to make sure you have edit to your privacy manifest when you add sent and if you had sent before you already made these changes.

Robin Heinze:

Okay, so session replay doesn't add anything new,

Krystof Woldrich:

Basically no session replay doesn't add anything new in

Robin Heinze:

That case wouldn't already have by using Sentry.

Krystof Woldrich:

Exactly.

Robin Heinze:

Okay, that makes sense.

Krystof Woldrich:

When it comes to the users, the end user seeing if something is being recorded or not, we in the mobile SD case, don't provide any UI as of right now and not only for session replay, but in general the SDKs provide APIs for the developers and not for the end users. So as a developer, if I decide to show to my users like I've recorded your session or I'm recording your session right now, there's an API to retrieve that information like, Hey, is this session being recorded? Yes or no? And then I can show a big red button or whatever I decide to do.

Robin Heinze:

So basically it's up to the developer whether or not they tell their users. But Sentry provides APIs that would let you get information about whether or not the session being recorded. So you can tell the user if you want.

Krystof Woldrich:

Yes, exactly. If you decide to tell your users you have the option to do so.

Robin Heinze:

That makes sense. So I know this is in beta, but do you know of anybody, do you have companies that you maybe partner with that are already using this in production and do you have any data for how it's going?

Krystof Woldrich:

Yes, there are hundreds of beta users at the moment. I cannot talk about the names for obvious

Robin Heinze:

Reasons. That's fine. And

Krystof Woldrich:

I also don't have the information if the apps are in production or not because our current recommendation is this is an open beta, please go try it out and open a GitHub issue if something is different than you expected.

Robin Heinze:

Generally how betas work. Yeah.

Krystof Woldrich:

Yes. That's the phase where we are to a point.

Robin Heinze:

You want people to use it so that you can get that feedback and make it even better and more stable.

Krystof Woldrich:

Exactly, because we can test it on 10 of our devices. And I like to walk around with this Pixel four, which is many generations behind right now is pixel line was introduced very recently and show people, Hey Luke, this is being recording and it has profiling enabled and performance monitoring and the animation is still butter smooth.

Robin Heinze:

I should try it out on my Pixel two. I think I have,

Krystof Woldrich:

Oh now we are stretching it, but give it a try.

Robin Heinze:

Try. I think I also have a Galaxy S five somewhere that I haven't booted up in years, but I don't know if we'll push it that far. Unfortunately, we're basically out of time, but this seems like a really amazing feature. Before we go, what's kind the future for session replay but also for Century in general and are there any features that are on the roadmap that you're able to share with our audience?

Krystof Woldrich:

Yes. So I haven't mentioned it, but the century SDKs are open source and when I say open sourced, I truly mean MIT licensed. So I love a lot of the things we are working on in preparing. You can see in the code and in not only in the code, which doesn't have to be easy to track, but also in the GitHub issues. And that's amazing because that means it's public information and I can tell you all about it. And so for example, for session replay, what we are looking into is React native specific feature. And that is not only telling you the component name and its file that it lies in when a user interacts, but from browser you might know that we have this nicer component where you see actually the HTML structure. And since in reactive we've worked with JSX structures and writing the React code, we are working on previewing you the JS six structure. So it's very familiar. You glance over it and you see, oh yeah, this is familiar. I wrote this two weeks ago and I don't remember how

Robin Heinze:

It works anymore. That's my code. It's like every time I look at a Stack trace or anything, I'm like, oh, I wrote that, that's mine.

Krystof Woldrich:

And if you don't remember, there is the Suspect Commit feature which tells you, well it's actually been you and that's why you were assigned to it.

Robin Heinze:

Oh, it's like get blame. Yes. Never want to know that it was you.

Krystof Woldrich:

Yeah, the information you never want to hear. But there are other things that we are working on beside session replay, like improving startup crashes specifically for the hybrid SD case, which we consider reactive and flutter where you have this period of time between the engines startup and a crash can occur during that window where the app already is running, but the JavaScript engine React native, it'll be hermis most likely haven't started up yet. And at the moment you have to manually go and say Century initialized at the beginning like you would be using pure native app and for the future and for the convenience of the developer. We want to make this magically happen so you don't have to go and change the native code. And this nicely ties to the export integrations where the code is being generated and express this ecosystem of plugins that let you add to the native code. And that's something what I'm really excited about, again, making it more smooth and easier for every developer.

Robin Heinze:

Awesome developer's heart sent. So we appreciate it. I wish we could talk about this all day. Thank you so much for coming on today and talking about Sentry. I really enjoyed it and we'll make sure that we put everything that we talked about, all the links to Century, including Christophe's Chain React Talk will be in the show notes. So thank you all for listening and thanks for Christophe for joining us.

Krystof Woldrich:

Thank you for having me. It was pleasure. I could talk about React native and SK all day long.

Robin Heinze:

I know. I love that. We always get to talk shop. Thanks everyone. We'll see you next time.

Jed Bartausky:

As always, thanks to our editor, Todd Werth, our assistant editor, Jed Bartausky, our marketing and episode release coordinator, Justin Huskey and our guest coordinator, Mazen Chami. Our producers and hosts are Jamon Holmgren, Robin Hines and Mazen Chami. Thanks to our sponsor, infinite Red. Check us out at infinite.red/radio. A special thanks to all of you listening today. Make sure to subscribe to React Native Radio on all the major podcasting platforms.