React Native at Scale

Summary

Software Engineering Daily: "React Native at Scale" (May 21, 2026)

Host: Josh Goldberg
Guest: Manjari Mogay, Staff Software Engineer at Coinbase

---

Episode Overview

This episode explores how React Native enables large-scale, high-performance mobile development, with a deep dive into Coinbase’s journey, practices, and architecture. Manjari Mogay shares her personal story and offers practical guidance on observability, performance optimization, reliability, AI tooling, and scalability—pulling from five years of experience building and maintaining one of the most demanding React Native applications in the world.

---

Key Discussion Points & Insights

1. Manjari’s Journey into Coding and Mobile (02:03–04:36)

• Background: Majored in electronics and telecommunication; initially avoided software due to her mother’s influence as a COBOL programmer.
• Turning Point: Building a hardware project in VHDL changed her view:

  “That's when I was like okay, I built this, I can do this. And I realized the power of coding and software engineering in general.” (03:13)

• Early Mobile Development: Started with iOS/Android, worked through hybrid solutions like PhoneGap/Cordova, then embraced React Native in 2016.
• Coinbase Transition: Joined post-React Native rewrite in 2021, hasn’t looked back.

2. Why React Native? Core Value Propositions (04:36–07:23)

• Best of Both Worlds:

  “React Native gives you the native feel, but the underlying technology of writing like JavaScript and CSS, which is the same as web, remains the same.” (04:52)

• Developer Velocity: Write once, deploy to iOS & Android, minimizing feature lag and maximizing speed—especially vital for rapidly changing sectors like crypto.
• Use Cases:
  • Ideal: High-velocity, data-driven apps (e.g., finance, crypto)
  • Not Recommended: Games or graphic-heavy apps (animation performance)

3. Advice for Teams Adopting React Native (07:33–10:58)

• Three Key Recommendations:
  1. Observability:

     "If you don't measure it, you will never be able to improve it." (07:37)

  2. Guardrails & ESLint:

     "Nothing is more impactful than something that blocks the developer while writing code and gives them information as to why this is a bad pattern." (08:32)

  3. Discipline & Design Systems:

     "Defining performance budgets... creating shared components ... in the beginning, not after a fact." (09:32)

• Design Systems:
  • Shared web/mobile component library fosters uniformity, velocity, and strong onboarding.

  • “If your code looks like my code, it's a win. If two developers at the same company are writing the same pattern of code, that's actually a great thing.” (10:27)

4. Performance Optimization Methodology (11:17–14:39)

• Performance Metrics Divided Into Four Buckets:
  1. Cold Start Time: Launch speed.
  2. Navigation Fluidity: Are there lags or unnecessary spinners?
  3. Error Surface: User-blocking vs. non-blocking errors.
  4. End-to-end Journey: How long does a full user flow (e.g., buying crypto) take?
• Focusing Efforts:

  "If you try to improve every single metric, it's like boiling the ocean." (13:18)

• Continuous Cycle: Metrics regress over time—require vigilance, automation, and ongoing investment.

5. Performance Debugging Tactics (14:39–17:24)

• Profiling Technique:
  • Use React DevTools to identify slow API calls, long-running JS threads, unnecessary re-renders.
  • Audit data fetching, defer non-critical tasks, and consider infrastructure/dependency impacts.

  "Profiling gives us all of that data if not most." (15:28)

• Native Thread Offloading:
  • Heavy work can move off JS thread to native or handled after UI interactions (e.g., analytics events).

  “That's the best part of React native where it lets you hand off certain operations to the native thread and not take away from the JavaScript thread.” (18:10)

6. Reliability Engineering & Observability at Scale (18:26–22:32)

• Key Metric: Error Rates
  • Errors bucketed as blocking or non-blocking.

  • “We monitor them literally every minute. If you are on call, that’s like your biggest responsibility.” (19:38)

  • Outages and spikes correlated to user behaviors (e.g., crypto price surges).
• Experimentation:
  • A/B experiments for both product and infrastructure changes—rollout only if controlled treatment scales.

  • “We do a lot of experiments... and see if the treatment is actually one that is going to be permanently shipped.” (21:19)

  • Sometimes work gets reverted if it doesn’t improve user engagement:

    “It’s very disheartening to delete that code that you have written. It’s very disheartening but it is what it is.” (22:14)

7. Global Scalability Challenges (22:39–24:34)

• Varied Device Landscape: Performance profiles for devices outside the US often lag; must optimize for these.
• Retention Depends on Speed:

  “If it’s taking me six, seven seconds to do something extremely simple in an app, I’m going to just move to another app.” (23:18)

• Testing: Use network link conditioners, device farms, and external QA teams to reproduce hard-to-trace bugs.

8. Data Fetching and Loading Patterns (25:08–30:46)

• Avoid Overfetching: Each unnecessary request incurs backend load; configure APIs to fetch only relevant data (e.g., region-specific compliance).
• Polling Pitfalls: If improperly canceled, polling can flood services with unnecessary requests.
• Preloading Data: Only preload if a very high percentage of users will need it.

  “You preload the data. But what if the user never goes to that screen? Now you have wasted the preloaded data.” (27:07)

