Video Feed
Angular: Apps with Scully | Jennifer Wadella & Sam Vloeberghs

0
Angular
02.17.2021

English

Jennifer Wadella & Sam Vloeberghs

Welcome to NG-BE Live Episode 4 with:
SPEAKERS: - Jennifer Wadella—I Want to Believe: Making Angular Apps More Performant with Scully - Sam Vloeberghs—3 things you didn't know about Scully
PANELISTS: - Yannick Houbrix
HOSTS: - Sam Vloeberghs - Jurgen Van de Moere
— I WANT TO BELIEVE: MAKING ANGULAR APPS MORE PERFORMANT WITH SCULLY Jennifer Wadella
If you’re looking for ways to improve performance of your Angular applications, look no further than Scully.
Scully is the JAMstack tool the Angular community has been craving to make pre-rendering and serving static pages a breeze, with a great supporting community and a variety of plugins to meet any application setups needs.
In this talk, Jennifer teaches us about JAMstack concepts and how to get started with Scully to make your Angular applications more performant today.
— 3 THINGS YOU DIDN'T KNOW ABOUT SCULLY
Scully is still a new kid on the block!
In this talk, Sam highlights 3 things you (might) not know yet about Scully!
— LINKS
- Jennifer Wadella: https://twitter.com/likeOMGitsFEDAY - Sam Vloeberghs: https://twitter.com/samvloeberghs - Scully: https://scully.io - Angular: https://angular.io
- NG-BE Website: https://ng-be.org - NG-BE Twitter: https://twitter.com/ngbeconf

Transcript

