0

From Google Analytics to Universal Deploy Schematics | James Daniels

James Daniels

9/1/20 at

Angular
English

New Angular 9 and AngularFire features! Learn about some of the new features in AngularFire and how the Firebase team leveraged dynamic imports, ES Proxies, and new features in Angular 9 to build a more streamlined SDK.
Watch all the ng-conf: Hardwired presentations/videos at https://videos.ng-conf.org
ng-conf is a three-day Angular conference focused on delivering the highest quality training in the Angular JavaScript framework. 1500+ developers from across the globe converge on Salt Lake City, UT every year to attend talks and workshops by the Angular team and community experts.
ng-conf: Hardwired is brought to you by: - https://thinkster.io/ - https://herodevs.com/ - https://xlts.dev/
Follow us on twitter https://twitter.com/ngconf Official Website: https://www.ng-conf.org/

Transcript

Everyone, I'm James Daniels Fimian, Twitter, James Urijah, and I'm a developer programs engineer at Google and I work on the firebase. Well, you may know me from such great hits as Angie. Twenty nineteen and twenty eighteen. I've been talking about fire base and fire for a little bit now, one of the most common speakers for the team. But I have to say, let's just look back, cover a little bit of ground on what firebases, what problems we're trying to solve, and then I'll walk you through some of the things that we've been doing. So Firebase is Google's application development platform, right? We are the tools made for you to develop an application quickly to get to market faster and build better applications. Ultimately, our mission is to have help app developers succeed. Right. We want to shipping those applications and we want to increase that time. The market two million apps use us. I don't know which one of these, if any of them are using angular, these are the ones that prove to be on the slide. But two million marks are using us right now. And I'm sure some of these people are using angular behind the scenes. So the problems that we solve, right, is really focused on the developer cycle development cycle. So let's first you develop your application, right? You need authentication. You need to store data. You need to have computing. You need to respond to events. And you need to test your applications. We have a bunch of tools around this first part of the developer and especially angular developers and people who have used Firebase on the Web. These are the tools that you are most familiar with. Now, Firebase has a lot more tools, right? So we have tools around running your application release management analytics and crash reporting. And we also have tools around engaging. We have messaging, personalization and experimentation. So ultimately, we have tools around this entire app lifecycle and we're supported on multiple platforms. Right. iOS, Android Web, C++ and of course, everyone here. Right. Presumably Rangeela developers mostly. So you're very much focused on this Web piece. And as I touched on before, in the past, a lot of our tools are geared towards solving the problems for iOS and Android developers web. We had a lot of tools back from the startup days, but not much in terms of new development since the acquisition by all of us change. So since I spoke at last and Firebase has been launching a lot of its features for the Web, we have remote configuration. We have the Google Analytics, integration, performance monitoring. We now have emulators for a lot of our tools and much, much more. And really key to this right was this Google Analytics piece. We rely for performance monitoring, remote config and a lot of our features on this Google Analytics piece. And finally, Google Analytics for Firebase for Web is now a thing which is really unblocked, bringing a lot more of our platform to Web developers. So how does this affect you and how does it affect me beyond my being an employee of Google? I'm also the maintainer of. Right. So announcing today we just released the first six, a stable version of Angelfire where we support Angular nine Ivy and some of the cool stuff. But you can find us on GitHub here and there. And that's where most of you are going to be familiar with the fire maintainer and Angourie Fire is extensions to the JSF. We wrap adding more angular features. Right. The FIREBASE SDK is meant for any platform. It's agnostic and ultimately angular. Fire's job is to make the firebase just a little bit more seamless and angular. And I'll jump in on some code and show you around a little bit in a few minutes. But what I really want to talk about today is how we can use the deep Google Analytics integration with the angular. Rather, this is a new feature of angular fire. I want to show you how you can alter the behavior of your application without having to redeploy your application with Firebase from a configuration. Right. We're going to show our universal deployments. And I'm going to touch on how we're achieving some of our new lightweight, lazy living models, so let's go ahead and jump into the cold. And, of course, this comes with the standard caveat. So I'm going to be coding. So things happen. Right. But let's pray to the Democrats are going. Let's go ahead and jump over, so here I just have a very, very simple shell application running on localhost, very simple. I've actually spun it up here to this started. Would have helped if I got that going before talking, but it's going to do its thing and showing us the code base, I have my module. I brought in a couple of things already from regular fire just to save a little bit of time. But this is the main thing. I brought in the angular fire module. I initialize the application with our firebase credentials. Let's go ahead and see if that's now running. That's religious. All right. Looks good. I brought in a couple of other things. This is the sample application I used to work on angular fire. I have a test of the database of fire store and I left a remote configuration blank. So I will add analytics to this and then we'll play around with the remote config. So adding analytics, I first brought in the angular analytics. This is going to be the angular fire wrapper for interacting with Firebase Analytics. We now have a number of services, so namely the screen tracking service by simply including Angola fire module initializing, bringing in fire analytics and now the screen tracking service. Our application, well, lazy load geotag. And a little hook into the angular read or listen to the events and start transmitting those back to Firebase, we also have a user tracking service. So if you're using firebase authentication, whenever a user logs in, it'll actually start logging there. Do you ID into Google Analytics? So we that. There we go. And now let's show you a little bit what the analytics experience looks like. So since it takes a while to stream the data and I actually grab one of my other applications, it has had data streaming in here for a while. This is on Snapchat. This is the application I built for the cold labs. At last, Jake and I actually updated it and brought in these new modules. So here's the Google Analytics experience. What we see here, we actually have a number of events. We have users logging into the system and we can filter on some of the parameters here. And of course, the counsel for us that we can actually see, I'm automatically logging the climate out here, so I'm actually tracking. So if you have multiple outlets on the page, when you render things and them, you'll actually get those transmitted and you can actually see the screen class as well as a screen name going to be transmitted. So you can see this is actually based off the name. And this is actually the the module getting loaded into the ropes so you can see where your usage is. There's a lot of really cool data in here and you can filter down on things, right? You can filter by platform audiences, stuff like that. But this really isn't Google Analytics lesson. I just want to show you that by just adding those modules, we're getting some really cool integrations with the angular router here. And it's developed in such a way, too, that when you're in production mode, you're still going to get really good naming and stuff like that. Whereas that's that's a hard problem, because when you deploy the production mode, things get tangled a lot. So we all set up performance monitoring. So by simply bringing in angular fire performance module, we then get statistics on our performance of our application. So we're going to get all network requests by default, first content, ful paint, stuff like that, so we can actually dive in on Trace's. I can see that local house is performing a little bit faster than the production side. Should probably figure out why that is. And then I have a number of Trace's and I'll touch on Trace's in a second and show you how to put a trace into. Finally, I can look at the network that I can see all the API is getting called by default is based on a domain name. I can actually create custom. They are all patterns to look at that further, but I can go ahead and jump in and look at how often Google tag manager, how quickly the response time is, stuff like that. And great thing about all this data is if there's something here in the console that we don't provide for you all of this, you can type it out a big query and do more advanced query. So that's that console experience. Now let's look at remote configuration, so a remote configuration is highly scalable service for basically delivering JSON payloads with variants to clients. So I have here what I can update that I can add more parameters. And the idea here is, if this is configuration, I can say background color. Right, and I could consume you somewhere in my application, I could then put variants on this right. I could vary by country region. I could vary by audience and which is a Google analytics audience and a lot of other powerful things. Let's go ahead and publish these changes. Let's go ahead and play around with. The remote config, so here I have a module, just remote config modules and some playing around with it, and I brought in a remote config via dependency injection. And this is one of the best things that gives you is is this going to actually have a dependency injection? Things are going to work a lot better than Mangler since. So I can go here and I can go remote config changes and I can async pipe that I can do Jassal because remote config changes if you see the autocomplete here. Is actually an observable remote config parameters. So when I say that it goes back to my application, I can actually see we have this year, we're actually fetching the value what Kiyo what time it fetched? I refresh it. We got that. Now, you notice I refreshed the page and I'm not getting new values. This is highly scalable service and actually has a lot of cash. And you've been with me for a second. I'm going to reset. Alex. And I fast forward in time a little bit here, I'm actually constructing a new observable and I'm actually tracing it. So now I'll actually be able to tell how quick it takes to get a response back from the server and then further what I've done in my app module as I jumped ahead a little bit and added a little bit more configuration. These are all the dependency injection tokens from fire. And these allow me to configure things, namely remote config. I can actually tell it that if I'm in dev mode, you reduce the caching time and that's going to make it so that I can see those much, much faster and local development and then let our production version be more scale. So now when I refresh this. And then to restart. We should now see changes. This is one of those demo risks that don't work as an. So. Back here. So one of the things that I've actually done here is this is it up, up, up on the Web. I'm actually hosting this on Firebase and there's a little trick here. If I actually go and I this. You can actually see that it has a bunch of data on it, the images there, we actually have our database content. So this is actually hosted on cloud functions, Google cloud functions and firebase hosting, and this is using our new deploy script. So now when we do and deploy, this will actually, if it's an angular universal application, spin up the resources on cloud functions as well. And we also have a cool option of engie deploy previa where it'll actually spin up the local emulators so you can actually see the application that you're about to deploy before you deploy it. Yeah, so that's a little bit of what's new. Let me jump back to the slides here. So I mentioned the lightweight and loaded modules. It didn't seem like I had to juggle much, basically the way we handle the lazy loading of the Firebase SDK behind the scenes, if you use the firebase SDK before, one of its problems is that it's a rather large kind of legacy styled library. This is one of the things that we're working on. Right. We're working to make it more modular and more capable, but it's sort of in that prototypical inheritance pattern. So when you pull in, say, authentication, you're getting all the different methods. So to make a better experience for your end users, we're actually lazy loading that. So we're using three technologies to really achieve this. First and foremost, we're doing dynamic importing of those states. We're then isolating the side effects by running that outside of the angular zone. And then we have an S proxy, which then handles all the promises and its chains. And we'll actually jump back into the angular zone when there is something to and from the user account. So I'll actually show you a little bit of a simplified version of the proxy itself. So first, we're creating a proxy and we have this jacket, which is going to allow us to get properties or functions out of it. So first we jump outside the angular zone. Then I take whatever SDK we're dynamically importing and I actually look to see if it has the property that we're asking for already on the SDK. So this would be something like then or catch something around promises or that dynamic import. So if you just want to get a that's a promise and you call them or you call a wait, then this year we'll just return the SDK import as a promise. Next, at the very bottom, we have this proxy object, so here we're seeing just an empty function because we already have the import, so the empty function allows us to get the plasma. So, again, if there's a gift and there's a property on there, then it's catch to string, what be it? And it's already on the promise to return it. Otherwise, we're going to use apply and we get apply because we're passing a function and that is going to be any function call. Right. So if it's a function call on the SDK, say you're dynamically importing Firebase and then you call off Dot Sinon. Then what we're going to do is jump onto that promise, we're going to resolve the promise. And then we're going to take whatever property you asked for or function, and once the promise resolves, return its arms and will act as effectively does for us is all the methods promised to fight and all of the dynamic importing is hidden away from the user. The real magic here is that promise, right, so we take an observable of the important, we turn into a promise and then if it's a function, we just bind it and return it. If it's a promise, then what we do is we resolve it, then we jump back into the zone and run it. And if it's just a prop., we jump back into the angular zone and just return that property, so this little proxy, it's very confusing, took me a while to get this right. But this is a really powerful have a lot of guns, too. But basically what I've done here is taking the dynamic import and hiding it away from you, the developer. You don't have to worry about any of it. So how does this look consuming this? So this is how it looks. You just import angular fire authentication. And we have an interesting login function that just causes this of pop up. And we have a logout out this sign out, if it was already a promise, it's still a promise, right? So it makes the API so that you don't have to worry about any of this lazy loading loading behind the scenes, any of that and. Whenever you call one of those methods, it's going to start importing that SDK, so it is really, truly the same goes with performance monitoring and analytics, right. So you're not actually going to have the analytics library interfering with your time to first paint or your zone stability that's going to go off to the side. And once that's loaded, it's going to start sending data to Google Analytics. But now Google Analytics is completely asynchronous and off of that critical path. I want to give some shout outs to a couple of things that I didn't have much time to talk about, the new version of TypeScript gave us a lot of these capabilities. We're now using energy packager, which is solving our angular package format stuff for us. It's really great. I don't have to have a very, very complicated build script. And we have provided in any what is provided in any. So basically this is an isolated service for every injector. So whenever you pull in one of the firebase case, it's isolated from the rest and you don't have to worry about conflicts. This is allowing for a cleaner separation of concerns between modules and SDK for us personally. The thing that it really brings to the table is say you're using Google analytics or performance monitoring and you're an SDK or your module. This is a common thing. This really makes multi tendency and angular fire a lot cleaner if you want to learn more about it in any person actually has a really good article on this. I'd recommend checking it out, goes into great detail and compares it to the other types of dependency injection. Just recently, the firebase console also migrated to ANGULAR nine. So today we're benefiting from lazy loading some great improvements there and you have the consoles a little big. The packages are a little big, but there's a lot more work to do to slow things down. But we're confident that we can do that work now that we're on ANGULAR and that team has our back, is giving us the great tools that we need to really increase the performance of the console. And finally, huge shout out to the angular community, right, and the angular community. We have a lot of awesome contributors. I think we're up to one hundred twenty contributors now, friendly fire. And, you know, everyone in that community makes my life a lot easier. Right. So if you're interested in these new capabilities, go ahead and add your fire that will prompt you three set things up if you're a universal application and I'll give you those deployment schematics and some really cool things. Thank you very much. It was great chatting with you today. I wish that we are all in Salt Lake City and I could interact with people face to face. I could, you know, go grab drinks with some of our contributors, but unfortunately is stressful times. And hopefully everyone here is healthy and stable jobs and it's going to weather this storm. But thanks for having.

Newsletter

Receive the most recent recordings from meetups and conferences in your inbox monthly

About MeetupFeed

MeetupFeed collects and organizes recordings from tech meetups and conferences. Follow your global community!

Disclaimer: This site is not associated, affiliated, endorsed, or sponsored by Meetup.com. None of the videos are our own.