• Automation & AI Feedback: Using AI bots in PRs to call out bad patterns in code (e.g., excessive polling or non-cached queries).
• Feedback & Experimentation:
  • Gradual rollouts/trials observe real impact before full deployment.

9. GraphQL and Data Loading Evolution (30:46–33:26)

• GraphQL Benefits:
  • Request only the data you need.
  • Modern GraphQL supports field-level deferral for more efficient loading.
• React Suspense Integration: Tie loading states directly to data fetching, enable detailed instrumentation (e.g., time-to-render per component/screen).

  “The suspense is so contextual, it looks great. It keeps the user engaged... And it also gives you so much out of the box for measuring metrics.” (32:40)

10. React Native’s New Architecture: JSI & Turbo Modules (33:26–35:34)

• JSI (JavaScript Interface):
  • Eliminates the old 'bridge' between native and RN, making integration much faster.
• Turbo Modules:
  • Speed up access to native device features (camera, secure storage).

    “It’s a way of making these native interactions faster for React Native.” (34:54)

11. AI Coding Agents in Practice (35:34–38:53)

• AI-Generated Code at Scale:

  “Our CEO Brian just tweeted about this two days ago...more than 50% of code is AI generated.” (35:41)

  • Internal AI tools/agents speed up day-to-day development and automate repetitive tasks.
  • Success depends on providing good context; agents tailor code to company standards.
• Lint Rules & Consistency:
  • Lint rules (e.g., ESLint) help AI agents produce idiomatic, error-free code.

  • “I use AI to just say, okay, give me violations for this lint rule...You do have to check the work.” (38:28)

12. Operational Excellence and Preventing Metric Drift (38:53–41:16)

• Continuous Monitoring: Teams review incidents, error rates, and performance budgets weekly.
• Automation: Offload repetitive checks & root cause analysis to AI to avoid repeated failures.

  “These learnings are so important... more often than not, there are incidents that happen because of the same root cause and that is something that we want to avoid.” (40:38)

13. Handling Explosive Growth and Feature Pressure (41:16–42:32)

• Prioritization Is Key:

  “If it’s impacting a lot of users, we have something called as severity metrics at Coinbase...” (41:49)

  • Triage based on scale and impact; some bugs take precedence over feature work, especially for high-value users.

---

Notable Quotes & Memorable Moments

• On React Native’s Impact:

  “It's been around for 10 years and only getting stronger because of the community and the contribution it gets from all these amazing native engineers and web engineers together.” (05:12)

• On Performance Monitoring:

  “Metrics are great, but having too many metrics adds confusion. So there needs to be a limit to what you measure and what you improve.” (13:10)

• On Experiment Failure:

  “It's very disheartening to delete that code that you have written. It's very disheartening but it is what it is.” (22:14)

• On AI Coding Agents:

  “In the past I would probably be able to open one PR a day, but now I have all these agents...I have five PRs open and it's just massive velocity.” (36:18)

---

Important Segment Timestamps