Hey, everyone, welcome to the fourth episode of NCB Life. In this episode, we have Jennifer Awadallah and some Flobots who will teach us everything we need to know to get started with Skully and create a wickedly fast, static, angular websites. Welcome, Jennifer and Sam. But before we dove in and let's meet our panelists for today, we have Bonnie Brennan. We have Martin Thibeault and Yanique Briggs. Welcome, Bonnie Martin and Yanique. It's good to be here. All right, all right. Yeah, good to have you. Welcome, Bonnie, and welcome Martin and Nick as well. All right. So our first guest, Jennifer Awadallah, has been writing code since before she realized it was actually a credible career path. She currently works as the director of Angular Development at Towfighi, is an angular DJ and loves building performant applications. She loves speaking at technical conferences and brewing kombucha. How cool is that? Jennifer is an active member of the Kansas City Tech community and a founder of the Kansas City Women in Technology, an organization aimed at growing the number of women in technology in Kansas City. That's super awesome. She is the Sydney Twenty Champion, the Silicon Prairie Champion Award nominee, rising trendsetter, Emmy Award winner, and is apparently Missouri's coolest woman, according to Pew. Wow. All right. That's super cool. We also believe you're Missouri's coolest woman for being here. Jennifer, in today's talk, Jennifer will teach us about gems that concepts and how to get started with Skully. Jennifer has agreed to taking questions after her talk. So if you have any questions, please don't hesitate to submit them into chat on the YouTube page and we'll make sure to pick them up from there and ask them to. Jennifer, if you like what you hear, please also make sure to leave some claps in that chat while you're there as well. One small disclaimer, Jennifer warned us that her connection may not be ideal and may be a bit flaky. So let's be forgiving about that. As you know, this show is completely life. So if something goes wrong, we'll make the best of it together. Obstacles only make us stronger with that. Please give it up for Jennifer Waddell. Thanks so much for having me. We need we need a real applause track in here that would really make it sound like a real life conference. Again, I know we're all missing those pretty badly, but I'm excited to be here with you all today and talking about Skully. So quick check screen coming through, OK? Yes, awesome, cool. So Internet connection story, I'm in Aruba right now because of international travel bans causing problems with my personal life. But if I was home in Missouri, they're actually rolling blackouts because of snowstorms and because our power grid across the Midwest of the United States literally can't keep up. So, honestly, I'm probably on the more stable Internet connection right now of all possible scenarios in my life. So, yeah, we'll just have to see how things go. And then if we lose connection or anything like that, happy to circle back and say things in the chat, but getting started. Want to be talking about making iller apps more performant with Scully. If you are not familiar, you don't understand where Scully comes from. I would definitely encourage you to check out Netflix on any of your Internet entertainment providers. Definitely one of those quality shows that that came out of my childhood that that is how old I am. But fun to know where the name comes from. Now, I want to start off this talk by kind of talking about the state of the Internet. And I really love this quote by Alexis Ohanian. If you don't know who he is, he's the co-founder of Reddit and the author of a book called Without Their Permission, which is actually one of my favorite books. I feel like it's really inspirational for all of us in the webspace as well as humanity as a whole. So if you ever getting down from being in or dealing with this pandemic, I would really encourage you to pick up this book and give it a read, because I feel like it's just a great outlook on humanity and all things provided by the Internet. But he has this quote, When all links are created equal, your eyes can simply with your ideas can simply win because people like them. The future of innovation will be made, not managed in a big promise of this book is the Internet makes all things possible. And so literally all we are competing against with each other is how good our ideas are and how easily we are able to get our ideas to other people. And I feel like this really plays into the Web products that we create because you could be the best developer in the world. You could have the best idea in the world. But if you're not getting it out onto onto the Internet in a way that people can discover your idea and discover how truly amazing it is, you're doing a lot of work for nothing. And so that kind of brings us into this idea of modern web development. First of all, we have an idea. We create some code around it. That's awesome. The next thing we need to do for that idea to be successful is to help people actually find our idea courtesy of Google. We have a way for people to find our ideas. And the common term for this is our search engine optimization, where you get people to your site based on different things that you're doing and then finally making people love your idea in this ties in to perform it. So obviously, if you have a great application, but the performance isn't fantastic. Once people are there, people are not as likely to love your idea simply because it's not as useful. So this brings us into Jim Stack and this. We can achieve these different things, these different goals, making sure that we're getting our great ideas out to the Web through Jim Stack. And so this stands for JavaScript, which is our application functionality. This is our angular piece of our idea that we've created APIs, which are server side interactions, how we're interacting with data, whether that's passing data from a user or delivering data for that that user to consume in markup. And this is the trick here, the statically served files. So GM stacks approaches to use all these things. But when it comes to actually delivering that content to our end user, they're going to be just statically served HTML files that we then populate with whatever JavaScript functionality necessary that we're used to from a single page application development standpoint. So when we talk about the term Jamm stack, which you'll see a lot in the Skully world, that's what James Stack means. So our Jim Stack or Jim set goals, I should say as a whole, are to provide better application performance. Part of this is that initial performance, that initial page load, once you know something is is delivered and in front of a user, can they see it perform quickly, easier scaling, making sure that the way we're rolling out our applications can be easily scaled to the masses across different CDMs, all sorts of things. They're making sure that we're improving a developer experience by building tools that developers can easily use and implement that aren't going to detract from their application workflow, making sure or trying to wherever we can provide heightened security. And so these are kind of the basic Jim Stack philosophies, I would say. So if you're if you're new to the space, you're not really understanding what we're trying to do here. What we're trying to accomplish with this is what Jim Steck set this concept set out in mind to create. So when we bring this back, looking at it through an angular lens, what is what is success look like for us? We want to make sure that we have improved search ability of our competitors. So this is a big part of performance and making sure that we're able to deliver files faster to the browser to boost our performance results. We want to make sure that we're delighting our users with really great performance of our application once running. And this is going to make our businesses basically be able to benefit immediately. I like to talk about this in business concerns because. When you're a developer at a company, you may be in the position where they don't really care about performance, but they do care about dollars. And so if you think Scully could be a good toolset that your company could use to improve performance of your application, I want you to be thinking about it in business terms and say, OK, if we were to take the time to invest in this tool and implement this, we are going to benefit because users will be able to more quickly reach our application, will be having improved search rankings. And this leads to increase in revenue because people can access our product better. So when Scully, where Scully fits into the puzzle is Scully is a gem sack toolchain for angular developers, so Gatsby, I really feel like helped put Jim Stack on the map. It's a react based approach to Jim Stack. And so if you've ever done that, dealt with that, you know how they've solved so many problems for you for delivering more performant Web pages where you're not really having to do a lot there. And so Scully is the angular driven approach to Jim Stack. So we I have a demo app and we're going to be kind of talking through some of this code that I have set up for you all. So if you would like to follow along, the top link is where the Web app is hosted live. And then I do have a GitHub repo that is available here. I've got a main branch that's going to have kind of like the base app code. And then there's a skully branch that's containing, containing all the different things that we're going to do. So you can take that away in your back pocket if you want to refer back to this when you decide to go on your own skully adventure. So what we're going to be doing for the purpose of this talk are we're going to work on, first of all, improving performance by pre rendering all our application pages. So what we want to do is we want to be serving static pages with all our content basically there and ready to go. And we can hydrate our angular application in the background. So a user has that first initial boost and understanding of what's going on. We'll talk through some of the metrics that search engines look at and how doing this gets you higher on that ranking. We're going to talk about continuing to improve by adding custom metadata tags to our pages. This may or may not be something you're aware of that already makes it possible for us. So we're going to kind of look at how we utilize that and what that actually does and then find. Performance by caching API calls that we know are necessary for the application, but may not necessarily contain data that changes very often. So what are some strategies around caching that we can use? So let's talk about goal number one, which is pre rendering our application pages. And so what I want to do is I kind of want to show you this little sample application that I have. So it's this silly field guide. I don't know about you all, but with the start of the pandemic last year, I got really into animal crossing New Horizons. And so I decided it would be fun to build this field guide. There's actually somebody who's created a third party API that I'm using. So if you're ever curious or want to do your own animal crossing development, there actually is an API. And so that is what I am using to populate the data in this app. So pretty, pretty basic read app where I've got a villager's page. This is going to list all three hundred ninety one villagers' I think there are in Animal Crossing, so you can kind of see who they are, what their species is. And then if you want to click through to a specific villager and get more information about them, you can see that on the page. So fairly common structure that we're used to dealing with where we've got a route and then we've got an idea or parameter where we're using that information to make a request to get more specific information about something. We're really going to be just looking at the villagers part of this application. But the fish, the insects and the fossils are all operating in the exact same way. If you are digging through this app or how to run things and these are the lowest prices for these different fish. So if you're ever wondering about that, trying to populate with fun information. So that's kind of the context of the app I'm going to be talking about and what we're going to be doing, so high level goals with this, let's say this was a real world scenario where we were providing a service to a user. And we know that that user would navigate to our website by maybe searching for one of these animal crossing villagers, maybe by their name or something like that. Our goal would be to have our pages for information about this animal crossing. Villager rank higher, get ranked higher by Google so it'll be higher up in search results. And a big part that plays into that is how good our keywords and titles and tags are. But another big part of that is our application performance. How quickly will our our page actually be served for for the color to look at just a little more context there. So the first thing we want to do is we want to go ahead and start using Skully. And so this is as simple as doing an ad scali slash in it. There are schematics already populated. And so the great thing is this is going to take care of your NPM install where you're actually getting the package, but this is then going to make some modifications to your route at module. I'm just going to go ahead and it's going to import this Scali live module for you and handle all of that. So really glad to see a project taking care of angular schematics and just saving us that many more keystrokes. So after that install, what we need to do is we need to kind of take a look, take a look at the current status of our app. The way Skully works is it's going to look for our router. It's going to look for all the different routes that are used for our application and use that to figure out what pages that they need to go through and pre rendered. So then we can serve those those preset pages from a CDN. So I know that I've talked to people before who've started using Skully and they kind of lucked into it in there, like, oh, well, it's just not working. Well, they didn't have a router defined and so there was nothing for Skully to do because it didn't know what pages it was going to render. So just conceptually have that understanding's. In the case of my application, my roots are going to look something like this where like I showed you in the application, I'm going to have a path of Villagers' that's going to render a component, that's going to be a list of all my Villagers'. And then I'm going to have another path that's going to be Villagers' and then take a parameter ID and then it's going to use that ID to make a request to get the villager from the API and then it's going to load that in my Pillager component. So this is a fairly standard pattern that we see in angular development where I've got a component in here. I am just getting those programs from the pipe. I'm making my request to my service that I've set up that's going to be making that to be recall and then making that call based on the ID. So looks a little bit like that. All right, so what we need to do next is we need to run the build command of our application because what's really is going to do is it's going to when we run it, it's going to look in our build folder. It's going to figure out what our routes are for the application, and then it's going to boot up puppeteer and then it's going to basically start hitting all these different routes, scraping the page and then dumping them somewhere for us. So I feel like this is just on a conceptual level. You need to know the order of operations of which Sculley is doing things. So that way, if you're ever troubleshooting or trying to figure out what's going on, you're aware of that. So a common scenario that somebody might run into is they run energy build and they run Skully and nothing happens. Well, you need to be aware that Skully, by default, is going to look into the disk folder where Angular is preset to configure your files. If you have a custom setup where you're not compiling into the disk directorate, you're going to need to modify Skully accordingly. So that's how that hook up works. So once we have built, that means we're going to have all our files available in our district right here inside of our app name, unless you have some sort of custom config, that's what Skully is going to boot up and puppeteer and start crawling through. So when we run Skully, it's going to do a series of things. It's going to start a puppeteer looking at all those different pages. It's going to be assessing our roots to try and figure out what's going on. And then it's going to start generating our static pages. I'm not going to run this where you live because my application has at least three hundred ninety one roots that would render and that does take a chunk of time. So I'm going to show you the output is going to look something like this the first time you run it, where it's going to give you this file it's creating called Skully JSON. That is literally going to list out all the different maps that is found. And so when I run this command initially, this is without me having done any custom configuration. So this is just Skully out of the box, what it's running against based on the config. So you'll notice some output in my my console here and it's going to say, OK, no configuration for root villager slash ID. So this means when Skully has gone in it's looked at my roots and said, hey, OK, I see that there's a param here, but I don't know how to render this page because I know that it's dynamic and dependent on that. So that's kind of what this output means. And it's going to say that for anything that you haven't defined and then for all the pages that it is able to create, it's going to go ahead and put those into the disk directorate under a static folder. So if we want to then serve what Skully has created, we can run and run Skully serve and this is going to do something pretty cool in my opinion, it's going to create two different servers. The first one is the normal angular build. So whatever your angular build looks like, especially if you run against the pride flag for minified code, it will be solved. Served at eighteen sixty for your static Scully builds. So the static files that puppeteer has scanned and slowly has packaged up and created are going to be served at sixteen sixty eight. So you can literally sit here and compare these two side by side and continue to figure out what you need to do to improve your performance and tweak from your static site serving. So let's cycle back to the root configuration and kind of look at what's going on there, so we need to figure out a way to tell Schily, hey, all right, we know we want to render a page for every one of our three hundred ninety one villages. How are we going to do that? So the first thing we're going to do is we're going to take advantage of these Scali plug in system. So Skully has a lot of default plug ins built in. I think they've actually added an immense amount since I last gave this talk. But these are going to be ways to allow you to provide specific instructions or configurations. There are three different types of plug ins that we deal with. We've got a router plug in, a render type of plug in and a file handle type of plug in and just to get a whole bunch of utility plug ins. So for the purpose of what we're we're going to do to render out these different villager pages, we're going to start in our default config is going to look a little something like this where we're pointing to our project route. We've got our project name, our output directory, wherever we're going to be compiling these static files to. And then we've got this route's object that is going to start to take the different routes that we want to provide instructions for. So around config interface looks something like this. I found it really helpful to just like always have the skully reflection on my local machine so I can quickly look at interfaces in case sometimes like docs get out of sync or anything like that to have a good understanding and be able to quickly assess what exactly is expected and what I need to do for what I'm creating a custom plugin. So for my plug in, what I'm going to do is I'm going to use the already provided JSON plugin, which is made available. And so what this is going to do is it's going to take an endpoint essentially. And what it's going to do is it's going to make a call that end point and then it is going to return, in this case, an array. So what I care about is I care about if I've got this massive array of villagers' in each one of them has an ID, I want to fetch all the IDs and then those are going to get past Tiscali. So I can say, oh OK, render villager one village to village or three and so is that's booting up in the application. Then as those pages are built Skully is able to see, OK, this is what this information should look like. Let's scrape that, let's slap it in a folder and we'll be good to go. So you can these are the two required pieces. The property is whatever you want to iterate on this. API is a little weird where they have everything in objects instead of just just returning an array. And so there is a result handler that will take whatever the response of this is and allow you to manipulate this. So in this case, I wanted to basically just pull the values out. So this is provided by to you, by Skully out of the box as a way to do this dynamic routing. So what that's going to look like is after I've learned that my application, if we look at our disk directories as far as what Skully is compiling, I'm going to have this villager's folder. And then for every ID that was found at that point, it's going to go ahead and it's going to render that villager that ID name. And then in here it's going to drop that in a folder and it's got an indexed HTML file that is going to be scraped and contain all the content that would have been displaying there. So a little bit of what's going on under the hood there. Again, a ton of community plug ins and the use of are getting updated all the time. So I'd encourage you to get really familiar with the Schily website and kind of checking and see what's available, because the community has been really, really great about creating plug ins and pools for developers. So now that we've statically rendered all our pages, let's move on to goal number two. And this is to add custom metadata to our application pages. And this is data that search engines are going to be calling for that help us explain things that are going on. And this is something that I feel like we have stepped away from a little bit in our development thought process with single pitch applications. So the cool thing is to make our pages really searchable and have good content. This is something that's already made available to us through ANGULAR. We have two different services. We've got a meta service, so we've got a title service. And so what we can do is we can import those services. And then every time that we are loading a new villager route, we can call different methods. So the the title service has a set title which is going to allow us to set the title of the page based on whatever our villager is, so I can handle this fairly dynamically in my village or component. And then we have a MEDITECH service that will allow us to update our tags. And so for all the different tags we care about, for instance, keywords or title or description or image, we can go ahead and populate dynamic information here. So if I want to set keywords, I can specify this is animal crossing's the horizon and then whatever my villager name is. So really powerful, dynamic tooling that we have out of the blocks from ANGULAR that can help us make our angular applications appear better for search engines. All right, one of the resources that I tend to use a lot, there's this school website called MEDITECH. And so if you're new to this kind of concept and want to see actually what your content looks like, you can go to this website, plug in your URL and make sure everything is rendering and looking good. All right, so that brings us to goal number three, and this is a cool one, and this is catching API calls. So like I mentioned before, I'm using this Animal Crossing API. And unless there's some sort of radical update, a lot of this information is going to be fairly static and not change super often. So this is absolutely something that I could basically cash these results and then have those kind of preloaded as the user hits some. So I'm not waiting on that API request every time you can already do this. And Angular, there's something called transfer state. However, in my opinion, it's a little convoluted there. There's a lot to write here and you have to do a lot of the management yourself. So one of the cool things actually offers us is their own version of transfer state. So if I have a villager service that looks like this very common where I am returning and it should be requests to whatever my endpoint is, what I want to do is I want to know if this request has been made before. I want to store that data somewhere. I want to serve it to the browser and have it available for these or more quickly than it might take to actually at this end point. So we have transfer state service provided by Skully, which actually wraps Agulhas transfer service and really minimizes the amount of code that you have to get this up and running. So you can just call this use transfer skills transfer state method. It takes a key, which is where that's going to be stored. And then evalu value, which in most cases is going to be the response of an HP request, for instance, in this scenario. But a whole lot of different ways that you can use this. So what this is going to do is it's going to when Puppeteer's doing that scraping, it's going to see this. It's going to make the request and then it is going to store that in a data JSON file. So here will populate all this information. And so that way we can pass it directly to our page. And Scalia smart enough to switch between this and do that for us so we don't have to wait on on this request to execute to show user content. So another really super cool thing provided by Skully. So if we were to run a lighthouse analysis over like just a villager page from our angular just served version versus actually static version, this is just a quick screenshot and you'll notice some of these metrics have changed a little bit. So it's important to know and understand what these different metrics are and how they factor into search engine optimization scoring. These are going to have different weights and different importances. And this is something that is constantly being reevaluated by Google. And so it's not like, OK, largest content, they're saying weighs twenty five percent now of of search engine results and where they're going to populate you. But that's not going to be necessarily forever. These are these are changing fairly often. And so getting familiar with understanding these different metrics that you're trying to hit, understanding how they play in the bigger ecosystem of wanting to perform your competitors matters. So when we were looking at approaching, performing, improving performance of our applications, we need to understand what metrics that we want to try and adjust. So the cool thing that Skully is going to do for us is really going to boost our first content because it's serving static, static page that we've basically built out already and that we're going to hydrate in the background like there's going to be something immediately visible for a user and also for Web crawler. So big performance there. We're getting a decent speed speed index. And so that's another one of our big, big ones, so an older version of it, one hundred sixty milliseconds with the Skully rendered version of a one hundred twenty. So good ones there. The other one we want to be concerned about is largest content. And so that means your biggest area that needs to be put on the page. You want to try and do that first. So the cool thing here is Skully is going to give you a lot of performance boost right out the gates by statically rendering this content. And then what you can do as a developer is you can start to look through these different metrics and figure out what you need to do to fine tune, whether that means caching API call, whether that means kind of figuring out your biggest areas and what you need to do, load, load, order wise or anything like that. So this is getting giving a good performance boost out the gate and then you can continue to optimize. So those are kind of like three super quick goals of how we can usefully, very quickly. And one of the other things that I want to give you are some tips and tricks. Schily is still fairly new in the ecosystem, which means the team is working really hard and trying to make sure docs are up to date and things like that. But that's not always feasible, especially if you're doing consulting is your full time job and contributing to open source. So I would definitely recommend that you clean this up so you can search through it locally. I'm a lot more fluent in my my idea that I am necessarily trolling through GitHub repo, so I feel like this just helps optimize my performance. If I can quickly troll through. There are features that are there and they're awesome and they just don't exist in documentation yet that you might miss out on. And so that's why I think this is a good approach. It's also good to be aware that you can take advantage of things like incremental rendering. So I mentioned earlier I had three hundred ninety one different villager pages to render, and that can take a long time, especially if I'm like troubleshooting or figuring out how Skully works. I don't want to be waiting on that every time so you can do incremental rendering where you pass an a base filter, which is going to take a base route path and only render what you pass it instead of doing everything. So that's available for you. It's important to understand how skill is rendering. I work as a consultant and so I've had clients approach me in the past. We're like, hey, we have performance issues. We've heard about the Skully thing. We can't get it to work. We don't know why it's absolutely failing. And so a lot of times I'll explain to the clients, well, this is how it works, is skill is going to again use puppeteer to crawl your your dis directorate of your project, try and render all those pages, basically scrape that content and then slap it in the folder and then other magic stuff that the team has provided for us. But at the base level, that's what it's doing. So I feel like having a good conceptual understanding of that helps you in your debulking journey if you need to figure things out. I think it's also really helpful. I'm a very visual person to see what Skully sees when running our pages. So if you want to run puppeteer where you can see it in the browser, you can run it with this show browser flag and you'll actually see Puppeteer doing everything. And you can go and see if there are any, for instance, JavaScript errors that you weren't aware of. Maybe something snuck through in your build or something like that. You can see exactly what the page is seeing. You can actually run solely with any puppeteer arguments. So if you are familiar with puppeteer, you've used that as part of your workflow. All those arguments are you are available for you to pass to to help you figure out exactly what's going on. For instance, I had a client that was like they would run Skully and then all that were getting rendered were these white pages. We were like, what's going on? And they had this weird third party, JavaScript library that they had installed to prevent the flicker. But essentially that was doing some weird logic where it was showing in hiding. And so it was just hiding the entire page to try and get rid of that flicker that it was causing real performance issue. And the only way we were able to diagnose that is by visually seeing it in the browser as puppeteer was running it and being able to figure out what was going on. And then another thing I want to call out is you can debug any potential issues with your angular router using the dash to show guess error flag. And so one of these dependencies is a library that goes through your application and tries to guess what your roots are based on what you can find. And so I had a client that essentially they had list or they had Sprout's into separate arrays that were named and then they were using a spread operator to bring them together. Well, that was not able to be interpreted by Gasso or the the the guest library or the guest rather library under the hood. And so they weren't able to figure out what was going on. It was silently failing. And so if there's a part of an issue with your router, this is a way that you can see exactly what's going on and get better errors to diagnose what's going on. So I know that was a lot of content for you, but we do have Q&A coming up. So kind of big picture and summary Skully rocks. It's awesome for Jim Stack Angular helping us figure out how to get our applications be more performance, especially for purposes. Skully helps us generate static pages of our application, which we can then serve. We are able to generate pages from dynamic groups using the plug in system, whether that means using something that's already there or writing our own, we can make sure to add content using the meta and title services already provided by ANGULAR. We can take advantage of you Schily transfer state to cache API calls we know will change a lot and so we can do some preemptive logic for the user and we can take advantage of Seelie arguments of any Schily dependencies. So anything Schily is using, you can use those arguments of the underlying tools while you're running Skully to give you better diagnosing of of errors or debugging or anything you need to do. I've got a lot of links for you here. The slides will be available, but again, the demo app is available. Just hosted a Democratic Field Guide app. The code is available on my GitHub and a field guide. I've got a couple of articles that explain how to do these concepts really in depth with a lot of code examples that you can copy and paste from, as well as useful debugging tips. And then the slides are available at TEF that I can get. Hubb, I want to believe. Thank you so much for having me. I Skully is a super fun tool, it's always awesome to be able to showcase things that that are built by our own insular community people. I'm so excited to continue the conversation about that with you all. Wow. Thank you so much, data for that was a whole bunch. There's a lot of love in the tap as well for you, so thank you for that. We do have a couple of questions from from people in the chance to put them on the screen, share. Everybody have links. Yeah. OK, cool. First question is by Lenny Stockmann. How will Scully handle routes that are protected with guards? That's interesting question indeed. So I so I guess this is a bit of a philosophical question because a lot of times you don't care about statically rendering guarded content because it's normally accessible within the application versus when we're using Scully to statically render pages or pages we care about delivering to the browser really, really quickly. So I haven't done a lot of it because what I've been on clients, it's they want something. Let's say it's like there are condos selling service and they want people to get information very quickly about a specific condo. They don't care about anything behind protected content. They care about what's immediately going to be in a Google search results. So I just I don't have experience doing that exactly because of that reason. Yup, got it, and I guess the guard can still block it if if wanted, even if it started. Yeah, because I mean, the guard will still function once your application, your English application is loaded. It's just. Yeah, from a philosophical standpoint, I'm not sure if you would want to care about free rendering guarded constants to deliver to the browser. Yeah, got it. Thank you for that. When we had a second question as well from Rob, how was he handled translations? Is it compatible with the both an angler and um, I guess I'm not sure. Yeah, it is. It is. There's an open issue on GitHub. About this on how to handle it, and I recently talked to a fellow GDI about this and he was able to get it working, so it should be possible. Nice, super awesome. That's great news. Then we have a follow up question by no name is it possible to combine static and dynamic pages easily with Skully. I guess like when you say static and dynamic pages, do you mean like dynamic in the way that we have like a page that is defined by a Perama needing to know that? Or do you mean like a page we're serving of versus our typical page like dynamic page we think about in the sparseness? For I don't know if, Sam, if you have a different interpretation of that question, I have the same question. It's not clear to me what exactly meant with the combined static and dynamic pages. I think the question is more about can we have statically generated pages next to pages that are not statically generated? Yeah, we can ask for input for four a.m., so if you can explain your question a bit more, No-Name Fifita, meanwhile, Will, we'll ask questions from from our panelists. Martin, do you have any questions? Yes, it's almost a little bit in the same ballpark as the question we got here, because or I did not really get it maybe, but with the transfer states, with the cash guy and since we're creating static Web pages, why would we cache that API? Because, as I understand correctly, the static pages are being random, basically on the fly. Once you run the build command and it's putting into the disk folder. So it's whenever we do a new build, we can actually I probably will call that API again. Is that the reason why I want to cash it? So so the reason why we would want to cash in API requests for better performance. That being said, like a lot of times when I'm talking about whether this makes sense or not for clients, it depends on their approach. If they have, like, a hyper dynamic API that they think is going to be changing a lot. This is probably not a good approach. That being said, let's say they have a certain set of products and maybe that product like that list of products changes every six months. And that since it might it might be a good idea because then you cash the call. You don't have to reissue that request every time because you have an understanding. And so it's important to have conversations at a business level and have an understanding of what matters to the business, how often content changes and what matters to the user to decide whether that's an appropriate approach or not. And is it then so that if you do the transfer state that on every build of your you're when Scully is running, you will look, is there something change or how should I see this? Because it's more done in the in an approach that if this website or application is running on a CD that is being deployed on multiple occasions a week or whatever. When you run this process, it's going to make that request and update the data file. OK. All right. All right. Thank you. Maybe then when you're developing, let's say you're developing and your build takes 200 API requests, you want to cash them so that every time you make a change and run to new builds, that you can grab the cash results then. So I think by default, if so, Sculley is checking for whether it's already built or not. So if you're developing your app locally and you're using this, you're going to get that API call requested. You're not going to be hitting the data, that data, that JSON file that's been created by making that API request is only going to be served for your static files that you're built. So, yes, you're wrapping this in your development, but you're still going to get that API request because Skully isn't running in your local development. Got it makes sense, I'm not sure that was the most eloquent explanation I've ever given. I know it makes sense. Makes sense? Well, yeah, that was one of those cool things when I discovered that under the hood, I was like, oh, that's so cool. So, yeah, I spelunking through their source code is fun cuz. Martin, did you have any other questions. Well the question of no name is the exact same question I think I have. OK, good to know. He says I meant whether it's possible, for example, to have static roots and anemic roots within one angerer project and to have it run on the same hosting. So OK, so so conceptually, let's say we're we've built the application that I was just doing and a somebody on the interweb navigates to villagers' one. They are going to initially get that static page that's been rendered and delivered, but we're still loading the application on it. That means the second they click in and do something else on the navigation, we are just back to a normal Aviel application. That getting help. Yeah, so it actually means if it's if it's available statically, it will be delivered statically. But if it's not, then all the other things of angular. So it's like you get an angular application with the cool things of being able to serving static content if it's if it's there or if it's generated by trickily. Right. OK, very cool. Yes. And no name answers. Great. Yeah. Perfect. So easy indeed. Thanks for asking the question. No name. Bonnie, do you have any questions. No, I actually learn a lot of schooling hanging out with sonder, so I've been following I just I just want to point out, because I think it's funny that if you look right now, when there's no comment underneath us, you see John Nickless like peeking in between Sam and Morgan. And it's adorable, like he's here with us even if he's not going to come say hi. You really should, yeah. We I've got Nicholas comes in, I. For at least in the corner that like, yeah, everybody's asking for him now. There you have a welcome live. Yeah. Nicolas, can you see that little picture of you in between? You're going inside. Can you just, like, recreate that moment just for a second for us? Oh, I was going. Oh, oh. Oh yeah. You need to make that face. That's kind of difficult. This was very spontaneous diva. Such a diva. Oh, and these are the clothes. Indeed. Indeed. But any questions for, uh, for Jennifer? No, that was great now. All right. Yeah. And then, Janet, do you have any questions for Jennifer? No, it was a great dog. All right. Thank you. Sam, do you have any questions for Jennifer? Currently not maybe officer, my talk a little bit, I hope I will deliver some new content because has been talking about the things that I was going to talk about. But I think that some some extra details and we believe in you, Sam. I will say I've sent my clients a lot of your blog posts, but I'm like trying to teach them and educate them. So they say I'm super knowledgeable and have some great stuff out there that's brilliant. So much love in year. Yeah. And we learn about it as well as time. So that's at least something we didn't know about to call me yet. I do have some some questions for you, Jennifer, before we go on. So first one like what is the difference between Skully and Universal? I think some some people in our audience may be wondering about that. Right. So the two big ones are slightly different approaches. So Eagler Universal provide server side rendering versus Skully provide static rendering that essentially you could just dump on a CD. And so like if you're like old school of and like you remember when Dev Ops was literally like chucking something in files Ilha, that's like a bit of the mindset that Skully approaches is a very, very crude analogy. So that's a big one. And then in my opinion, I think there's a use of implementation difference that Skully is you know, you set up a config. It's a very root focus. There is some integration that you need to do with your app. But I feel like it's a little less intertwined than what I see needs to be done for universal God. But again, like this is one that I will defer to Salman on because I always refer to his article on the Universal versus Skully. So, you know, you're already revealing everything that I'm going to talk about. Oh, OK. OK, OK. You know what? I'll save my questions until after some time. Do we do it like private screening your questions and then you can answer them together. All right. Thank you, Jennifer. I really appreciate your your talk and a connection held up greatly. So that was that was perfect. Thank you. Think for me what the stock was. I was reading that I was not aware that Scully and Angular would still work together so that you can have a Scully application with Angular on site. It's not the same like to be that that it's like it's a Gatsby thing and or eleventh or whatever. Then you just have static and that's it. But you can actually, if it's statically available, you'll render statically and if it's not just a regular on the side as well. Yeah, I would agree with that also. All right, so with that, let's give a huge applause for Jennifer. And let me introduce Sam for you. All right. So as you may already know, so Sam is our very own co-host here at MGB, your life. And you'll be giving a talk today as well. So some Bluebox has been playing with websites since he was 16. If you can guess how long that's ago, please put it into chat and we'll let you put it on the screen here. He studied computer science at the University of Kent and has been coding ever since. Sam is a Google developer expert for ANGULAR co organizer of Angler Belgaum Meetup Group and organizer of MGB Belgium's Angler Conference and also a very dear friend. Sam is an expert and angular, Universal and Skully and builds digital solutions for health professionals and patients at Rossa. Today, Sam is going to highlight three things that we may or may not know yet about Skully depends on what Jennifer said, I guess. Right? So super curious to learn what that may be. Sam, please give it up for some Bluebox. It doesn't work as well when we're all on mute, but we're clapping for you, Sam. Yeah, just a sec. I need to I need to prepare. Yeah. As you. Because just a quick peek behind the scenes. Sam is also orchestrating the screen. So he's getting a close, getting introduced and saluting a static when we see a UFO areas. All right. Yeah, we see the UFO, Sam. So. With that will give the winner take all. I'm going to take out my headphones so something's off, just going to take me off the jet. And. So all good you can hear me is. All this talk is going to be about UFOs. No, really. No, not really, because it's about the three things that you didn't know about Scully yet. Well, I might be mistaken now because Jennifer might have told you already some things about it, so. I will see if I can provide some extra details. I will probably limit my talk to around 10 to 15 minutes, so you might end up with some questions and I will be very happy to answer them after your presentation as long as I have some time left. So first, let's talk about the name of the project. This has been somewhat already revealed, but where did the name come from? Well, the project started already more than a year ago, but the company called Hero Defs and their developer consultancy firm from the USA. And, of course, they started the project. So they wanted the name of a hero for this project. And then, of course, Agent Scully, which is the female lead actor of this 90s science fiction series called The X Files, was quickly embraced as that hero. So Scully was born and the X Files Static Files kind of relates. And these days, of course, if you are trying to find a good name for your project that still has like an unused domain name. Finding that unused domain name might be probably the biggest challenge. So who am I? I was already introduced by you again, but my name is Sam obviously, and I've been a freelance software engineer for my whole professional career. And even before that, during university, I regularly do some Cyprus projects. And the most significant one has been the organization of the Belgian Angler Conference and eat and also maintaining the Angler Belgium Media Group. So yeah, and this means that I'm very happy to serve you and our community of angler friends as a guide for Angler. So let's show you what you know about it. Well, most of it has already been explained very well by our first guest. But let's do a quick recap. Scully is a static sites generator for angular, and it has the potential to become a static generator for almost any website or Web application. So not even using universe using angular, they are not really marketing that. But technically, theoretically, that should be possible. So its configuration is very easy and the documentation is growing. So it's becoming well documented. It allows for automated rediscovery of the pages that have to be prepared for your application. So that includes all static routes that get discovered by using its parser and all dynamic routes that get discovered by plugging configuration and custom router plugins. So this is all possible because of its bugging system that allows us to hook into this process and do awesome stuff. So how does it work? Again, a quick recap, because, of course, repetition makes you remember it better. First, we need to build our Anglo application, preferably using the production flag for an optimized build. And then as soon as we run Skully using NPM runs, the route discovery process will start. This process will generate a full list of the two Prerana pages and output this as an easy to read and understandable Jason. Next, Scully will fire up a static Web server for the static assets of this angular production builds, it might not be the port four to four thousand two hundred. So don't care about that detail, but we just need the application to be available from a server during the process. And then Scully will be under all the pages it collected before, and that's basically it looks pretty simple, right? But that's quite a lot of well thought magic happening behind the scene. And because of the toll, the existence of the toll, we don't really need to think about that, too. So that's nice. So you also might have heard about Universal and. In essence, it can do the same, but what what's the difference between Skullion Universal and the short version is that Skully uses Puppeteer to render and serialize our pages to esthetic develop and universal uses the JavaScript done, which is a no just implementation of our brothers document object model. Let's compare some good and less good points about Skully in Universal, first, the good parts about Scully. Scully allows for an easy configuration and as a very nice, extendible plugin system. You can use nearly all JavaScript plugins in your application, not even not even angular JavaScript dependencies, nearly every JavaScript plugin that you can find on the Internet, Skully will be able to handle them. Skully is loosely coupled from your project, so it's not even integrated into Engelhard adjacent file. This means that you can easily integrate and set it up for any existing Angerer project. And as already mentioned, it uses a super efficient transfer state to optimize client site navigations. Universal, the good parts, universal, can be very fast and reliable because its users are super fast implementation of the dollar, no just level and you can set it up directly by the Engler's Seelie and start using the official angler's support billers. The loss of freerunning and server side rendering of our application. On the contrary, supporting all the goodness of Skully and because of using Puppeteer, it can be relatively slow when you are generating and rendering many pages. Scully does not really allow for server side rendering. Yeah, so it doesn't really allow for server side rendering, so an update to the data that build up your pages will require a new pre rendering of those pages. So the less good parts about Universal is that it does require a tight coupling to your projects, so it's integrated inside the angled, adjacent and universal. In general, it requires a high discipline of strict coding principles. For example, you cannot use the window navigator documents APIs directly and you will need to use some dependency injection to work that out. If you want to integrate in an existing application, it might be hard because, as I said before, it requires strict coding principles. And if you did not start your project from the beginning with those strict principles, you might need to do some refactoring when you want to integrate Universal. It also has a transfer state, but it's good for initial page, it's it's less efficient for clients like navigations and let's talk about that a bit. So to optimize the client site navigation. This is an amazing a performer thing about Scully and Jennifer already explained it's. But what does it mean in detail? So as soon as a static page is loaded, Angular is bootstrapping in the browser and in navigation that you afterwards do in the app is potentially a client circumnavigation. So Angular is again handling the routing. It's a normal single page application before. So Skully is capable of collecting all the dynamic data that was loaded via HTP during the pre rendering process of any specific pitch, and this data is saved in a static asset file data to Jason right near the general demo for that page. So. So this is even more this can even be more performant than the state service from from Angola because and just in general, because you don't need to cash the complete data that came from the FBI. If you use some some mapping and some filtering on your data, you will only save the data that you need in the data that Jennifer. So when we navigate Clydeside that day that Jason will get loaded and if all or only the required data for the next drop. So there's no more need to carry the API or the backhands. Which could have been even more than one call, so imagine a page where you need to go three different then points to get the total data of your page, then you will make one call from you, make you will make one call in the other instead of three calls. So do I still need to explain to you that this can be superfast? So instead of getting data from different dynamic API and points that might do slow calculations or database reads, we just reach from one static file that has all the data that we need. So. To give a better idea, I've prepared a visual representation of how this works. So let's first start with our typical angular universal server side rendering setup at work. So the brother requests the page in this example, it's a new detail page and the server response to that by generating that page on the server, fetching all the required data. So, for example, first the details about the moves and then secondly, all the details about the order of this article. The brother is waiting for the response of the full HMO and of course, also including the angular build assets. So as soon as the server returns to the browser, the browser gets the full e-mail and all the assets and angular bootstraps, again, the browser. So now we're back at a single page application. So as soon as the user starts navigating around so for example, he goes through another detailed page for a news article. Angela will kicking and Angler will first say, OK, I need to get the news detail and then I would need to get the alternator. So. What we're doing to dynamic data requests, which we could have avoided. It's actually things, of course, very differently. So, again, the browser request page to the static server, this page was already generated up front so it can instantly return and there's no need to fetch the data from any API at runtime. The browser receives the full amount. The angler built assets and all, everything related to the application and the browser bootstraps, the single page application. So now as soon as a user navigates around, for example, again, the second news item page angler fetches that data. But Skully intercepts this request and fetches the aggregated data from a static database of. And now I come with something extra that Jennifer has not told us yet is that you can use something called enlight states and so instead of generating an extra DataDot, Jason filed that data will be included in the index of Jimal for that page. So you can even have one file less in your pre rendering process. So you have two options, or you use the data to Jason or use them out of the on the other page. So in general, this is much faster because your application does not need to clear your life, FBI can retrieve the data for the next page from a simple JSON file that got generated during the pre rendering, and that files also also posted on the static server. So I've already mentioned this before. If you only use part of the data returned by the API, we can choose to only catch that specific part in the data of file. Another thing to mention is that, of course, you can also do pre rendering with Universal and we can come to a same solution where we have that data to Jason file or or it's the data included indexing page, the metal file. But this does not come out of the box. It's universal. You will need to do some manual coding for that. The third thing, something that, luckily for me, Jennifer did not talk about yet is, is that being able to control the stability of the application. So this is the last thing I will tell you about today. So what do I mean with stability? To put it simple, we can reach stability in our application if there are no more tasks in the context of pre rendering pages. Spending tasks could, for example, be a ongoing HTP goal or spending some time out, for example. And these tasks need to complete to have our full data content ready, so if we do not wait for those tasks to end, we might end up with an incomplete page, for example, missing the dynamic data from from our backend and by default. Stability in Angola is handled by Zangas and is stable, observable that is exposed of the Application Service of Angola framework. So whenever we are using the building HTP clients from Angola, Universal uses this observer to this observable to know that the page is ready to be serialized. But Engler is by default not aware of any async operation like, for example, HP vehicles that are running outside of the framework, so. This. This is about being able to use any third party library in our application, Scully, and it will still work, you might use any other tool to do it, request to your back. And a good example for that could be, for example, a headless CMS JavaScript API that you use, for example, or amplify or magnify or whatever. And that headless CMW JavaScript API does not have integration with ANGULAR yet. So it's running outside of the of the context of singes. So in this case, Skully or Angler will not. Universal will not exactly know when the page is stable, so it doesn't know when to correctly serialize our page static HTML. And for this, we can configure our Skully module. To to disable the always monitoring and to wait for a manual idle. So as soon as the angler has received the contents, we manually fire the Apprendi event as a side event, as a side effect of the data fetching. So this is what we do in that function that assuming that, of course, our external HP library exposes our API, but in most cases it will be a problem based API built in ANGULAR. You can easily wrap around that which are just. So those were the three things I wanted to mention, as I said before, most of them were already discussed, but I hope that you were that I was able to to add some extra detail. And if you want to read more about Skully, you can, of course, check the official documentation on Skully website and their Guiseppe organization. And I also wrote a few articles about most of the stuff that I explained is in this talk. It's written out on my blog, for example, custom custom plug ins for Skully, How to disable Angular with Skully. That might be very interesting for you if you want to get to that. Ninety nine or 100 percent in Lighthouse. More in detail, the difference between Skullion Universal and comparing some benchmark's with pre rendering static pages with Skullion Universal. So thank you very much for your attention. Feel free to contact me about this at my email or on Twitter. And of course, if you have any questions, feel free to ask. Absolutely. Thank you so much. Yes, let's have a look at the charts. If you have any questions, feel free to let them go to post them in the chat. I'm going to add everyone back here to the screen. All right. Yeah, I didn't even know. I didn't know. So what did you know? Well, it just I like I thought that that it was pretty cool. The third one, just the stability of it. I thought it was already cool and I learned some new stuff. Yeah, absolutely, yeah, and No-Name also asked, like, so it's possible for Reactant View to also use Skully so that indeed, like, is it possible to run Skully with ultra JavaScript frameworks and angular theoretically? Yes, I this with the manual Identica. So if you fire an event that says to Skully that the application is ready to serialize, the puppeteer will just take the current state of the dumb and render it serializer. The static html in DeRisi guess parser maybe also supports react or by imagining that I feel like I was trolling that rebill recently that could be. I don't know that's which potentially. Yeah, and so nobody guess how long ago I was 16 years old. Yeah, we actually asked the question and answer like, was that 16 years ago? Yep. Is that true? Yeah. Yep. So we will have to send you a present. So thank you for, uh, for guessing. And, uh, you were totally right. It's indeed 16 years ago I just realized that now that I've been programing and coding for half of my life, it's insane. So we learned four things today, really. And, um, while we wait for some other questions and the chat coming up, Bonnie, do you have any questions for, uh, for Sam? No, I don't think so. I think you look great, Sam, so you should give us some tips on skin care. Perhaps not drinking for a month and a half is helping. There you go. And Martha, do you have any questions for. And or Jennifer. Well, since the talks were a little bit in the same ballpark, the only thing that that it became very clear and I was really not aware of is that indeed Scully just runs aside Angler. And for me, it was always like, I'm not going to dove into that because I don't know if I just only need Scully. But now it's becoming clear that it's like, yes, you get statically generated pages, but you got everything that Angler already has to offer. So if you have like a news website where you have, like users, an account info and all those things, that can still be your regular application. But the statically generated news feeds, that is just skully them. And that's something that I did not know before, even though I approve some of early posts. So, yeah, but and I also never dabbled with Universe before, stuff like that. But I have been investigating stuff like Isla Vista and things like that. But yeah, then this would be like an easier go to because I'm more familiar with Angular and then moving away from it because L.A. is like really static. So once it's built it's, it's done and you cannot do anything even though you always need to rebuild. So that's a little bit different. So if you want to have both, go with Skully. Yes, absolutely. Do you have any questions or sorry, did you want to come? There is a question in the chat. Well, it's not really a question. It's more of a remark that the latest angular update has something similar. Um, well, Universal has already been in Angular since V2, so. I think in the recent edition, in the recent version of Angler, there's the option to cash. Data that was statistically generated during server side rendering and return, that if it's already cached, if it's already rendered before, so you will not always render each page again, it will return a cache if it was already rendered before. OK, thank you for asking that question. Much appreciate it. Isn't it also that you will always have both lag in the sense that if you have certain server side rendering, there will always be some trade offs instead of having like Skully with, it's actually giving you the static content and it's super fast as well because just at the end point and it's there. But is there some timeline where they vote or is the team of Skully like looking to angular Universal as well, like we can learn from both of each other and maybe we can come up with some hybrid or buildOn solution and angular as well. Is it on like maybe a for far future, but I would think that that a lot of angular developers would also be able to benefit of just having that static generator or static golden generator being built in an angler like out of the box? Well, I think current conversations have more led towards the angular team, making it easier for regular developers to consume the tools that they want versus trying to maintain or do everything or solve every problem. So I think they're right now, the current roadmap is more towards how do we let people pick and choose their solutions versus providing the guardrails that a lot of us regular will versus so fond of. Yeah, makes sense, I think I heard. I'm not sure if I should talk too much about it, but I think that the Scottish team is looking into incorporating some techniques of universal into how they render. So why would not why would I would they not do it? Because if you can use a virtual implementation of the Jónsdóttir versus a real browser, which is much faster than you can optimizing a pre rendering process. So this is also the the idea behind Scully. Scully will work for any library that you include in your application. If a library sets a timeout or if it's calling the window dots or whatever location, whatever session, cookie API or whatever, it will still work. And if you do that with Universal, it will not because it's running on a note, just context. So that's for me. The the big value of Scully is that it works for everything. I said, do you guys see that? Yeah, sorry. It's actually like he did it again. Next toolbox for static generation. If you're like you have a roll and X and you can use it for angular, for react for whatever you want. But here with Skully, at some point in time, you can use this very act for you for whatever as I and that was theoretical. And Martin said that is giving them them an opportunity to expand, take over the world. It was an admitted well I think part of it is playing catch up to because if there's one thing people have been giving like, you know, angular shit for, it's oh, it's not as performant. And so Skully gives us a superway to clap back and be like, boom, look at that static rendering. Oh. And we still have all the things we like coming into the background. Absolutely. I think we can all agree that it's a wonderful tool based on what we learned today. So very, very cool to have it in in our community right now. Nick, do you have any questions for Sam and or Jennifer? No. No. All right. Martin, is it your birthday today? Or did we misread that? That's a long yes or no, is it the yes oh oh oh happy birthday. I actually was assuming they're doing it, why are they planning session on my birthday? But this is just a date as one other. But the song is still very young. I'm a bit older. Sadly, I haven't been going for well over it. Happy birthday. We send you lots of lots of love. Thank you for writing on your birthday. Yeah, I do have one final question. Uh, Sam and Jennifer, time you mentioned, like Skully intercepts, the API request and services from the data. Jason, does that mean Nisqually lives at runtime in the browser or does it does it kind of re-route that when when pre rendering is that? Are you aware of how it works? So you want me to yeah, you can go, you can. Oh, so this DataDot Jason file is only going to be created if you use the the static service method. Right. And that's going to say, OK, you're passing it a key and you're passing the value which when the purpose is we've been talking about this to request. So at that point when you're running Skully, it's going to make that API request, create that data, that JSON file and store it to be served. So it's something that you actively have to do to make that happen to be available there. The other thing Scully is doing is it's got to remember they've got a method that I think is that is Skully running? I can't remember the exact method name without trolling that they have that will not run for your local development version, but will be initially like it's going to be true in your static version. And so if it's true, then that static service is going to serve that data JSON file versus your local development. Your API request will happen as normal. Did I exploit. Yeah. So the original question from your emails is Scully running the run? And that's partly true, partly because you're injecting a certain angular service from Scully. So it's not like Puppeteer is running at runtime. It's more just Scully angular code that's running. Some of the pieces of Scully are also present in the browser then at runtime. Yeah, you do the skull module for root. So obviously that good will get the goods and I do military service, for example, the transfer state service. Those are that Scully. Good. That will be considerable. Got it. OK, thank you. Thank you for explaining so that that's why it's like, yeah, technically it's possible to do react, but then stuff like this would not be possible because it's it's like an angler module that that has to be loaded to do stuff like this at down. Got it, so it will be it will be much work to support the goat from the skully angular parks to react, but I'm not aware of anybody who's already done it. So theoretically, it should be fairly easy to do. I think with Westpac five, a module federation and all those cool things, that might be maybe something that. Let's not let ask me that. Yeah, I was here last time, so you learned a lot about your federation, if you will be a challenge for him to episode three. Indeed. And watch that. So but yeah. Thank you so much, Jennifer and Sam, for being with us today. It was so great. We learned a lot along the way. Super, super nice. I think we now all finally understand what Sculley is and what the difference is with the word universal. Also, a huge shout out to the top contributors of Skully, which is under Alias and for Ricardo. So thank you so much for bringing so much awesomeness to our community for making this happen. If any of you, uh, Sunderer if you're open to joining us one episode, feel free to reach out for more than happy to have you here and go a bit more in-depth on some of these intricacies that we learned about today before we jump off some. Jennifer, where can we learn more about you and is there any advice you would like to give to our Angerer community or to our audience? Maybe. Jennifer, you want to go first? Yeah, you can follow me on Twitter at like, OMG, it's funny I do a website, Jennifer Dollar dot com where I post blog blogs. Actually it is in GABSI right now, so I'm in the process of transferring it to school in my spare time. No spare time. And my advice in general for this conversation we've had about Skully is like this is an awesome tool. But I think it's really important to understand the realities of the business, your product, what you're needing to improve and understand that like this, this performance in the game, there's not one silver bullet like you need to look at this very holistically, understand what your problems are, to understand where you're falling short when it comes to performance scores that Google cares about. So definitely take advantage of school if the situation makes sense to make sure that you're understanding things from a business perspective and making the right technical decisions in light of that, was that you jumping in the pool just then? No, no. We're at an area B and there are people who are not working like us nerds. Do we go to the beach yet? And we've been here since we got on Saturday night. All right. Don't touch the screen or we'll be in trouble. Is there anything you want to where can we learn more about you and anything you want to recommend to our audience? Yeah. Um, well. I've also been I've been doing some consulting on Universal and Skully and. It can still be problematic, for example, when you need to generate, let's say, 50000 pages or even more. How do you do that? There are still challenges. How do you distribute 50000 pages to cDNA? How long does that take? How many servers do you need? It's the questions that arise around the problem are insanely difficult to do resolved. So. Having such a tool like Scalia University is just the beginning when you really want to provide business value for a very big news website that has like 50 50 thousand or more pages, then it's more about how to generate your set of pages. So just keep that in mind. It's it's the global. Problem of all of this is it's insane. It's hard to grasp. Got it. Thank you. Yeah, and we learned that it's like the kick start for your CEO journey, but there's still more work to be done once you have it running. So thank you so much both for sharing your insights with us today. We learned a lot and thanks for everyone for joining in the audience. We hope you had a great time as well. Learn something new as well. Please have an awesome day. Stay safe and see you in our next episode. Thanks, everyone. Bye bye.

Blog

Top 5 IT management meetup videos in March, 2021

After our last IT management post about February’s most interesting meetup videos, we’re back once a...

Read more >>

Serverless: Top 5 meetup videos in March, 2021

It’s been a while since we posted a Serverless roundup. However, we’re back now, with March’s top 5 ...

Read more >>

Top 5 React and React Native meetup videos from March, 2021

March is over, and just like last month, we’re here with our hand-picked top 5 selection of the comm...

Read more >>