3 Places Firebase Breaks Your Next.js UX (Auth, Firestore, Remote Config) | Rosário Fernandes

This talk covers the integration of Firebase tools for improving web app performance, specifically focusing on React server components. The speaker discusses Firebase features like authentication, Firestore databases, and remote config, which can enhance user experience by reducing UI flickering. They explain how to initialize Firebase server components to ensure users are authenticated on the first page load, minimizing client-side delays. The talk highlights the importance of server-side JSON serialization to manage database records and real-time updates without noticeable flickers. Additionally, the introduction of Firebase app hosting for server-side rendered apps and a new SQL database called SQL Connect is mentioned, along with plans for Crashlytics for the web.

Hi, I'm Rosario. I work on the Firebase developer relations team. Uh I'll just like to preface this talk with uh the fact that this talk was actually put together by my colleague James Daniels and he's the real React expert. I'm actually an Android developer, but because he couldn't make it to the conference, I decided to stand in for him. So, if I say something wrong about React,

forgive me. It's just my Android background kicking in. So, if you don't know Firebase, Firebase is a platform with a lots of with lots of developer tools uh that can help you build your apps. So, we have things like databases, authentication system, uh remote config for things like feature flagging or AB testing. we offer those services as client-side SDKs for your app. So, you you write it

in in JS uh for for the web or like in Android, you write it in Kotlin or in iOS with Swift. But, what's the problem with client-side? The problem with client-side is that it all runs in the browser. But, if you're a React developer, you might have React server components which run on the server. And the problem with that is is the flow for the user is

going to be a little bit flickering as in like if your server is sending the first uh HTML, it might send a sign-in state where you have a sign-in button. And then, the client-side figures out that oh, this user is actually already authenticated. So, let's update the UI and then there's a tiny flicker there to show that the user is authenticated. You might have seen this in

your own apps or in other apps. I've definitely seen it a lot. Um and then the UI flashes and then it's like oh, you're actually logged in and that's it. So, how How you fix that with Firebase? If you're using Firebase authentication, we actually have a new uh I say new, but it's actually been released a couple of years ago uh class called Firebase server app. So,

you can actually initialize Firebase in your server and then get all the authentication contacts for that app and then use that to send to the client so that the client already knows that these users are authenticated right on the first load of the page. They don't have to wait uh for the client side to kick in to be to be able to tell uh these users, "Oh,

you're authenticated, so you don't need the the sign-in button." And authentication is just the first part of the story because you also have databases and one of our database is called Firestore. And Firestore has some really cool features, but that can make this process a bit trickier. One is the offline component of it. So, it has uh by default an offline cache. And so, if the user

loads the page and then the database records are coming later and then the the they pull the the records from the cache first and then the the records from the server coming next, that means there's there's like one more flicker going on there. And then another feature that Firestore has is server-side uh sorry, it's real-time updates. So, you might have a second flicker because now the the

real-time component kicked in and there's more records to display. Uh and so, as you can imagine, this is this is like a total of like three flickers that the user has to wait for uh before they see the full page. How do you fix this? Uh two main components. Uh there's a function in the server-side SDKs uh that is called to JSON so that you can serialize

all the data. You can basically run a first query on the server side, serialize all the data, and then send it to the client. And then the client has a function called on snapshot resume, which is going to take that serialized data and just resume for there, which means if there's real-time updates being done to that app, it's not going to invalidate the the previous ones if

it's not needed. And then for things like offline cache, it's also try try to merge all those results so that the user doesn't really see a flicker, but rather just an addition of new data or records being added in real time. So, like I said, the way it works is that on the server you'd call to JSON, and then on the client you just pass those serialized

snapshots and render them. The third part of this is remote config. So, remote config is used for things like feature flagging or AB testing, and we actually recently released remote config for the server. So, you can also use it with server components. You can on on the server fetch all the values, and then on you can use it to whether or not display the new UI or

old UI if you're doing like feature flagging or something like that. And you don't have to wait for the client to to figure out all the changes for the user. Just a look ahead where we're going with this or like I think you probably already see a pattern with this. It's this just mostly a way of us showing you how we're trying to adapt to the modern

web, and one of the ways we're doing that is with for example, we have a new tool called Firebase app hosting that allows you to deploy your Next.js or your Angular apps with server-side rendering to to to Firebase. And under the hood it uses products like Cloud Run, so you you you're you're probably already familiar with some of the infrastructure that it uses to deploy these things.

We also have a new database that is called SQL Connect. If I spoke to a lot of you this morning during at the booth and it sounds like a lot of developers have used Firestore, which is our NoSQL database, but the good news is we we also have a SQL database now. It's called SQL Connect and that's the case for the web. They actually use TanStack Query.

So it's starting to use the patterns that you're already familiar with or for the modern web. And very soon we're going to have Crashlytics for the web. is our crash reporting tool so that whenever your users face some crashes, you can see it on a centralized dashboard. For a very long time we've had it for Android and iOS, but now we're bringing it to the web. And

it's actually going to start an early access program really soon. So if you're interested in trying that out If you're interested in being one of the early testers for this this new tool, please scan the QR code and you'll find the form that you can fill to to get access to it. And that's it. Thank you so much for listening. If you have more questions, I'm going

to be at the Firebase booth outside and happy to answer any questions. Thank you. >> [applause] [music]