00:00 - Intro by Norbert Sram 03:10 - What's Prisma? - by Daniel Norman 6:43 - Write a function - by Stefan Juris 44:09 - Reasoning for Micro-Frontends - by Balazs Korossy-Khayll
------------------------------------------------------
📣 Stefan Judis (Developer Relations @ Contentful) Twitter: @stefanjudis Website: https://www.stefanjudis.com/
💬 WRITE A FUNCTION With the rise of the JAMstack, the evolution of hundreds of APIs and new hosting services tailored for Frontend engineers, the way we build websites changed. Instead of building everything from scratch, it's now possible to connect all the pieces, use all the services out there, and focus on the things that matter – building excellent products and UIs. But how do you connect all the pieces? Let's have a look at the missing glue that changed everything for Frontend engineers!
------------------------------------------------------
📣 Balazs Korossy-Khayll (VP Engineering @ BlackRock) Twitter: @bkhayll GitHub: https://github.com/khayll/
💬 REASONING FOR MICRO-FRONTENDS A story about experimenting and introducing micro-frontends in production with a retrospective on what went well and not so well.
- Welcome everyone, hopefully you can hear me and see me. My name is Norbert, I'm the organizer of this lovely meetup group. And I will this start the event with a small presentation from my side. So first I will have to share my screen. Okay, now hopefully you see my screen. So welcome to this year's last BudapestJS meetup. I'm guess you are already familiar with the agenda, but I will also introduce our speakers as we move on. But first and foremost, I would like to start with a round of applause and thanks to our sponsors. So BlackRock and Contentful, thanks to them we have Balazs and Stefan as speakers for this evening. Hopefully they will also into those BlackRock and Contentful for a bit. Thanks to Prisma we have actually this, among many things but this evening we have the streaming setup configured. So right now we are stream to YouTube, but this will also handle the recording and transcribing of the talks so we get to send it out later on and thanks to Jetbrains, we also have some things to raffles or a license coupon, which we can send to you, that you can use to redeem the top notch tooling for JavaScript development and everything else, if you're familiar with their product suit. So last but not least BudapestJS is a completely community driven event. So it's a free time. We don't have a specific organization backing us. So there's always ways you can help out. We are always in need of speakers, if you have ideas, just about topics that you would like to hear about, we also welcome those. Feedback in general is appreciated and just spreading the word. So get the word out and we are always keen on reaching a bigger audience, especially for our presenters as they do a lot of prep work for these events. And that would it from my side. I would like to hand over the stage now to Daniel, who will introduce Prisma a bit. Some of you might be familiar with Daniel. He already did a talk for us, I think three months ago, right? About Prisma and among many things, he already convinced me to start using Prisma. So Daniel the stage is yours. - Great so, hi, I'm Daniel. I'm gonna just add my screen to the stream. So hi, my name is Daniel. I'm a developer advocate at Prisma, and I'll try to keep this as brief, if you're interested in getting more information, I'll share some more links about that. So Prisma, what is it? Well, Prisma is an ORM that makes working with databases easy. And one moment, I'll just make this full screen. And yeah, so Prisma is an ORM that makes working with relational database easy, in NodeJS, and you can use it with TypeScript. And this is a common problem in the NodeJS ecosystem. If you've worked with a relational database, like MySQL, Postgris, or one of the many others that exist out there, there's a, it's quite challenging working with these types of databases and in principle, we're tackling this problem by allowing you to sort of interact with the database by having these two core benefits. The first one is higher productivity with things like rich auto-completion and co-generation. And the second is increased confidence with type safety. So Prisma consists of three tools. Prisma client is the ORM. That is what you use in your application to access the database. Prisma migrate is a tool that you use in order to migrate your database schema. And finally, prism studio is a modern and intuitive database gooey. So let's look at what a query might look like. So here in this little handler that I have here, this might be a rest API. You can see that I'm actually creating a user in the database, and you can see that what we're getting here is we're getting a lot of these type areas based on the schema of the database and what we're actually fetching from the query. So this is just to give you a little glimpse into what you can do. And you can use Prisma with any framework really. We have a lot of content on each one of these frameworks. So next.js, which is a react based JAMstack-like framework. You can build graph QL APIs. You can integrate this with Apollo to also build graph QL APIs. You can use this with NestJS, Express are Hapi. And for all of these, we have examples on the Prisma examples, repo for which I will drop the link in the comments. So that was it from my side. Feel free to reach out anytime and I will drop the links. Now, if you would like we have a lot of stickers, and if you're interested in getting some of those stickers, you can go to some of those pages for which I'll drop the links and you can get your stickers here by ordering them. So that's it from my side. Thank you for watching this and try it out when you have a chance. - Thanks, Daniel. And it was a great and good introduction of Prisma for those who are not familiar with it and now on to our main speakers of the evening. So our next speaker is Stefan, as most likely, some of you are already familiar with him as he was already kind enough to do a couple of talks for us, both online and offline. So he was already in Budapest for one of our meetups. I always love to have Stefan as a speaker because he brings a unique and critical view of app development, amongst many things. And his talks always have a main takeaway and real world experience and usage that you can leverage starting from tomorrow. So, Stefan, again, thank you for doing this and the stage is yours. - Thank you very much, man. I'm almost blushing here and now. All right, let me just hit play here on my little thing and I don't see the streaming software anymore, but is everything, does everybody see Write a Function here right now? I assume everybody does. Okay, no feedback okay, let me just see. Yeah, that looks good. All right, hey, thanks so much for the lovely introduction and thanks so much for having me again, let's talk about serverless and functions, shall we? And I really consider functions as we're using them today as a glue driven development for frontend engineers. So let me just quickly introduce me a little bit more. So I'm Stefan, I'm building stuff for the web now for almost a decade. And I work for a company that is called Contentful. So in case you're wondering how you can bring in a API first or a headless CMS into your next.js apps or your Hapi apps or your Express apps, or whatever you're building and you don't want to set up your own database and deal with that conduct management system. Actually, you can't give Contentful a try. But the main thing is that I'm really just a frontend developer and I just love it. I really care about building beautiful UIs and websites. And over years, I figured out that a very nice UI can really spark a lot of joy in myself. And while I do build things for the web, there are set of things that I don't care about that much. So for example, even though we had Prisma JS giving a little intro and Prisma is a great service, usually I don't want to deal with setting up servers or databases. And I just want to build frontend things for the web. And I also don't to write or set up the low level deployment scripts. In the past, I worked for companies where we had massive shell or Ruby scripts that were just are sinking files or SSH files through a remote server. And I really don't want to deal with that. Because the only thing that I really care about is beautiful UIs and websites. And when I started building for the web, there was a very strong separation of developers. So I did my first job and it was an internship at an e-commerce shop here in Berlin. And it was a PHP Magento shop. And we had some little bit of Jay Curry in the frontend. And there was a clear separation of the developers working on the backend, I'm more of a frontend. This then changed over the years. And the main reason for that was that NodeJS appeared, right? NodeJS was then the first steps of JavaScript and frontend engineers entering the server side. So from one year to the other, we were able to write our own tooling, to write our own deploy scripts and maybe even to run our own web servers. And when I figure that out, I was overly excited about deploying NodeJS servers everywhere, but this comes with its own set of problems. Because how do you set up and scale the NodeJS servers? So when did you know that you might know that NodeJS processes just die. So you have to figure out what to do then and how to do your paralyzed, maybe different services running in NodeJS. And I came to the same conclusion that I don't want to deal with that. So what I did then is that what I tried is I gave Heroku a try. So in case you don't know, Heroku, Heroku is one of these platform as a service providers, they deploy your stuff. They scale it to a certain extent and it more or less works out of the box. So I built this little thing here. So what you see as perf-tooling.today, I like to make lists of things. So what you see here is perf-tooling.today. Unfortunately, I'm not maintaining it anymore, by this runs still on Heroku. I'm still paying $50 a month because it's sitting there and now the web development industry progressed a little bit though. What we have now is that we have providers like Heroku, but we also have new and fancy providers like Netlify for example, or Vercel and there are several more services out there. And depending on how you define this whole term of serverless, everything changes with it. And before we move forward, I want to just bring a brief introduction of what actually serverless means to different people. Depending on who you talk to serverless could mean just that there are a bunch of API providers that run in the cloud that provide their servers and UNAPI, so that you can just use things. Serverless could also mean function as a service, which I'm gonna talk a little bit about today, which is mainly Google cloud, Azure and AWS Lambda. And the idea here is that you publish or push a little bit of source code, and this is then run by the infrastructure or just because developers like to troll each other, serverless could also mean the serverless framework. Which is a framework to orchestrate serverless functions. And now in 2020, serverless really became kind of a thing. And I think that development practices become a thing when Martin Fowler decides to write about it. So Martin follower is an expert in software architecture. So when this article appeared on his blog, I decided, okay, serverless is the thing. So now we have these three definitions of serverless. And I think, well, maybe serverless is more like an idea. Because when you think about the whole fact and I've worked in companies where we had engineering teams and we maybe even set up our own service sitting in a data warehouse. When you think about the fact that usually, when you use a cloud service, it is almost always cheaper than doing it to yourself. Even when you consider a 50, 100, 200 dollar subscription for cloud service or serverless service, this is usually still way cheaper than paying a single engineer. So for me, serverless is more like an idea rather than a single implementation. And when you do frontend, this is what you're doing anyways, right? So when I'm building a website, or when you're building a website, usually you have a analytics solution in there, because most of the people don't want to build their own analytics service. Maybe using a cloud CMS like Contentful, maybe using a cloud storage, like a Firebase. maybe you're using your era monitoring with Century, self hosted on the cloud, or you're using something like a Algolia, which provides you a nice and easy solution for cloud search, a little side story about Algolia, I worked once at a company where we tried sprint over sprint over sprint, to make our search experience faster, and even of our several iteration, we still didn't make it to be as fast as Algolia's. Because they are specializing this one single thing. And today you really don't have to build everything yourself. And there's this really nice resource from the people of CSS Tricks. So basically this is a collection of things that you can use when you don't want to reinvent the wheel. And serverless.css-tricks.com, covers things like for serverless functions, for authentication, for forms, for notification, hosting, most likely for everything, there's something that you can use out of the box. And for me as a JavaScript developer, this really just boils down to the fact that everything becomes Legos, because I can just connect all the pieces with a set of APIs. And especially in the JAMstack world, serverless gains more and more attention. So let's just talk briefly about the JAMstack. So this is the first definition of the JAMstack. Initially when the people came up with the JAMstack idea, this meant JavaScript mainly in the client, it meant the usage of APIs and it meant pre-rendered markup. And I love that. I think this is a great architecture for frontend developers. But when you think about this definition of JavaScript APIs and markup, people figured out this year that this is maybe not the right approach. So the JAMstack became the JAMstack without three capitals because not everything needs to be JavaScript driven these days. So when you go to jamstack.org, you will find out that the claim of this architecture is that it's the modern way to build websites and apps that deliver better performance. And there are two core principles of this architecture. So the one is that it still delivers or delivers aesthetically pre-rendered HTML. And then it bets on decoupling that then enables greater confidence and more resilience. So how do you usually build the JAMstack site in 2020? So first you have to figure out what technology or framework you use. You can also roll your own if that's what you'd like to do. And the there's a variety of things out there going from next to Next to Next to Gatsby, I'm recently more like an 11ty fan boy. And then you have somewhere a build server that uses the framework and fetches a lot of third party data. So what you see there for example, are the data providers that power up my own private website. So you see that I've 11ty, Contentful, Buttondown, which is a newsletter provider. Feedly which is my RSS reader, but I put that on my website too. And a little bit of GitHub stats. And the beauty of the JAMstack then is that the result is static HTML, which means that you can put it on a CDN. This is fast, secure and scalable. And then when something updates, you have two options here. So basically what you can do is you can go into your provider or into your setup and you press a button to rebuild the website, or you connect then all these third parties that you can use with an automated webbook. So that whenever something changes in the data storage or service that you use, that the website gets rebuilt. And with an architecture like this, you can really outsource most of the things that you are implementing over and over and over again. This can range from authentication to payments, to content management, data search, and much, much, more. And when I started building for the JAMstack and playing around with it, I think this idea is great. But I have the problem that you really can not use every API in the frontend. So let's just have a look at the example of sending emails. So you might want to choose that user provider like SendGrid, which is an email provider, and you could potentially install the SendGrid SDK and then sent emails as right from the browser. But what happens then? Then this guy, the hoodie hacker appears, and the hoodie hacker will find your credentials because you're exposing them in the client. You don't want to have sensitive clients and tokens in the browser, because people can just snoop around. And this is where this missing piece came into the play for the last few years, which is serverless functions. So let me just show you one serverless function example here, so this is what it takes. It is a typical JavaScript function because I like to write JavaScript and you see here that it is exporting an async function that's saying hello from Lambda. When you extend this example with just a little bit, and you return an object and a status code, you will find out that, congratulations, this is already an HTTP endpoint that frontend developers can use and deploy. Serverless functions do not only support JavaScript though, the support ranges from C-sharp to GO to Node to Python, Java. So whatever rocks your boat, you can use that. And this then has the benefit that, you don't have to worry about that. You can push that coat and it will run, it will work. These kinds of functions when you're using them for HTTP, for example, are automatically upscaling. So when you have a hack and use it, or you ran some big promotions, you can bet on the serverless functions because your provider will take care of scaling that up. And the beauty of this is that you're not paying for these, when they're not running. And then you have this little tiny pieces and decoupled units that do one thing only, and they do it well. So what's the overall cost of serverless functions these days, when you go to Netlify, you get 125,000 serverless function invocations per month. When you want to go a little bit more low level, and you want to take the journey into the AWS Edmund interface, you get 1 million free requests per month. So how can tackle now our problems? So this is already in HTTP endpoint that we could use like that in our Jemsek sites. All we have to do now is to bring in some functionality to send an email. And what we can do is that we can parse the request body, when you just make it post to this endpoint, you will know the URL, depending on what infrastructure you choose. And then we can define another function which is send email and then you use the third party provider of your choosing. And to see here already that this is the core part of being the glue for frontend developers. Because you can now hide sensible tokens in the environment itself. Which means that no hoodie hacker in the world can figure out how to send emails in my name. And then you can send the email. With this approach, hoodie hackers won't find your credentials since you as a frontend developer, really can just connect all the pieces. Which I think is beautiful, because now you can leverage all these great free services to play around with. So what am I doing with several as these days? So I really dabbled around with my websites, probably way too often. But when you go to the articles, you see that there's an old stool view counter as that counter. And this is actually powered by an Airtable spreadsheet. So Airtable is this spreadsheet as an API service. If you haven't checked it out, I think it's beautiful. If you ever tried to kind of automate Google Sheets and found out how terrible this is, so Airtable is a nice alternative there, and it's just being powered by a serverless function on Netlify. So whenever someone visits this article page, I'm just increasing an integer somewhere in the spreadsheet and I'm giving back a new number. Or another example is that I have this little form down here, which subscribes people to this newsletter service that is called Button-down. So when you, for example, using Netlify, you can define an, so Netlify has a little bit of form magic. If you want to use that one. So you can define an action, which is then the result of a redirect. And then you can just upload a submission, created function at Netlify, we'll just, we'll connect the pieces. And we'll give you the data, what was included in this form submission. So that even when people don't have JavaScript enabled or fails for a reason that still works. And with 24 lines of JavaScript, I can now connect to another API provider. And in case you're wondering, or in case you're interested in these slides, they are available under my dash links online. And I have to tell that really everybody, because I feel like the troll on the internet, because I own the domain, my link is online. So when you want to have the slides, there are under slash write a function and guess what? That's a serverless function too. So what I do here is that I'm using Contentful to power the content on my website, and I have a little bit of configuration to add and you redirect. So whenever something hits this AWS Lambda function, I fetch in the content and I'm redirecting there. This is 32 lines of Java script, and I just built Bit.ly, right? To handle the redirects. If I would like to count how many times people follow a certain redirect, I could also just connect that to spreadsheet. So these are the use cases that I have for serverless functions, but I also felt that it might be cool to find out what other frontend developers do with functions these days. And a few people replied and said, well, for example, the people from JavaScript conf Hawaii, they do something like SMS based code of conduct reporting. And I think about this, frontend engineers sending SMS, I think this is beautiful. Or our friends from leedsJS, they also put it to the next stage, where they scheduled treats, they schedule emails, they pipe around Slack posts and they create tickets in one platform and another, and at the end it is connecting all the APIs together because we now have the infrastructure to do so. And last year I built something that I think is worth sharing, which is this. So for example, what you see here is Grandma's Gallery and it's basically a website that my grandma can open on her tablet and wen my grandma presses this button, all her grandchildren receive a WhatsApp message. So how does that actually work? So the way that this works is that this is another site that runs on Netlify and whenever we pressed this button, the serverless function is executed. This then goes to Twillio and Twillio will send a WhatsApp message to pre-configured WhatsApp members. So when now one of the grandchildren maybe it's, me answers this WhatsApp message, Twilio will send a web hook to rebuild the whole website. So that my grandma always have a nice little thing sitting on her table. And every now and then there's just a new image appearing from the grandchildren. And the list of use cases, really just going on and on and on and on. So for example, I was on the stream with Jason Langstove and we used the serverless function to gate content on a website. So what he built is that the integrated Stripe with some serverless functions, and then when someone wanted to access some content, we piped everything through a serverless function to then figure out if this person is allowed to access some content. And if they were, then we just returned the content. And I think this is just honestly freaking cool that we now in 2020 can do all these cool things. If you want to learn more about these things, what I can highly recommend is this talk by Chris Coyier and it is called the All Powerful Frontend Developer. And basically what he does there is he's doing the whole round of third-party services with generous, free tiers that you can use to build very quick products and science. I feel like that it has never been easier to build products and sites that quickly with that many options, because we can now rely on services that focus on one thing and do it well. Serverless functions at the end of the day for me were the missing glue to frontend awesomeness. Because now we have this big bucket of options. And the only thing that we have to do is connect all the pieces, because we can control a little bit of infrastructure too. Just as a lighter side note, something that I am very excited about is another serverless function provider. And if you haven't had a chance to look at it, I can recommend to check it out. So CloudFlare just recently also joined the serverless functions game and what they do is that they have something that they call the CloudFlare Workers. And why all the others providers have this common module exports on NodeJS kind of syntax, CloudFlare goes a little bit into a different direction. So CloudFlare is modeling their serverless functions based on the service work of the API. And this feels a little bit uncommon when you think about this, but this opens up for completely new use cases. Last year, I was giving this, I built this prototype and what I did was, that I had a react app and I rendered it server-side in a service worker. And I rendered it also server-side in a Cloudflare worker. So what that means is that I had the same code base running in three places in the client, in the service worker and in the a CloudFlare worker. And this is just so nicely nerdy that I would like to continue exploring this approach. But it's not everything super great about it. So there are obviously also downsides when you want to decide to go for a serverless architecture. So, first of all, when you go down the rate and do you want to use serverless functions all the way down, testing and debugging serverless functions can be a little bit tricky. When I started doing serverless functions, it was actually fairly tricky to develop these because you had to do a Git push and you then had to figure out if it's working or not, and the workflow wasn't great, but over the years, this became a little bit better. So Netlify and Varcel, which are both my tools of choice and I'm just changing like how the weather is and depending on that, so they both offer now a CLI that is kind of mimicking the production environment that they have. So you can now develop serverless functions right on your machine, which gives you a really nice development experience. The log in is still a little bit tricky though, because you still have to figure that out, where to fish out the locks in the cloud. Then you always have to remember that serverless functions are not ideal for long running tasks. So if you want to crunch some image data, do some heavy data manipulation or do anything that takes a little longer, you have to be very careful because the providers out there also provide for execution time or build on execution time. Some providers out there also suffer of cold starts. So the way that it works, that is that we have a little bit of code running in the cloud and it is not running when you're not calling it. So sometimes it can take seconds or two or five until your HTTP endpoint answers the requests. So you have to be aware of that, depending on how performance critical that is. There are still some high key workarounds, and probably the thing that you have to get used to the most is that you don't have state. And serverless function is an encapsulated, single piece of thing that runs in the cloud. You can not just write something to disk and read it out later. So you have to find a way to connect and share state across these. But it's always in development. it really depends on what you're building and for setting up and building up a project very quickly, I think that serverless functions are beautiful thing that we have these days. And it's excellent to know some JavaScript. I mean, we're coming from the way where we maybe did a slide down and slide up because we knew a little bit of JavaScript and now we can build beautiful products and websites on the one hand, but on the other hand, we connect and use all these APIs that are out there to complete and really finish the thing. With a little bit of JavaScript these days you can come very, very far. And maybe my front Marcos takes it to the next level. You can also be very dangerous because we have a lot of power with the infrastructures that we have these days. So for me, I think, I use functions really for the majority of things that I do, because I do rely on a lot of third parties. And over the last two years, everything really became just legos for me. And that was my little intro to serverless functions. I'm Stefan, thank you very much for listening. - Thank you Stefan for the awesome talk as always. The grandma and grandmother application is really a killer one. That that really solves a specific problem, that's really awesome. Guys you can ask question from Stefan in the chat, what we have in YouTube. So feel free to note down or just give him a thumbs up. I would like to kick off with a question. It might be difficult to answer right now, just my observation in the past, is that for technologies that that become, I would say more of a mainstream tool, they usually have a killer app. Like classic example is for Ruby its Rails, like 10 years ago or so. Do you think there's a killer app already serverless, or that's still waiting to happen? - I think a few years ago, the killer app, at least how I started doing serverless, was actually really the serverless framework. Because it was this first way to orchestrate and AWS was the first thing that I played around with, that was pre-Netlify and all these newer houses. And if anyone ever entered the AWS admin interface, it's not that straightforward, right? So at that time, the serverless framework was for me just really defined some Yaml files and everything would just work automatically. I think that over the time now, over the last year or two, this change to that there is no killer app anymore, because when you think about the use cases, at least what all the frontend developers do is they use it for a very single purpose thing. And the tool chains that we have these days are fairly nice. So when you use and I'm a little bit of a versatile Netlify fanboy here, right? But they do the heavy lifting for you and it really boils down to writing 20, maybe 50 lines of Java script and then it just works. So, I think we see a shift in hosting providers over the last year because these new providers, the developer experience these days is just so nice. Honestly, sometimes when I do a branch deploy and it's automatically on a different URL and then I just have to merge it and the functions are all set up and everything's so school. So maybe the killer app is just the new hosting providers that we have, because I think like for frontend developers, it's just beautiful time to live in. - Yeah I also use Netlify and I was surprised how much it provides out of the box and yes, we are not affiliated with Netlify, but it just works. Okay meanwhile, you can still write down the questions. I'm going to note two things, if no other questions, I will have one more for you, Stefan. So you might have noticed that magic happens behind the scenes so when I say that word, let's say Stefan has the stage, then it happens. Well, that's things to Natalia from Prisma. So Natalia, thank you for helping us out here. We really appreciate it, it's wonderful. The second thing is in the event, I mentioned that there will be a raffle and even the beginning, the JetBrains sponsors the event. This means that I have two license number, or actually those are coupon codes that you can apply to any Jetbrains product and get it for free. So I will send out a form link in the message box on YouTube. You have to sign up for that. So I need an email name, which I can later on use to find a winner. And now feeling a bit ashamed because I'm not using serverless functions to get a winner from the entries. But. - Next time. Exactly you gave me some homework. I would just share my screen and use Google Sheets to find something randomly. And this leads me the same point that you mentioned Stefan with their table. I try to automate it in Google Sheets and it's just. - It's such a hassle. Oh my God. - Exactly, exactly. - So I was like, oh fuck this shit, I'll do it by hand. - That's what you said, but I thought that yeah. - Yeah so okay, one last question about the topics. So, so far I gather that serverless functions are mostly used in applications that are public facing. Would you also consider it for internal applications and in like large companies have their own software solutions, would you consider even they are building single-page application, so they adjust to having nowadays, but is it a solution for potential or a backend solution kind of at least a decree in those private facing applications as well? - I mean it depends kind of what you're doing, even though when you're doing private applications, you still probably have something like an off layer in there, right? Something to see if the people have the right access, you would have to bring that in then there too. And probably rely on some kind of session there. But you can totally do that too. If it's not too, yeah, no, I'm stopping there because otherwise I'm probably not giving it too good recommendation here. - Okay, it's a potential start, but yeah I mean, you have to give it a shot. That's the beauty of it. It's really easy to get started I do agree with that. Yeah let me see whether, meanwhile, we had some other questions popping up as far as I can see. No, so still, if you have something pops in your mind, feel free to write it down. Again Stefan, thank you very much for doing the talk. - Thanks for having me. - As always, I hope to see you next time as well. - I'm sure we will see. - Hopefully is in person. - In person. - Yes. - Yes. - Okay so our next speaker for the evening is Balazs. Now Balazs is a huge contributor to among many things, but I will name BudapestJS currently. He leads the number of presentations and talks. So he's kind of the pole position holder. I lost track of the number of presentations he did. Why I really love having as a presenter and that I think it's always a born for the audience as well is because he's the guy who's seen things. So he's not just a web developer or just the backend developer, he's really a full stack software engineer. And he always thinks like a software engineer in the large scale setting. So there's a lot of things you can learn from him and a lot of wisdom, which is coupled with humbleness. So Balazs thank you again for doing this talk and the stage is yours - Thank you, so we're very see kids running around town. - Balazs, you might have to mute the YouTube, turn off the sound on the YouTube sharing. There seem to be a bit of an echo coming from. - The sound is pretty terrible, I'm not sure what goes on. There seem to be like an echo delay kind of thing, or it might be a bad internet connection. - Just to say. - What we can do, if you don't have YouTube open and running with sound. If you do, please close that. What we can try is if you disable your camera with the voicing or the sound improves or not. Meanwhile guys where we're sorting out this small technical difficulty, I'm going to give you a link, which you can use to sign up for the prize we have. And here we go, I'm going to put this on YouTube. And there you go, you can sign up there. - So Belazs, is it better now? It doesn't seem to work. Okay meanwhile, you are sorting this out, yeah, most likely an internet connection we'll have to see. - Can you hear me? - The sound is still pretty terrible. Okay so sorry you guys for the technical difficulties, sometimes this happens even in in-person events. Meanwhile, here's your chance to sign up on the referral form. I'm now going to give you tips on how you can cheat, but I guess you figure it out, but I trust that you are fair. And remember we have two licenses, so there will be two winners for the evening. Also Daniel mentioned the about the Prisma stickers. You can take the time to sign up for those as well. Last but not least, we also have with Apache stickers and magnets, I think you can see it now. So this is a magnet which I can stick on my desktop. If you want one of those, usually we hand those out in in-person events, but you can write to contact at BudapestJS and we see how to sort it out. I'll send the email to the chat. Let's see whether Balasz his connection is better. - Hello, can you hear me? - Awesome now, now it's awesome. We see you, hear you, it's perfect Balazs. - Let's see whether it's going to be awesome or not. Okay, so after sorting out some technical difficulties, Hello everybody, so I am Balasz Korossy-kheyll and I work for a company called BlackRock. And so no but ask for a little bit of an introduction. I don't want to go into much details, but BlackRock is the largest asset management firm. And what that means is that you've probably, if you probably have some kind of a retirement savings plan, whether you have some private ones or maybe your company is paying for you, or maybe you just have the state one, but if you have a private pension plan, for example, you might, there's a good chance that you're investing in some kind of product that was created by BlackRock. And so BlackRock is not just a financial asset management company, but BlackRock is also selling the software that we ourselves are using for managing assets. So BlackRock is selling the software to other companies as well. So you can say that BlackRock is a financial company, but also a tech company as well. Okay, so and I am actually leading a small team there at BlackRock and so, first of all, I kind of want to explain why I'm thinking about micro-frontends. Because this talk is going to be about micro-frontends. And first I'm going to show some slides and then I plan to show you some code, that hopefully will help you understand and create micro-frontends. So let's look at this happy developer, right? So why is somebody a happy developer? So there's the number of different like theories about this, for example, you might say that you need to have autonomy, mastery and purpose. That's a popular view, right? Right now, I just want to focus on, what makes somebody happy developer, when you look at the code, right? So a happy developer in my mind deals with a unit of code, like one unit of code that fits into the head of this happy developer. So if I need to work with a code base that I can understand, and that I can instantly think about the different parts of it, then I'm fine. If I need to work with a code base however, that is large and I don't even know where I begin to search for something, then I'm becoming unhappy. Because there is a certain amount of knowledge or a certain amount of things that fit into my kind of working memory. And I'm happy if the code base is something that can fit into my working memory. So this thing happens with a team as well, right? So an unhappy team needs to deal with a large amount of code. And there might be some code base from one application that might be some code base from another application, or it might just be the same application, and it's a large complex application. And that application might have parts that you don't deal with anymore because they are fine the way they are, they work or maybe some parts of the code was done a long time ago, by some different developers that are no longer in the team and so on. So the code base can be very large. And some of the code, as I mentioned, can be considered legacy code. So I think, if you haven't touched some parts of the code for a year, you can consider that legacy code and you don't even know how it works. Maybe six months ago, you still remember something, but what you really like to work with is what you currently focusing on. And so if there is all kinds of other code that you're not currently focusing on, then you're not a happy developer. So the question is, well yeah, can the team be larger? Because yeah, more people can deal with more code, right? So that doesn't really work because of a number of things. So the communication overhead is one of the major contributors. And especially if the team is spread out over multiple locations, right? The locations need to synchronize. Maybe they're in a different time zone, but even if they're just physically in a different location, it's going to be a problem to discuss things, to come up with solutions for problems. And so what happens is that you start to introduce standards and conventions, and these things tend to slow down the development, right? Because you need to synchronize with all the team. And if there's a lot of code, then these things kind of are needed for the code to be a consistent, good quality code. So what else can we do rather than increasing the size of the team? So what I've been describing is kind of a monolithic frontend, right? The monolithic frontend is just one application that has a lot of different parts. It's a complex application and all projects start like this, you could say that on the left, we have the frontend in the middle, we have the backend and on the right, we have the database. So, the applications grow and grow and grow, and this is where you have, a lot of complex stuff happening in your application. So on the frontend, like let's focus on the frontend. On the frontend, you could have a number of different problems, when you have a large application, it's one package.json. So that one package.json creates a problem because if you need to, for example, update your framework, whatever frontend framework you're using, you need to update from one version to the other, there might be libraries that are not compatible with the newer version of the framework. So the more libraries you have in your large application, the more it can happen that you cannot easily upgrade to the newer framework. So, as I said, there's this legacy code problem that there are just code there that nobody really knows how it works anymore. And so if you have to upgrade, and if you have to touch that code, then you have to understand it again, it takes a lot of time. You also might have called in your code base that it was reused a lot of times. And so if you need to touch that code that is reused a lot of times, it's a lot of testing, right? You have to make sure that the whole application works correctly. If you need to touch that piece of code. And of course the developer experience is not that good as well, because the larger the project, the slower your IDE is going to be, the slower the build times are going to be, even just running something on your local machine might take a lot of time to start up, might take a lot of time to re-render the page after you've made some changes and so on. So yeah, you have all kinds of problems with a large application. And the solution could be the micro frontend. So on the backend, what happened is that people said, well, let's do microservices and the microservices, they should deal with just one thing and they have their own database, right? So the picture becomes a bit clearer in the backend and in terms of the database, but the frontend was still, and we could say, I think that most frontends are still a monolithic frontend. They combine a lot of functionality from maybe multiple microservices. And the idea is that you can break up the frontend into multiple smaller pieces. Now, this is not a good idea, this has been around, but I think where we recently, technology really made this possible. Okay, so I think the micro-frontends or micro frontend is a pattern to break up a monolithic frontend into independently deployable pieces. And I think it's important to note that it's not a pattern to break up something into reusable pieces. So you really just want to break up your application into multiple pieces so that you can independently deploy them. You can work on them independently and they don't affect the other parts of the application. Okay so we did some implementations in our team for micro-frontends. And I'm just going to quickly explain how we did that. So for example, if you have an application and you break it up into smaller, different parts, like on this screen, on this slide, on the right, you have micro-frontends, you have three of them and they make up the whole application, but you still have to have some kind of a thin layer. We call it a host, that bundles these applications together. So the host should have very limited functionality. It really just loads the code for the micro-frontends and does some kind of routing. Because that can not happen in the micro frontend, but everything else happens in the micro so frontend that load in data and displaying data and so on and so on. And so you can think about a micro frontend as something that is an application, but this application has kind of a public API and the public API, what really that is, is custom elements. And we are using the web components standard here. So it's a standard that browsers, modern browsers to understand. And it's a standard that multiple frameworks can agree on. And nowadays Angular has ways to create custom elements and Reakt as ways to create customers, You has ways to create customer elements, so most major frameworks, I would say, support this kind of exposing components, their own components as a compliance. So the rest of the application is just a regular, let's say Angular application. With all the features that Angular gives you. And what you end up with is multiple different repositories. For each repository you have a continuous integration and delivery pipeline and a location where you deploy your application. So if you change something in any of the micro-frontends, you only need to change the code for that particular micro frontend and you can deploy independently. Okay, so the host application has a small bit of code that loads the micro-frontends and it's fully on demand, right? So unlike maybe an Angular application that can also lazy load some of the parts, it's still loads a lot of things upfront, but with micro-frontends you really load the whole application when it's needed. Okay, so what is kind of the experience with working with micro-frontends? So, one thing that is very different from a monolithic application is that for a monolithic application, you have an overhead because of the complexity. So like I said, if you touch one part of the application, it can have effect on a lot of other parts of the application. And that just slows you down because you have to make sure that whatever you change has not broken the application. So with micro-frontends, there is an overhead because you need to do things many times. So you need to create a lot of repositories. You need to configure your continuous delivery pipeline a lot of times. Maybe you're using something in all the micro-frontends and so you need to maybe copy paste that piece of code in order to keep them independent. And so, for example, if you want to make a change in the monolithic, frontend, that's one, maybe one place you need to change the code. But it's kind of a big bang, you don't really know what will happen to the whole application. But in the micro frontend world, you need to change the code maybe many times. Like in this example, you need to change it four times and it's the same code. So it's kind of, it's not very intuitive to do this, but it has the advantage that you can do it step-by-step, right? So if somebody asks, how much time is it going to take? Well with a complex application, you can only say, well I don't know. We'll do it and then we'll see whether it works and we'll do all the tests and we'll have to go over the application and make sure every part is working with the micro-frontends you can say, well, okay, it's going to take two days for this part of the application, but I will have to do it four times. So in total, it's probably going to take around eight days, right? So yeah, there is advantages and disadvantages of doing it. So one other thing that is a common question, is how do you actually develop the micro-frontends? So you start with developing a micro frontend, you implement some kind of a functionality and then you integrate it into the host application. And then you go back to the micro frontend, maybe make changes then you check in the host application. So the way you do this is that your micro frontend code is deployed after you make changes to maybe a development environment, and then your host application loads the micro frontend from the development environment. So it doesn't have to run them both at the same time. The kind of the only situation when you need both, is when you're trying to debug the interface between the host application, the micro frontend. But that should rarely happen because you should keep the interface like the inputs and outputs to the micro front and to a minimum. Okay so some other considerations that I want to talk about is performance. So, for example, if you have 10 different micro-frontends, and you need to load all the files for the 10 different micro frontend, there may be a lot of files. So I think, the reason I think that we're, or the world is ready for micro-frontends is because we can pretty much have answers for all these problems for the performance, I think we have HTTP two or newer versions of HTTP that can bundle your network requests, and you don't have to await for a lot of flags to be loaded asynchronous, like after one another with HTTP 1.1. So memory, do you have to load the same Angular framework? Maybe 10 times, if you have ten micro-frontends with Angular. Well, there is, Webpack five helping you with that and the module Federation especially, and that can pretty much like take the Angular framework and load it just once and then load your code only the parts that are different. So you have to kinda think about the boundaries of what goes into a micro frontend, and usually this is kind of some kind of a domain or a vertical like a stack of dealing with one problem. And it's the best if you have very little inputs to the micro-frontends, but the micro-frontends, they do everything themselves. So I'm going to show some example. So the support model for your software need to adapt because then people have to be able to kind of understand a smaller piece of code, but that smaller piece of code is easy to understand. You don't have a complex directory structure. You don't need to think about where a component might be because the micro-frontends they tend to be smaller and easier to understand for somebody who haven't seen the code. But it's the best if the micro frontend, they have owners who really know the code still. So to the design and it's pretty much the only thing that you want to reuse between the micro frontend is some kind of a design system. So your company might have a design system, or you might be using, say Angular material or some other design system. And you reuse the design system between the micro frontend, but not any of the business logic, even if the business logic maybe has to be done twice into micro frontend, because that would create a dependencies between your micro-frontends and then you're back at the kind of the problems that the monolithic code base have. Okay, so now I'm gonna, okay, try to show you some, okay. Some working example of the micro frontend. Okay so on my screen, I have an example where I have my favorite example, the list of SpaceX launches on the left. And if you click one of those, then it will load on the right. So if I click on the left, it loads on the right and this might look like just a plain old application, however, the host application is actually pulling these two components, so the list of the launches and the kind of the right side that shows a little bit more detail about one particular launch from a micro frontend. So what happens is, and I'm gonna okay, show some cool here. So here I have just a very simple Angular application. It could be a Reakt application, could be whatever you want. What's important to you is that this application has just one very simple component. I'm going to just open this one, what you see here is I have this heather and I have the main section and in the main section, I have two components basically, the launch list and the launch list details. So the launch list component has one output. It can tell you what is the selected item, and the launch details expects one input. And it's the kind of the ID of the launch that you want to display. So the host application is very simple. It captures the output event from one component and passes it to the other component. Now I could even do something better here and I could, because the launch list and the launch details are coming from the same micro frontend, I could even manage the communication between those components in the micro frontend itself, but for the sake of showing you how the inputs and outputs work, I did it this way. Okay, so this application is basically just like that and there should be one library that is important here. And this one library has one service, and this is a very simple service. What it does, it goes and loads the micro frontend. So you can give it a name, the name of the micro frontend, and it will, it's a very simple code. It will just go to a certain URL, that has a certain pattern, it starts in micro frontend then slash the name, and then the files that make up that application. So this code, I created this code to kind of showcase what happens, but in a production environment, this might look a little bit different, but if it's done for the debug versions of these applications. Okay, so it has, just this one method that basically appends a script tag to the body of the document. And by appending the script tag for all these scripts, the browser loads these Java scripts, and then they start to bootstrap the application. The other application that is the micro frontend here. Okay so this application is very simple. Like I said, it just notes the files and it just uses the custom elements that are exposed by the micro frontend. So the micro front itself, looks a little bit different. So this is an Angular application as well. What's important here is that this Angular application has a library that is called custom elements. And this library has the list and the details components. And these are just basically very simple components, they wrap the Angular components, so that I can expose these components as custom elements. The way that happens is that I'm here using Angular elements. So with one of these lines, I define a customer then for the list component, and I define a customer then for the details component. So this is, if you, in your application, this is an Angular application as I said. If in my application module, I load the custom elements module, what happens is that the customer elements module will wrap my otherwise completely plain, simple Angular components into a custom elements. So if I go and look at maybe the least component, what happens here is that it has one output for the selection, right? And if I go to the other component, the details component, this is code just for the custom element. It has one input, so with custom elements, you get three inputs. So this component, the Angular component that I did, accepts a number. So what I'm doing here is that I have the setter for the flight number, which is the idea of the launch and it's a string, so I need to convert it to a number and then kind of and like, this way I'm actually using a subject here, so what I can sorry, so that I can use it with an async pipe in my template with the real Angular component that accomplishes showing the details. So if I go to that one, this is the Angular component that displays the details of a launch. And you can see that this input is now a number. So I can make use of type speed and type safety and all the things, because this is just an Angular component. And basically that's the reason you want to breath this Angular component into another component that is then exposed as a custom element. So that you can do all kinds of these things that don't belong to the actual functionality of the component that is displaying the details. Okay, so yeah, so this application can be run as well. So yeah, I'm showing here two terminals, the left side, it has some errors, but nevermind it is running the host application on my local machine. And since I don't have a development environment, where I put out these applications on the right side, I have, I'm running the micro frontend. So I'm running two applications locally, and you can actually go and see what, okay. What the micro frontend looks like. So this is the micro frontend application. It has this red heather, so that you know that it's a micro frontend. It's just a demo of the components. The component here has some fixed, wired in input, and this is the list. So these are actually the same components that are being used by this other application, except that this other application is using them as a custom elements, so as web components. Okay so there is a couple of things that is worth mentioning here. So when you're doing the micro frontend, there's a couple of things that you need to change. So one important thing is that, I'm gonna go back here and open up the dev tools. I'm just gonna reload it. So one important thing is that when you're loading your application, if you like take a look at, for example, this file that was produced by the Angular CLI when it built the application, it has a way or defining all the code on the window object in a certain module. And you need to rename this module for every micro frontend, because otherwise they would go into the same module or the same kind of namespace, right? And then they will, just conflict with each other. So the way you do this is that you introduce just the simple addition to the Webpack configuration. You need to override this .jsop function that Webpack is using. So by default, if you go here, and this are other application and take a look at what this application is using. By default, okay, to go there. So let's look at the same file. By default Webpack uses this name. So webpack.jsop, right? If you would compile this other application and not change it, then it would use the same module name. So code from both applications would land in the same namespace or module. And that will have some very nasty side effects. So you need to change that. And the way you do that is that you just replace, sorry, in this file, you just replace the, let me scroll up. You replace this thing, the builder here, with something that's called the Angular builders customer effect package. So you need to install this package and you need to replace what Angular has here. So it's on its own. And you need to define the file with some additions to the Webpack configuration. So you cannot do this because you want to override the Webpack configuration that Angular CLI creates. And you don't want to kind of eject the configuration, so you don't want to actually deal with the configuration, with other parts of the configuration and then you don't want to deal with the configuration when something is changing in the project or when you're upgrading to a newer Angular or whatever. So you want to let Angular handle the web configuration, because that's the easy way. But you want to have this one addition and this one addition looks just like this. Okay, so that's one important thing that you want to do. And then the other thing that you you might want to do, but that's just a small thing is that you want to have the base Href here, somehow embodied in your Angular.json configuration, so that when you start this application, it's going to be available on this URL. By the way, you also want to change the port. So in this case, I'm not using the 4,204 port, but I'm using 4,300. And so in the other application, so on the other side of things, what you want to do is for local development, right? And, but not just for local development, if you're using a development environment to host your micro frontend, you want to create this proxy configuration. And a proxy configuration basically takes the path that where your micro frontend is deployed and redirects it to a different port. In my case, it's a 4,300. Because the files that you want to load from this path, they are hosted by this other locally running application. Okay so but if you have a development environment, you could use a different host name and load the micro frontend from there and you don't even have to host it locally. And with that you can achieve a way of working where you only work with one code base. So it's either the host application or one of the micro-frontends that you're working with. And like I said, since the micro frontend has its own page with with its own kind of show showcase or demo of the components, you can work with these components right here. And once you want to integrate them to the host application, that's where you start using it from the development environment that you already published it. Okay, so yeah, I think that's all I wanted to share. So now back to Norbert and see if we have some questions. - Thanks Balazs for the awesome presentation. It was great to see this whole thing in action, and I just see or read some blog posts about how great it might be. We do have some questions for you, but before we get to that, you can still sign up for the raffle, afterwards I will close down the form and to announce the winners. Balazs, let's do need help with, I mean, I can help you with the question. So Alex asked, what tools do you use? Oh, wow, we have technology here. I didn't know that it has this feature. So you guys see the question on the screen as well. Thank you Natalia. - So, but I'm gonna read it out loud. So what do tools do you use to set up a micro frontend ready repository? So it's actually just, you can accomplish these things with just a old Angular CLI. Like I said, what's important on one side is that you configure the output of Webpacks so that it doesn't use the default. So your micro-frontends don't interfere with each other. And on the other hand, in the host application, you just need to configure the proxy. So when you want to load your micro frontend, it loads it from a different URL. And whether it's local or whether it's your dev environment, you need to load it from somewhere else. Now, with that said, I'm actually using the MX Tols to, to create my repositories, because I find that the MX is a good addition to any Angular CLI tool set. But I don't only, because the MX tool set, it can work with mono rapples, where you have lots of applications and lots of applications are reusing a certain libraries. So I don't really use that functionality here. And when you're doing micro-frontends, you don't really use that functionality, but yeah, it's still a nice addition and it has a nice feature, a couple of nice features. But not related to the micro frontend. So there is, I think, or I've seen somewhere, I don't quite remember where I've seen some tools that you can use to make it easier to create the micro-frontends. But right now, I don't think that there's kind of a definite go-to kind of package that you can just download and make everything or configure everything easy way. Yeah and then also, so if you're doing this in production, you might want to do a couple of other things, right? Maybe you want to want to just have one JavaScript pilot per micro frontend so you want to bundle the JavaScript files into one. And so some other things, but yeah, we do them by hand, unfortunately. But I'm hopeful that in the future, there will be some great tools to do that, okay. - Thanks but we still have some questions for you, so we can move on to the next question from Bonoit. - Okay so the question is when not to use micro frontend, right? So I think, when the application is just a simple application, so when it's maybe a couple of screens and not a complex application, you definitely don't want to use micro frontend, so I it's the same thing with microservices, you start with one application, you could name it the monolithic application, whatever, but, when you have a smaller application with a small code base, you just, you want to have just one application, because it makes life easier. But the, really the advantages of micro-frontends come when you have a large code base. And when you start to have a large code base that is larger than what one team can actually understand and maintain. So that's where you can start thinking about breaking it up into a micro-frontends or multiple parts that are integrated together into one application and these smaller parts, they are now independent, and they can be developed by a smaller team. And the the smaller teams kind of just put together what they have into one large application, but what's important here is that the smaller teams, they don't have to agree on day to day problems with each other, right? But they have their own code base and whatever they do, it's not effecting the other parts of the application. So that is kind of the advantage of micro-frontends. But like I said if your project, or if your application is not complex enough, then you don't need to use micro frontend. - Our next question is from Balazs, - Okay, so do you think it's a good idea to use iframes to load the micro frontend? So I think iframes have been around for some time. And so using web component is I think it's a better in a number of ways. So when you have an iframe, what you really are doing is, when you're creating the iframe and loading the micro frontend or loading any code to the iframe, it kind of loads the code and it bootstraps the whole application. And in terms of user experience, that's not ideal at all, because when you're switching between micro-frontends that are maybe on different pages in your application, every time you open up a new iframe and load the applicator, that small part of the application into the iframe, it needs to bootstrap, and there a slight delay. So ] using web components, you need to load them once and they stay in the memory though. So when you go to a different page and then you come back, it's lightning fast, the customer elements are defined, and the browser just understands them. So once they have been loaded, you can go back and forth. And also you can, what you can do is you can have an Angular application with maybe services that load some data from the backend and those services stay alive when you go to a different page and when you come back to the page where you're using the micro frontend, the data is still there. So it's in the browser's memory. So it makes it much more fluent and makes the user experience much better. And also with custom elements, you can actually have inputs and outputs that work just like from Angular, you can use them as kind of simple inputs and outputs to a component that would otherwise, could be an Angular component, but it's just a custom element but still has the inputs outputs. So iframes, they don't really, there is like you can have some forms of inputs and you can achieve some kind of an output from the iframe, but it's not really complete yet. So, yeah, I think that there's a couple of reasons why the components are much better. - We have a question from Hugh as well. - Okay, so the question is about how do you kind of, well, I would say, how do you reuse functionally between your micro-frontends? So let's say, let's try to find example. You might have some kind of an error handling on your backend calls, right? And so it's always the same, right? You go to the back end, and if there is an error or you want to log it somewhere, or you want to display the error message to the user or whatever, and you have 10 different micro-frontends, and you don't want to implement the error handling 10 times. So the bad news is if you do use one common library, in all your micro-frontends, then you start losing the advantage of the micro-frontends. Because if you have one library and you're using it 10 different times, then it introduces a dependency between your micro-frontends and they're no longer independent. They're no longer kind of independently deployable or better said, you can create a library, but then you start to have to deal with the complexities of creating the library, because, it can be an NPM package, right? So an NPM package, but then you start to have different versions of this NPM package. And you need to upgrade all of your micro-frontends to the latest version of the library. And so, yeah, you can do that, but I think it's a lot of overhead. And so the thing is that doing something in a library is introducing communication overhead between the teams. So it's, in my experience, like what I always think about is that, I work in a company where we have a lot of frontend teams and every frontend team, they tend to implement their own, wrapper around the HDP client in Angular, for example. And they, for some reason, right? They don't want to agree on one commonly used version of it because changing anything in the common version will become kind of an impossible task if a lot of projects are using it. So yeah I think it's just, you have to be very careful with these things. And although it seems like a better idea to just copy and paste the code maybe, or to let the team implement their own version in terms of autonomy of the team and in terms of, might sound counterintuitive, but in terms of speed, the team can work faster if they fully own their own code base. Yeah, so hope that kind of answers the question, but yeah I would say try to use NPM packages that are publicly available and that are owned by somebody and try to use the packages that have a huge backup, they're very popular or is, you know, like a huge number of downloads per week or something like that. Those libraries they tend to be the stable and they tend to be supported by a team or by a couple of persons. And just use that and try to find something that suits your needs instead of trying to develop your in-house libraries that you'll reuse. So, yeah I mean, like it's, like I said, with micro-frontends, you have overhead buyer repetition, so you just need to do the same thing many times. - You've got some tough questions Balazs to answer. Last question from Krisztian, I think I can answer that one. So what is written on my awesome shirt? I'll try to fit it in the camera, but I'll also do a translation. So roughly I would translate it this way that I envy Santa because he only needs to go among people once a year. So that's the answer for that question. Thanks Balazs for all the answers and sharing your experience, I think is really a great topic and a topic that we will be dealing more and more in the coming years, as frontend just keeps getting more and more complex. And now on stick around, we will get a recap at the end of the whole thing, but now it's my turn. I will share my screen, if I find the appropriate screen. Yes, okay, so hopefully you see a bunch of names. I'm not going to use these emails or names, I will do them. These are the people who signed up for the raffle, and now I do my job. So I'm using random.org to generate a number. Let's see our first winner and our winner is number two. So Bense, congratulations you won, one of the licenses. Let's see our second number. And that is number nine. And that is Attiwa, you won the second license. So I'll send you the details to the mail that you provided and that how you can redeem it and then have fun with your new toy. And let's have everyone together before we say our goodbyes. Okay, so Stefan, everyone's here. Natalia, can we have you here as well maybe? - But just for a second, because I'm very shy. - Thanks, thanks so as you saw, the magic was happening throughout the whole event, that was thanks to Natalia. Thanks again for doing this and reaching out to us for doing this, without the doubt that this was the most professional online event we had so far. - Thank you. - So there is no words I can use to express our gratitude to you. - Well, thank you very much for this lovely shout out. Thank you for all our wonderful speakers. Thank you to the audience and hopefully see you next time. - Yeah, you too, Balazs, Stefan, thank you all so for doing these great talks. I think there's a lot to take away. I guess, Stefan you use your own domain to share your slides, right? So you can find those. Balazs will you share your slides and the code that you used? - Yeah, yeah, definitely. I can, I'll send you the, well, I'll put it out somewhere on Github. - Thanks, thanks and we'll keep in touch and I'll make sure that it's available because it also contains a lot of goodies. So again, thank you all, next year we will continue with BudapestJS, hopefully we also have the opportunity to do it in person, but regardless, most likely we will do live streams from now on as well, or at least give it a shot and see how that works. So thanks again for everyone and happy holidays to you. - Happy holidays. - Bye bye.