• 02:03 — Manjari’s coding background and React Native story
• 04:36 — Why React Native is compelling for companies
• 07:33 — Core advice for new React Native teams
• 10:04 — Design systems’ importance in React Native/web
• 11:28 — Defining and measuring performance in RN apps
• 14:39 — Debugging Cold Start and performance regressions
• 17:33 — Threads in React Native and performance engineering
• 18:37 — Defining and monitoring reliability at Coinbase
• 22:59 — Globalization and device/scalability challenges
• 25:18 — Ensuring reliability as user base scales
• 28:49 — Preventing (over/under) fetching and API inefficiencies
• 30:52 — How GraphQL helps (and when it's appropriate)
• 32:20 — React Suspense and instrumentation, performance wins
• 33:35 — New React Native architecture: JSI & Turbo Modules
• 35:41 — Real-world impacts of AI coding agents at Coinbase
• 38:53 — Team operational excellence and avoiding metric decay
• 41:34 — Prioritizing when faced with scale, bugs, and feature demand
• 44:17 — Advice for new React Native developers

---

Getting Started & Further Resources

• AI as a Learning Partner:

  “Just take help from AI, have them build that greenfield app for you and ask the questions right in your prompts. I think it's the best way.” (44:17)

• Official Resources: reactnative.dev
• Contact Manjari: LinkedIn

---

Tone & Takeaways

This episode is both practical and encouraging, balancing the hard realities of large-scale mobile engineering with optimism about modern tools. The conversation is honest about failures, performance painstaking, and the messiness of real-world reliability—while celebrating community, automation, and the power of shared knowledge in scaling React Native.

---

(End of summary)

Transcript

[A]

React Native is an open source framework developed by Meta that allows engineers to build mobile applications for both iOS and Android using a single JavaScript code base. The framework bridges the gap between web development and native mobile, which lets teams ship to both platforms simultaneously without sacrificing the look and feel of a truly native app. Manjari Mogay is a staff software engineer at Coinbase, where she has spent five years building and scaling one of the world's most demanding re React Native applications. Her work spans performance optimization, reliability engineering, and the developer tooling that keeps large engineering teams moving quickly without sacrificing quality. In this episode, Manjari joins Josh Goldberg to discuss why React Native has become the framework of choice for high velocity mobile teams, how Coinbase measures app health, how to handle data fetching and loading in production, how, how AI coding agents are changing the day to day workflow for mobile engineers, and more. This episode is hosted by Josh Goldberg, an independent full time open source developer. Josh works on projects in the TypeScript ecosystem, most notably TypeScript eSlint, a powerful static analysis toolset for JavaScript and TypeScript. He is also the author of the O'Reilly Learning TypeScript Book, a Microsoft MVP for Developer technologies, and a co founder of SquiggleConf, a conference for excellent web developer tooling. Find Josh on bluesky, Fostodon and dot com as Joshua Kgoldberg.

[B]

Hello everyone. With me today is Manjiri Mogay, Staff Software Engineer at Coinbase. Manjiri, welcome to Software Engineering Daily.

[C]

Thank you. I'm excited. I've been an avid listener and yeah excited to talk to you today.

[B]

Great. Well we're excited to have you here. Let's start off with you. How did you get into coding?

[C]

Yeah, so I got into coding pretty late. At least I like to think that I got into coding pretty late. I am an electronics and telecommunication major and we did have coding subjects in engineering, C, C, Java, but I never really liked them. It's probably because my mom was actually into software. She started coding in 1983 in Cobol and I grew up around programming books like ERP, SAP, Java and I made up my mind this is not something I want to do. So I definitely registered it. But it wasn't until my final year hardware project where we designed the pcb, wrote hardware code in it was called VHDL Hardware Descriptive Language and I saw it working on the circuit. That's when I was like okay, I built this, I can do this. And I realized the power of coding and software engineering in general. So Right out of college I got my first job at a consulting company. I learned iOS and Android. It was the AI back then, you know, 2011, 2012, everyone wanted to learn mobile development and I was very happy. I was working on like cutting edge technology. Loved native development back then and then moved towards hybrid mobile development which was this phase when everyone wanted the apps on iOS and Android to be built at the same time. But we didn't have React native and we used to have this wrappers using like phonegap, Cordova. It was just wrapped around a webview, did not feel native at all. But you built only once actually web mobile built together and then deployed on iOS and Android. And then React Native came out in 2015 and everyone was so excited we didn't have to wrap web views around anymore. We could write code that felt like native, write it only once and Deploy it on iOS and Android. And yeah, I have never looked back since 2016. Did multiple rewrites from hybrid or native mobile to React native. And at my previous company came time where I worked, we did the rewrites and I joined Coinbase because Coinbase was a big proponent of React Native. They had just done the native to react native rewrite when I joined Coinbase in 2021 and it's been five years and I haven't looked back.

[B]

It sounds like a wonderful journey. Let's dive into some of the high level attributes of React Native you mentioned. So a lot of developers may have heard of React, this sort of front end web space thing. Why and how is React suddenly on mobile? What does that mean for a developer?

[C]

I think the biggest thing here is React Native gives you the native feel, but the underlying technology of writing like JavaScript and CSS, which is the same as web, remains the same. So many web engineers were able to adapt to React Native fairly quickly. I want to say React Native does need native understanding and some native skills, but not too much. That is why I think it was a brilliant home run from Meta to build React Native because it attracted web engineers, it attracted native engineers and it created this community that now builds mobile apps. And that's what I even love about React Native. It's been around for 10 years and only getting stronger because of the community and the contribution it gets from all these amazing native engineers and web engineers together.

[B]

It's kind of a best of both world situation, sounds like. So when you say that they're built at the same time, what was the difference between writing native apps versus a React Native app?

[C]

Yeah, I think the biggest Difference from a company perspective is obviously the speed, the velocity that you build. Products with iOS and Android, you have to build code on them separately. Unfortunately, and in my experience in the past, I have realized that you are always playing catch up. You always have that business priority of a product, what that needs to be launched on X date, and then it comes down to, okay, 80% of my users are on iOS, I'm going to first build it on iOS and then Android follows. So you are never able to maintain that feature parity between iOS and Android, whereas on React Native you write that code once and then it goes out on both. Yes, there are differences because iOS and Android are just different architectures. But rarely if you are writing like pure JavaScript code, you have to make distinctions for iOS and Android. So it depends on the space you are in, like if you are working on animations or if you're building a game. I would not recommend React native because it's not there when it comes to animations and the performance that's needed. But if you are building a financial app like we do, like Coinbase and where velocity matters because the world is changing so much, the crypto industry is evolving so much, we are launching products at such a scale that if we were building two apps, iOS and Android, we would just not be able to keep the feature parity.

[B]

That's a very appealing value proposition of reducing velocity. Let's say that a company is just now getting started, switching to React Native and or making a new app. In our end, what advice would you give them?

[C]

Yeah, I think I have three pieces of advice. First is observability. Many teams or many companies building mobile apps consider observability as their P1 or a non functional requirement. But I feel like observability is so important, like if you don't measure it, you don't know how to improve it. So I think observability needs to be the first thing because people go to React Native and then say it's slow. But what is slow, if you don't measure it, you will never be able to improve it. So you need to have observability in place. Second is guardrails. There are so many good patterns, bad patterns that are already defined in React Native that if you're using TypeScript and you have Eslint rules. You know about Eslint, Josh? I love Eslint and I feel like it's the unspoken forced rule that you can have developers follow. You can write multiple documents, you can have so many presentations or learning sessions and whatnot. Nothing is more impactful than something that blocks the developer while writing code and gives them information as to why this is a bad pattern. So I think that's very, very important when you are building in React native especially. It may apply to other technologies too, but especially in React native we have been like exhaustive dependencies is such a simple eslint rule goes such a long way and can catch so many performance regressions. So yeah, that's the second thing and third thing is I think just discipline built into platform defining performance budgets is how long should this screen load take? Should it be under 2 seconds? Should it be under 3 seconds? How do we want the navigation to work? You know, because React navigation is such a critical part of React and also sometimes the biggest footgun lists again in React native because we have the virtualized dom, I think defining what you want to do in that area, creating shared components for it in the beginning, not after a fact. So playing offense for building that shared repository is the third thing. I would advise teams or companies that want to move to React native.

[B]

That's a lot of great info. The last tip there, you ended with what almost sounds like a design system. I know front end folks and websites are very often these days building design systems. Does that also hold true for React native apps?

[C]

Yeah, I think so. Shared design system, especially for a React app or a React native app is very critical. So we do have a coinbase design system which is actually now open source. So if you're writing web code or React native code, sometimes you won't even realize that you are in a different repo because it's the same design system. You are using the same elements that you would use on a web app on a mobile app. So that's great. Actually if your code looks like my code, it's a win. If two developers at the same company are writing the same pattern of code, that's actually a great thing. So yeah, definitely. I think design systems are a way to go. We have so many abstracted components in design system like lists, models, trays so you don't have to do the same performance optimizations again and again. When you are building new features, they are just given to you out of the box.

[B]

That sounds like another example of improved developer velocity.

[C]

Yeah, exactly. And it's also easy to onboard to a design system because there's just a lot of examples, so much documentation. You don't need to reinvent the wheel. So if new engineers are joining your team, they are ready to go super quickly.

[B]

Swell. Let's dive into some of the more deep and rich end user facing metrics. You mentioned performance. How do you optimize for performance or design or architect for performance in a react native world?

[C]

Yeah. So I think there are many ways to look at performance. My simple definition of performance is how does the app feel when you open the app and try to do something that you intended to do? For example, we all open our apps, especially our stocks and crypto apps to check the balance. How is my portfolio doing today? So I consider that as like a critical operation that needs to happen under certain seconds. Also, am I being shown many suspense or like loading states? That's a big turn off. So I try to divide performance into four buckets. One is the cold start metrics. Cold start is when your app is totally killed. You open the app, how long does it take for you to land on the main screen of the app? Second is how does the app feel? When I navigate between screens, are there too many loading indicators? Is it slow? Is it getting stuck? Third thing is how many errors am I experiencing or is the app user friendly? Am I getting full screen errors and something that's putting me off or not letting me do the job that I came to do, which is check my balance. And the fourth metric that I want to talk about is the end to end journey. By that I mean is I open my app, I see the landing screen, I check my balance. Now I want to buy crypto. I how long does it take me to get to buying crypto and finishing my trade? That's the other metric that we look at. Before I get into too much detail, I want to pause and say that metrics are great, but having too many metrics adds confusion. So there needs to be a limit to what you measure and what you improve. If you try to improve every single metric, it's like boiling the ocean. You cannot achieve what you want to. So the focus needs to be extremely narrow. When you are trying to improve performance,

[B]

how do you choose which metrics to focus on then? If you've got a big app with

[C]

a lot of them. Yeah, great question. It depends on what's the need of the hour. Like what should we focus on Today you improve a certain metric and then I think it takes two years in my experience for that metric to regress and then two years later you're again talking about it. It's also because you know the trends change over two years. You just have shipped so much code. New team members have joined so they don't know the metrics that you talked about. That is why I think automation and guardrails is just so important. So you fix one problem and it never happens again. But unfortunately in performance world it does not happen. I feel performance is recognizing certain bad patterns and then optimizing it is just a task. It's not something heroic because you keep running into the same problems again and again.

[B]

Performance is a flat circle. Yes, let's say that you have an app and you've noticed that Cold Start used to be wonderful, now is terrible. Let's dive into the tech details a bit. What would you do to debug this performance issue?

[C]

Yeah, so we do something called as React profiling. We profile the app, we use react dev tools to profile the app, see exactly what is happening, which API calls are taking too much time. Is any JS thread operation that is long running on a JS thread that we can move or defer to a later time? Do we have bad rendering patterns? Are we re rendering our code too many times? That's something that we look at. So I think the approach is multifold bad fetching patterns. We audit the data that we are requesting for cold start. We look at any JS long running tasks that we can defer or move away from the main thread. And yeah, profiling gives us all of that data if not most. That's something that we look at. And also sometimes updating React native versions or moving to the new architecture that is out helps with Cold start metrics. It's not always your core, it's also sometimes your dependencies and your infrastructure.

[B]

TurboPuffer is how companies like Anthropic, Cursor, Notion, Atlassian and Ramp ship their most ambitious search features. TurboPuffer is a serverless vector and full text search engine built on object storage. It's up to 95% cheaper than traditional search databases and just as fast. With TurboPuffer you can index and search 50 million documents at 10 millisecond P90 query latency for less than $100 per month. Head to turbopuffer.com sed to get your

[A]

first month free in mobile application security. Good enough is a risk. Guard Square uses advanced multi layered code hardening techniques and automated runtime, application self protection and mobile application security test combined with real time threat monitoring to deliver the highest level of mobile app security. Discover how Guard Square brings all these together to provide mobile app security for your Android and iOS apps without compromise at www.guardsquare.com every AI team eventually hits the same wall. The models are solid. The infra is Solid. But the data coming in is hours old because the pipeline is batch when it should be streaming and nobody's had time to fix. That's not a modeling problem, that's a pipeline problem. Estuary gives you CDC batch and streaming in one platform. 200 plus connectors live in hours, not weeks. Your AI is only as good as your pipeline. Estuary.dev Interesting that you mentioned threads.

[B]

In webland it's all just one thread. And then maybe you use a service worker, but here it sounds like we've got a lot more intricate stuff to work on. How does that work in real life? React native.

[C]

Yeah. So for React native, you can fall back to the native thread. I call it the native escape or a hatch. You can defer some of the heavy programming or heavy computation or long running tasks to the native thread. You can also do something like run after interactions. That used to be a hook, it's actually being deprecated. But there are some similar things that React native has been launching but run after interactions are complete. Which means once your screen is loaded, you can run those computations. For example, if you have any analytic events that you are sending back to your service now, those can run after you know all the interactions on the screen are complete. So yeah, I think that's the best part of React native where it lets you hand off certain operations to the native thread and not take away from the JavaScript thread.

[B]

That's a powerful feature. I want to switch gears a little bit and talk about reliability. You mentioned analytics. Let's say that I have an app and it's in production. What should I do to figure out even whether it's reliable at all?

[C]

Yeah. So reliability, I want to say, is there is a single user using your app and the app works great. Now there are 100 users and they are using your app. Does your app scale, do your APIs respond in a way that they should be? So does it handle traffic? And there are many ways to look at reliability. One is obviously, am I able to get the data from backend or do I just see a bunch of errors? So the way we do it is we have certain reliability metrics, the biggest one being error rates. Error rate is we categorize them into a few buckets. Error that blocks the user. Error that does not block the user. And a blocking error is not just a full screen error or something, but if a user is not able to perform a journey that they intended to do, that's considered as something that's blocking the user. We monitor them literally every minute. Of the day, our eyes are glued. Like, if you are on call, that's like your biggest responsibility. Because we have high traffic and also being in an industry which is influenced by like even tiny, like, price movements in like major crypto assets, we have to be on top of it. So if we start seeing like these errors spike up a little, we immediately start investigating, okay, is there a price movement? Is our traffic spiking? What's going wrong? What do we need to do to, you know, figure out? So we start that root cause analysis and this is very established framework at Coinbase on how to figure out if something's happening. So error rates is our biggest metric. Also, like traffic usages, if we see some of our critical services seeing very high requests per minute, that is also another indication that, okay, something's happening or why is this happening? Do we need to investigate it further? So, yeah, those are some of the metrics that we look at.

[B]

It's interesting that you talk so much about end user behaviors like price surges. Do those in your experience have a significant impact on stability of the app or areas that you have to focus on?

[C]

Yes, they do. And that's something that also drives most of our optimizations, honestly, because we experience like new scale. Like, so four years ago, Coinbase had X million of users and now we have even more. So once the users scale, we have to scale for it. And the user behaviors definitely drive what we do because that opens a new can of worms or presents new challenges to us. Because I think user behavior is driven by the UI that we ship. And if we change certain aspects of the ui, we need to measure or we need to see if that's actually scaling well. So that is done by experimentation. We do a lot of experiments. If we are shipping like an ambitious change, be it infrastructure or be it a product change, we do it behind experiments. So we analyze the behavior and control and treatment and see if the treatment is actually one that is going to be permanently shipped and if we are ready from the infrastructure side to scale that behavior.

[B]

It must be devastating as a developer to work on a feature, to launch an experiment and then to decide not to ship it. Is there anything you can do to make that feel less stingy?

[C]

No, honestly, it sucks. I have been there. I have had not too many. I want to say just maybe one that was resolved to control because it just didn't move the user engagement metrics. It's very disheartening to delete that code that you have written. It's very disheartening but it is what it is.

[B]

And better that than shipping something worse for users.

[C]

Exactly, exactly. Yeah. Customer is the ultimate, you know, power.

[B]

Speaking of customers, as you grow as a company, the way, for example, Coinbase has, you pick on different kinds of customers, a lot of companies start, you know, North America or United States, perhaps even California focused, and next thing they know, they're shipping to Europe and Africa and Asia. Has that changed significantly the areas of the app you look at or the way that you deal with users or outages?

[C]

Yeah. So Coinbase is obviously global, as you know. And from my view, when it comes to just performance and reliability, we do not have the same devices across the world. Right. So when I look at performance and reliability metrics, I see so many devices and if you look at like P75 metrics and P95 metrics for these devices outside of United States, they look terrible. And you have to do improve and, you know, improve those metrics because those users are also key users of the app. And even though our user base is very like North America focused, we want to grow in those areas and make Coinbase the crypto app that everyone uses globally. So it's critical that you optimize those user experiences. I think time is money and if it's taking me six, seven seconds to do something extremely simple in an app, I'm going to just move to another app. Because there is no shortage of apps today that let you do the same thing. But if you want to build user trust, you need to make efforts to build that trust by making sure your app is actually letting the users do what they want to do. And quickly.

[B]

Let's say that you receive a bug that a user on a particular device, very common in, let's say India is experiencing slowness and you don't reproduce on your device, but you see the recording that on their device, it is very slow. What do you do to investigate or debug this?

[C]

Yeah. So at least on iOS, thanks to like network link conditioner, you can simulate the network that the user is on and try to reproduce that bug. We also have various like devices. We use a third party tool that lets you run your end to end tests on certain devices that you pick and choose. We also have an external QA team that has like a device farm. So yeah, you know, those are the things that I would typically do to investigate a certain bug. Yep.

[B]

Let's move on a little bit from performance to reliability. You mentioned user trust. Having things break or be very slow erodes that trust. How do you make sure that your app stays reliable, especially as you scale.

[C]

Yeah, there are a few things to look at. One is the load that you are putting on your infrastructure is the number one thing. There are just so many obvious problems that you can find if you start digging deep. One is just over fetching data. The patterns that I have realized don't work well with React native especially are over fetching data. Because React has this re renders and you fetch data that's not necessary. Your app keeps re rendering that causes slowness. So when you are designing your API layer or data layer, it's important to fetch just the necessary data. For example, if you are in the US and there are some UK or Europe specific compliance things that need to be fetched or shown to the user, I don't need to fetch those for a US user. If you're running experiments and I am not part of the experiment group, but the data is still being fetched. For me that's putting load on my backend services and that's totally unnecessary. And it's not always just one request, right? We are in this microservices architecture where one service calls 10 other service that calls 10 other services. So it becomes like a giant fan out and one request from client leads into like 100 downstream requests to your APIs. Right? So overfetching data is one of the biggest things. The second thing is polling. I think polling is one of my biggest pet peeves in software engineering. I think it's when used incorrectly it can cause so many issues, honestly, especially in a React native stack. So say you have polling on screen one, now you go to screen two. The polling is still active unless it's handled properly. That's how like the navigation state works in React native. So until you go back completely on the navigation stack and you don't discontinue polling, it's going to continue hitting your services all the time, which is again added API load. And third thing is I think having good guardrails like keeping a tab on. We spoke about cold start in the beginning. We have a very close tab on how many requests we make on cold start. If they regress, we make sure, okay, what is the need to fetch this data? Can this be deferred to a later time? You know there is always this battle between showing experiences quickly and then regressing another metric because you want to show certain experiences quickly. So I'm specifically talking about preloading. Lot of people like to preload data but they don't understand that there is a cost to it. You preload the data. But what if the user never goes to that screen? Now you have wasted the preloaded data, right? You need to have like strong metrics to support that. Okay, Preloading is really necessary because 99% of the users are going to go to that screen. Only load data when you are sure about it. Otherwise you should just stick to fetching data when the user goes to that screen.

[B]

We've now stumbled onto the blog post section of the Q and A. Yeah, how do you make sure that you design for the correct amount of fetching, that you don't overfetch data, as you said, or even under fetch and not have data available that you need?

[C]

I have tried to automate it a lot because I was working on this topic in 2024 and I wasn't really successful in finding a way to give that feedback to the developer when they are actually writing code. Like when they are writing, when they are trying to fetch certain data. Can I give the feedback that, hey, adding this field right now or fetching this data is going to add say like 10 requests to your API calls and that 10 requests are going to add say 40 millisecond latency to your screen. Is that acceptable? I'm still trying to find a solution for it and how we can do that, but if the feedback is not given at like development time. I think the best part is once the feature is live, that's where, you know, experiments come in. You start with a slow rollout or, you know, 1% ramp up, 2% ramp up. Observe how it's performing, how it's impacting your infrastructure, what are the number of requests, how can we optimize it and then continue the rollout of that feature? I think that's what I have been doing. The one other thing is now with AI, we actually have some AI conventions. When a dev opens a pull request, we find these patterns that are footprints. For example, I mentioned polling is a foot gun, like network cache. You know, if I see a query asking for data with every time and not using the cache, we ask the developer, the author of the pr, that, hey, why are you fetching this data every time? Can this be cached? So that's also like a way to educate the dev that, oh, this is not something that I intended to do. Maybe let me change it back to the cache policy, which is use cache data if available. If not, go and fetch the data. So these are some of the things that we could do to avoid making sure the app is reliable.

[B]

Do you recommend using something like Say relay and GraphQL the way Coinbase does to automate some of that.

[C]

Yeah, I think it definitely depends on what sort of app you are building. We use GraphQL as, you know, heavily as our data layer and it definitely has like pros and cons, like every data layer. Yeah. So it actually just depends on the use case of the app.

[B]

So what does GraphQL actually do for or give to your app?

[C]

So, as you know, like, GraphQL lets you request only the necessary data that you need. And over the years, GraphQL has evolved so much. For example, it now lets you defer certain fields that you don't need right away to render your critical UI. So the way GraphQL. Good GraphQL is structured is you have one query on a screen which fetches all the data, and then you have fragments on that query which are then passed down to your child components. And in an app like Coinbase, where we have so many screens, you can end up having a lot of child components. So all that data is fetched on the main screen. But having something like defer lets you defer the load of the data that's needed for your child components and focus on the critical data that you need to render the screen that you are on right now. So the user sees the data that they should, and then all the other rest of the data is kind of loading behind the scenes and is being suspended.

[B]

This brings up a lot of the recent developments in react suspense and being able to tie data loading to as things come in. That seems like a very kind of streamlined, easier to use system than manually setting this all up yourself.

[C]

Yes, exactly. And in addition to having that being set up seamlessly, I think it's one of my favorite loading states, honestly, like, it just looks good on the app. Like there are no giant spinners anymore. The suspense is so contextual, it looks great. It keeps the user engaged, that, yes, this is where the data is going to load, this is what's going to happen. And it also gives you so much out of the box for measuring metrics for, you know, how long did this component take? How long did this suspend for? And yeah, suspense instrumentation is something that we use at Coinbase to calculate how much time it took for a certain component to render or even a certain screen to render. Like we do calculate the total rendering time of screen using suspense instrumentation. So that's been a huge win.

[B]

Let's segue a little bit into more of the architectural features since we're already talking about them. What are some of the other cool things that you're recently excited about with React Native.

[C]

Yeah, so we just enabled new architecture and I am very excited. I think there are so many cool things happening in the new architecture. One is definitely the jsi. If you have been doing React Native for a long time, you remember how painful it was to bridge data between native and React Native. When we first started building React Native, many of the payment modules or integration with banks, they were just not available on React Native. So you had to bridge data to native, connect from the native side, get the response and bridge it back to React Native. And this communication took such a long time and I am so excited that JSI JavaScript interface is finally getting rid of that bridge. Already gotten rid of that bridge, actually. New architecture. It's going to make things so fast. And yeah, the next thing is Turbo Modules. Very excited because we don't use too many native features, but we do like, you know, cameras, then Secrets and then storage on the native side. That's going to be like, you know, speeding up very quickly on the new architecture.

[B]

So it sounds like React Native's new architecture is they're rolling out a whole bunch of new features and ways to integrate with native. What are Turbo modules within that?

[C]

Yeah, so Turbo modules are say you are interacting with camera or you are interacting with the keychain, which is very native specific. It's time consuming and it adds like a lot of load on the whole infrastructure. So Turbo models is just something. It's a way of making these native interactions faster for React Native.

[B]

And how does that come into play with apps? Is it not kind of straightforward to just open up the camera in a React Native app?

[C]

It is, but it does go through native layers. That's not something that React Native does out of the box. So we would use some dependencies like React Native, camera or having Turbo models on React Native just makes it super fast.

[B]

Let's talk about AI. AI is everywhere. What have you been up to with AI in the context of React Native?

[C]

Yeah, I mean coinbase is. Our CEO Brian just tweeted about this two days ago is we are writing more than 50% of code is AI generated. And I like it. Honestly, it's been hard to keep up with everything that's been happening with AI outside. But Coinbase is building like tools that we can use, internal tools that we can use. Like we have, we are heavily using Claude at Coinbase. We have so many like internal commands that have been built. We have agents, internal agents that have so much context of Coinbase that our day to day tasks are becoming easier and easier and we are able to ship so much code. For example, in the past I would probably be able to open one PR a day, but now I have all these agents, you know, I just give them a prompt, make a nice plan, tell them exactly what needs to be done, and then I have five PRs open and it's just massive velocity. But I do think that it's important for you to give the right context to be successful with getting the output from AI. I think that's very important.

[B]

Talking about React native, how do you set that up so that the AIs know how to deal with your say, scaled React native application?

[C]

Yeah, so we have lot of agents like conventions agents, MD files in contextual agents, MD files that if, say I'm working on a UI component, there are some things that we want the UI component to do out of the box. We want say a screen name so that we can measure some rendering metrics. We want something called as page information which tells me, okay, this is the page that the user error on. I think that's some of the context that we provide out of the box. So when I tell AI that hey, build this component for me, it knows exactly what it needs to add in my UI component that is contextual to the code base and will reduce the back and forth between a human and an agent.

[B]

Have you found that agents tend to write idiomatic React native code rather than non idiomatic or idiomatic for something else like React web?

[C]

Not really. Especially because we have so many abstractions. We spoke about design system before and the code may look similar on mobile and web. I have not experienced it writing like React web code because honestly, it may not look that different because we are using design system because we are using React. Obviously in both places similar lint rules too. So yeah.

[B]

Have you found that the lint rules are particularly helpful with AI agents? I ask because a lot of developers have reported that AI agents write code with a million squigglies and then with the lint rules they can, you know, sometimes clean it up for them.

[C]

Yeah, I think so. I have been using them a lot. Like I use AI to just say, okay, give me violations for this lint rule because people like to disable lint rules. And then I say, okay, go fix these lint rules. You do have to check the work. I still still see that, especially when it comes to like fixing lint rule violations. But some of them are super obvious. But for some you need to before

[B]

we start to wrap up, I want to circle back on something we were talking about earlier. You mentioned that oftentimes metrics fall over, let's say the course of two years. How do you set teams up for success to not create, succeed and then gradually fail at their metrics?

[C]

Yeah, so operational excellence is something that we take very seriously at Coinbase. And yeah, there is definitely that two year cycle. So we try our best to put these guardrails in place. That will not digress. I don't want to say regress, but that will not be forgotten. Two years later, they will regress for sure. That's how the nature of these metrics are. But at least someone's looking at them. So we have so much automation for operational excellence. Almost every single team at Coinbase runs their own operational excellence, where they review these metrics like they review error rates, they look at performance budgets, they look at the number of incidents that happened in the past week and try to summarize what happened and how we can prevent it. I think these learnings are so important. We also have these operational metrics bubble up to the leadership. So at org level, we look at them and everyone takes it very seriously. It's not something that you just bucket for like 20% of your time and 80% goes to feature development. This is very top of mind for every engineer at Coinbase. And even in operational excellence, we are trying to use AI as much as possible to do the heavy lifting. Where do all these queries get me all the data? Find the common themes and we find avenues to share these lessons amongst each other. Because more often than not, there are incidents that happen because of the same root cause and that is something that we want to avoid from happening. We don't want repetitive mistakes. I think new issues is something that is unavoidable, but I think we categorize wins when the same incidents don't happen two weeks later because of the same root cause. So, yeah, operational excellence is something that is very, very critical and again, a very important aspect of reliability at Coinbase and how we have been able to stay reliable in the industry.

[B]

Let's cover a horrifying hypothetical. Let's say that you're in a team that traditionally has been very stable, not that many users have used that area of the product and all of a sudden a whole bunch of users are using it. So you're getting these new bugs, you're getting slow loading times, your servers are overloaded, and leadership needs a whole bunch of new features. Features from you. What do you do in that situation?

[C]

Yeah, this is the classic panic moment, right? Like as an engineer, like do you focus on the new things or do you focus on something that's broken? I think my thought process is priority, you know, like how bad is something? I'm getting all these bugs, I'm getting all these alerts. But what's the scale of it, right? Is it impacting one user, is it impacting 10 users? If it's impacting a lot of users, we have something called as in severity metrics at Coinbase where we use that to assess how severe it is. So I think I would just add priorities to all of this and attack it from that angle. It's very important that if one user is facing this problem, yes, it is important. Also it depends on who the user is. That's also something, you know, if that user is some high net worthy individual. Yeah, it needs to be addressed like today. So I think it comes down to prioritization in the end.

[B]

That makes sense. Jiri, I've got one last set of questions for you. I'd like to end every interview with something non technical, just to cleanse the palate. What does it look like? Or what is the best part of having a photographic memory for you?

[C]

I think the best part of having photographic memory is if you are somewhere where you shouldn't be and I spot your car, I know that's you. I remember number plates of all my friends. Well, not all, but like close friends, also neighbors. And yeah, it's also a fun thing like you know, if I spot you there and I'm like, okay, this person's here, but you told me you are not here now I don't care as much. But back in the day it used to be fun.

[B]

Do you find that having this incredible memory gift is useful at all in programming or your day to day job?

[C]

It used to be now with AI you don't need it as much. But sometimes, yes, like I tell my teammate, I have seen this somewhere on Slack and I try to quickly go find that because I just know where it was, which channel, who said it. And it helps in remembering like names of people to go back to because I've just. I remember their picture, I remember their name and it's like a photo in my mind. So yeah, it helps to find people. Back in the day it used to help me because I used to remember all like the database connections and port numbers and whatnot. But now we don't do that kind of thing. Maybe I'm too old now, but yeah, that's just. But it does help in many ways.

[B]

Yeah, that's so cool. Well, great. Thank you so much, Marjorie, for coming on. We talked about React Native, the trade offs, when to use a performance, reliability, scaling, architecture, solutions, kind of team practices around it. Last few questions on that. If you wanted to get started anew as a React Native developer, where would you go?

[C]

Honestly, now that we have so much AI stuff other than React native websites, just take help from AI, have them build that Greenfield app for you and ask the questions right in your prompts. And I think it's the best way. I think if you're starting as a new React native engineer, I think AI is a great friend to have. I wish I had it back then because I could ask AI dumb questions and not get judged, but unfortunately I didn't have AI back then.

[B]

It is nice to be able to ask dumb questions and not get judged. Not everyone can support that on either side.

[C]

Exactly. Yeah.

[B]

Well, great. There's AI, there's reactnative.dev. a lot of great resources out there for this technology. And about you. Let's say someone wanted to find out more about you or the work you've done at Coinbase. Where do you direct them? On the Internet?

[C]

Yeah, LinkedIn is the best way to get hold of me.

[B]

This has all been a lot of fantastic info. Manjiri, thank you so much for talking us through React data. This has been really wonderful for Software Engineering Daily. This has been Josh and Manjiri. Thanks for listening, everyone. Cheers.

[C]

Thank you for having me.