Okay, so you guys can hear me, right? It's fine. So yeah, welcome for our, like a very special session of the Java user group in Singapore. So for the first time, we are actually having a virtual session. We didn't really think it would happen before, but now it's like special circumstances. And I think many of you guys are aware of the conference we organized, Fox Day Singapore, which we do every year, and which we had to cancel this year because of the coronavirus. So we thought, okay, maybe let's take it as a positive thing. And since we cannot take all the speakers to Singapore because the conference is canceled, we thought since we do it like online anyway, we can have like super awesome speakers and like Java champions and all that kind of stuff. So we have a few lined up. The first one is Julien Dubois, who works for Microsoft and who is the founder of JHeapster. So you can see here, like in case you never heard about JHeapster before, JHeapster is like a spring and spring boots plus Java backend and you can choose your phone and can be angular or react or view. And it's basically an application generator and it's not just a toy, it's actually used by like, I think hundreds of thousands of people. So yeah, Julien will be showing you how to code an application from scratch and deploying it to production in one hour. So that's what we'll be doing for today. And just to show you a bit of what we have in plan for the coming weeks. Maybe you heard about this guy here, Kosuke Kawaguchi. So he is the creator of Jenkins, awesome guy as well. So like he did Jenkins for like so many years and recently he had actually moved to a new startup called Launchable, but he's still very involved in the continuous integration and Jenkins community. So we will have Kosuke next week. But the difference between Julien and Kosuke that Julien is based in Europe, which means he can speak like 6 p.m. our time, but Kosuke is based in the U.S. on the West Coast, which means he will be talking, he'll be more like a breakfast with Kosuke if you like. So it will be 8 a.m. our time when we'll be doing the talk with Kosuke. And the next speaker we have planned as well is the super famous Josh Long. So he will be doing a demo on Reactive Spring. That will be a few weeks later. That's what we have in the plan for the coming weeks. Then we did a small survey. Have a look at, I think I had a few issues. So like we wanted to see like, oh, guys, okay, it's a new platform and it seems like I didn't, okay, let's move on. Yeah, so it seems that nobody has used, oh, we only had two votes, didn't make sense or? Okay, yes, I'm watching now, okay. So basically we have 25% of the people who use JaveStory in production. Hope Julien and you didn't vote. But yeah, actually we have 40% of the people who use JaveStory in production. 10% who use for demo sample applications and 50% who actually never use JaveStory. And okay, that's one I think has some issues. I'll go back to it later if I can fix it. So never mind. There is just one more thing I wanted to share. So it's a bit special times for us here in Singapore. So yeah, we have the economic crisis which is due to the coronavirus. Some companies are actually doing some refinements and we have some people from our community who reach out to us and say that they have been retrenched. So typically we don't try to advertise recruiting and the kind of stuff in our meetup but it's a bit of a special time. So if you happen to be hiring and would like to reach out to people from our Java user group, please send us a meetup message and we will just put people in touch, okay. So you can see our meetup page. Just click on send message to the organizers, send it to us and we will pass the message for once. So yeah, that's all. And that's all from me as well. So if you want to start here, we'll do it. Okay. Thank you. Thank you, Michael. Sorry, I'm trying to get the... Do you see me now? Yes. Okay. I thought this was still on you. Okay. So hi everybody. So I'm Junior Du Bois. Thank you, Michael, for presenting me. What Michael forgot to say is that we work together for a couple of years at Spring Source together. So we are very old friends from spring. And sorry, it's always a pleasure to meet again. We were the two people from Spring Source France. So I'm going to show you what Jipster is and how to deploy it to production. Let's first... So I'm going to share my screen so you're not going to see me again. So because my face is not the most important thing here. And let's get started. Okay, can you all see my screen? Yes, I think so, yes. Yes, do you see my screen? Not yet. Not yet? No, okay, I see no. But Zoom tells me it's okay. So that's an issue with Zoom. Let me try this again. Oh, and this time? Yeah. Yes, perfect. Okay, thanks a lot. So I'm going first of all to do, let's say a classical presentation of Jipster because I saw that only half of you have already used it. And then I will do a presentation on deploying to production because it was, well, first of all, that was the theme of today's presentation. And also for people who already use it, I think it's of course more relevant for them. So I'm going to try to have something for everybody. I will also try to give you let's say latest news and information on Jipster. So people who already know it will also have, well, more relevant information from this introduction to Jipster. I will, oh, as Michael said, I am currently working at Microsoft. So I am working on a service where we can deploy screen to production on Azure. This is what I will use, but you will see that most of what we will see here are, I would say, independent of any cloud vendor. You can do it on any kind of cloud or even on premise. You will have some specific help to deploy to Azure. But what we also do with Jipster is that we try to have, let's say, common experience for everybody. So you will have something very similar if you use Azure or Google Cloud or Heroku, for example, from a Jipster perspective. So we will talk a lot about production and we will use Azure as an example, but what we will see here is, I would say, generic for the most part. So first of all, let's have a look at Jipster. So this is the main webpage. It's on Jipster.tech. So if you want, I would say, any kind of information on Jipster, that's where you need to go. It is very complete. And to explain you more what Jipster is, so Jipster is a code generator, as Michael said. And what we usually say, again, like Michael said, is that it's a code generator for Spring Boot and I would say more than front end, like Angular React of your GS. So that's what people usually tell about. It's a full stack generator for a Java backend and a more than front end. Things are evolving, things are changing. Now we have also backends, which are in preview for .NET, Node.js, Micronaut, Quarkus. So it's not just Spring Boot anymore and it's not even the GVM anymore alone. So it's going to, well, today, Jipster is going to become like a generic code generator, both for the backend and the front end. For this demo, we will be, I would say, very, we'll do very simple and normal stuff. So we'll use the Java and Spring Boot backend and we will use probably Angular on the front end, but we have many, many more options and this is evolving very quickly. So it will not just be that in the very near future. So Jipster is very, is used by a lot of people, as you can see here on our statistics. So for the last months, we had nearly 150,000 people downloading it. So it's a big down at the moment because of course of the coronavirus, but still it's a lot of people installing it.  So probably they are using it. That's why we say we've got tens of thousands of users. We've got nearly 6,000, 16,000 GitHub stars. If you can give us some stars, so we pass that mark, it will be very happy. And we've got more than 500 contributors. I think it's like 600 or 700 at the moment for Jipster. And also we've got many, what we call sub-projects, sub-generators, and so we've got lots of teams of other people who are under the Jipster organization, but who are not contributing to the main project. It's a very big project. So I'm concentrating on the main stuff, but it's much bigger than that. Jipster works also thanks to our sponsors and bakers. So people basically give us money while giving money to the project. The project is organized as a non-profit organization. Oh yeah, everything we do is free and open source. We don't have an enterprise version. We don't try to sell you anything. And if you would like to sponsor the project, well, you can give us money, but there's like nothing is forced, of course. And that money goes to our non-profit organization. So we use it basically for two things. One, to pay for some bug bounties. So when we have some important bugs to fix or features that we would like, we can put some bug bounties on it. And second thing, we use that money to organize some conferences or events around Jipster. So I have some little advertisement for our next conference. We just postponed it today. So it will not be on the debt because of the virus, but we will still do that conference in September in France. Should be the 14th of September, but not sure yet. So we only use that money for the project. Let me just go a little bit down. So as Michael said, so our usual backend is using Spring Boot, but we have now backends in .NET, not JS, Micronut and Quarkus. Our usual frontends are on Angular React and view is still, well, it's not in preview anymore, but it's not merged yet in the main project. So you've got three different frontends. And when you merge everything, well, that becomes Jipster. That's why we've got our little logo here. We've got different logos, by the way. So you don't see the same person all the time. What we keep is a bow tie usually. So that's why we've got lots of different hipsters depending on who you want to be. I'm going to do a quick demo and then we will talk more, of course, about production. You can use Jipster in different ways. The most, I would say, normal way would be here to create a repository, sorry, a directory and run Jipster on the command line. So you install it as a node module, so you need to have node installed and then you can just type Jipster and you're going to be able to run it on your machine. Doing it that way is, of course, more secure because it's on your laptop. You've got tons of options. I put my screen a little bit. Yeah, you can probably see better that way. And so this is where you've got the more control and the more power. Then it's, as you can see, it's common line stuff. So I would say it's good for most people, but people might like better web interface when they are starting. That's why for this demo, I'm going to use our web interface. We've got different ways to start Jipster, but the web interface is probably the easiest way to get started. So we've got, so our main website is www.jipster.tech and we've got start.jipster.tech. So if you know Spring Boot, it's the same as start.spring.io, but it's start.jipster.tech. I don't remember when we started that. We started that quite a long time ago, like Spring Boot. I think we copied them, but I'm not even sure now anymore. So if you go there, you're going to have the same thing as the common line interface that I just showed, but it's going to be as a web app, so it's easier to use. And also you've got nothing to install at the beginning. So it's easier to get started. That's why I'm using that for my little demo here. Of course, the more you use Jipster, the more you will use the common line. This is just for getting started. Let me create a first application. So if you want to log in, so I have logged in, if you want to log in, what's interesting is that you can push the application to GitHub or to GitLab. If you don't want to log in, which I can understand, of course, you can still download the generated application as a zip file, so you don't need to... Oh, hang on, I have it up now. If you need to log in, you will not need to log in for a very long time, because I want to suppress that. I know I have some doubts. Initially, you had to log in, but we're afraid of people like abusing the service, but we see that nobody abuses it, so we're going to remove security. So let me create an application on GitHub.  So those are the questions you would have, again, on the command line here, but here, they're easier to read. They're simplified. There are a few questions which have been removed to make things easier. So it's easier to get started using that interface. The biggest question we have here is what type of application do you want to do? Do you want to do a microservice or a monolith? That's basically the main question. I remember that for this session, we said we were going to talk about microservices, but let me just tell you the difference between monoliths and microservice from a deep-sub-perspective. So the monolith has got a front-end, so you've got Angular, React, or Vue as a front-end, and, of course, a back-end. So you've got a full stack application. If you do a microservice, it's going to be simplified, so you don't have a front-end. You don't have React, Angular, or Vue.js. Well, you have it, but somewhere else, not on your microservice. And also, if you use a microservice, you've got some specific Spring Cloud features which are enabled like Eureka to do service discovery, that kind of thing. So the difference is not that big, in fact, in the end, but that's the main question you have to answer. Yeah, I could use both. I am going to cheat a little bit. I'm going to set monolith, even if I want to show you microservices, for one simple reason is for my demos, I want to show you some data and to have something which is nice to see on the screen. And, of course, it's better if I have an Angular front-end than if I have nothing. Otherwise, I would be doing curl all the time to show you stuff, which is not really fun. So I'm going to just to keep that to have some UI on top of my application. We'll keep everything else by default just to show you a couple of important things about Zipster. As you can see, we support a lot of databases, like all SQL databases, like MySQL, PostgreSQL, Microsoft SQL Server, of course. We support also a lot of no SQL databases, like MongoDB, Gastron, Rack, Kuchbez, and Neo4j. That's also one of the main questions that you have to answer, because your data store is, of course, very important for your application. I'm going to keep the default here, but just to show you how Zipster works, if I select MongoDB, you're going to see that some of the questions are going to change. You see questions have changed. Going back to SQL, new questions are arriving. Those questions are not like a form that you fill up completely, it's more like a tree of questions. As I selected SQL, I'm going to be able to use iBanet, and I'm going to use an iBanet second level cache. If I had selected MongoDB, of course I would not have iBanet, and I would not have an iBanet second level cache. So what you need to understand here is that Zipster is like a tree of questions, and they're ordered in a way that is logical, and we are trying to help you. And depending on your choices, you're going to have new questions arriving or disappearing, depending on what makes sense for you. So I'm going to create a default application, so with a cache, I'm going to keep Angular. Yeah, I'm going to keep everything by default. Oh, hang on, I'm going to use Protractor for testing. So if we have time, Protractor is a front-end tool which is going to click everywhere on my app, so it's fun to have it just to show that everything works well. So if we have time, we will have a look at it. I'm going to generate this application on GitHub, on my GitHub account. And as you are all on the internet, you can even access it yourself. It's going to take like 10 seconds to generate the app. So if you are logged in, of course you can do it like that. If you are not logged in, the solution would be to download your application as a zip file. So my app is here. As it's public, if you want to test it, well, you can just go to that URL. I'm testing it in the chat box. So if you want to test it, you can just go there and have a look at what was generated. I'm going to clone it, and I'm going to, hang on. I'm going to clone it, and I'm going to go there. And I'm going to open it with IntelliG. Zipster works with all major IDEs, of course. It's generating, oh, sorry, it's opening in the wrong window. Here it is. It's a normal Java script application. So all major IDEs will understand what has been generated and everything is going to be set up automatically. What we didn't talk about yet is that Zipster does not only generate Java and JavaScript code, it also generates a lot of configuration files. So you can see them here on the left. Hang on, I'm going to scroll. Oh, sorry. Sorry, my shortcuts are not working. Maybe it's because of Zoom. No, it doesn't work. Okay, can you all see correctly on the left? Yeah, if you can't see correctly, just, oh, I see people, thank you for telling me. Yes, okay. If anything goes wrong, just tell me. I have the chat window on the right, so I see if it's, okay. Everybody says it's okay, so let's go. Thanks a lot, everybody. So yeah, I've got quite a number of configuration files which have been generated for me. I will take a simple one like the .gitignore file. As you can see here, Zipster generating you, generating for you also configuration files, so your IDE can set itself up automatically. That's why, for example, here my target directory is excluded because it has been correctly set up. Let's have also got, so here at Maven, I have selected, when I generated my project, I selected Maven. I could have also selected Gradle. It works the same way. So as I generated a Maven project, I got a .xml file here, and so, well, IntelliG, so it, so basically configured everything for me. So I have everything working. You can even see here, I've got the app which is ready to run, well, because IntelliG auto-configured itself, so I can just click here, and my app is going to be up and running. So all I did was just generate the app, clone it, and then I'm able to run it. And that's basically the experience that we want on desktop. We want to have something which is very easy to use out of the box. Some people say it's too complicated because we generate a lot of stuff for you. The idea is that you have something working by default, and then you're going to have a lot of documentation to help you understand what has been generated for you. We kind of do the other way around to what you usually do is having like a blank app and then have to learn everything. Here you have a complete app and documentation to help you understand what has been generated. My app is running.  Let me show you what's going to happen here, because it expands also what I just talked about. So I have generated my app, I have run it, but as you remember, I selected to have a model it. So I have a full stack application. I have a backend and a front end. And here I only started, in fact, the backend. I didn't start the front end. If you have a look here at what is being said, they tell me, oh, you didn't run and spend start or end pay run webpack, you didn't basically run the front end. So what we do all the time, as you can see here is, we try to guide you. We know you selected an app with the front end. We see you didn't generate, you didn't start the front end, so we tell you what you should do to do it. There are several ways to do it. I'm going to do the easiest way. So I got to package the JSON here. I'm going to say NPM install. Then I'm going to tell IntelliG to run my front end. And I will have the front end running on top of the backend and then everything will be working. All right, so it's taking some time to download stuff. I don't know why. Let me show you a little bit what has been generated here. So it's a, let's say, classical Spring Boot project. I've got source, main, Java. And here I've got some, let's say, usual Java code and the usual layers that you would have when you are developing Spring Boot. I got like a domain layer, a service layer with some DTOs, for example. I've got a web layer. All of this, well, all that has been generated here is mostly, let's say, a skeleton app. So there is no business value. Well, very little business, mostly for security, maybe for internationalization, that kind of thing. But as much, it's not a business app. Like a skeleton app, which is empty. And everything is ready for you to get working. NPM has run. Let me just say NPM start. This is going to start my front end. It's going to connect to the backend and I will have the whole application running. We have, once this is done, everything will be running. I will not have to start those again. We have everything configured to have auto-reload working. So for example, when I will change a Java file, I will have auto-reload on the Java side, which will be triggered and it will start automatically. And I will have also auto-reload on the front-end side. So as soon as I change a TypeScript file, Angela will restart itself. Well, we have web packs that will rebuild everything and everything will be auto-reloaded. I will show you an example very shortly about that. So the front-end is building. As you can see, JavaScript is a lot slower than Java. I think I have cleared up my cache at some point because usually it's faster than that. Anyway, you only do that once because after that, you've got auto-reload again, which is working. Here it is. So I have got my front-end running. I've got another person arriving. Again, this is a simple application. So I have only a few screens that are available. I've got screens like this one. So this is a welcome screen. You've got also an error page, a logout screen, that kind of thing. And you've got also some security, which is configured using screen security. So yeah, I have logged in. You can say I can do a few things on my accounts, like change my settings. I've got some administration screens which have been generated for me. For example, here I can have a look at my Spring Boot metrics. So those are the metrics from Spring Boot, which are being displayed by my Angular front-end. So I can see my GVM metrics, my HTTP request, my Spring Boot bins performance, the statistics on my cache because I'm having an iBanit level two cache, statistics on my data source. So I have access to everything here. But as you can see, it's most the only screens which have been generated are screens for let's say a general application setup like login, logout, security, and administration. I've got no business code. Business code would appear here and it's all empty because at the moment I'm having just an empty application. This is what a lot of people will already use. You don't need more than that to get started. I mean, if I want to challenge, let's say I'm going to change my main app. I'm going to add the logout. I'm going to do something very simple. Here I'm going to say hello from Paris. So I can code here and as soon as I build my code, auto reload will be triggered. That's why I just clicked here. Auto reload will be triggered and Spring Boot will start. And oh, so it's here. And my application will start automatically. So it says now, what does it say? Hello from Paris. It didn't say it. Hang on. I just did it right now. That's a cool non-working demo. What did I do wrong? Well, let me change something. Ah, skip hiding it. And why doesn't it work? That's weird. Application is running. It should have appeared here. Hang on. I'm putting some random stuff just to see if it picks up what I'm doing. Maybe I'm not in the right directory at some point. Not sure. Oh, yeah, something is just totally wrong here. Going to restart it. Just to check. So normally you don't need to restart. Yeah, I know it works. Okay, so I add auto reload dot working here. Let me test that again. Because that's the first time it happens to me, honestly. Auto reload with Spring Boot usually always works very well. Yeah, I know it works. Okay, I don't know what I did wrong the first time. Oh, now it's working. Okay, so I have auto reload at the backend and something on the front end. If I want to change like welcome here, I can go to my front end, which is here. I can go to home here. I've got some Angular code here. You can see an HTML page, some TypeScript code and a CSS file. And instead of saying welcome, I can say bonjour. Oh, sorry, I've got some translation. So I go from the translation here. And this is automatically saved. So I just switch here. I don't do anything. And it's automatically restarted. And now I've got bonjour on the front end works well. That's cool. So when I work with, so everything is set up for me. I've got auto reload on the backend and on the front end, which is of course fun. And we've got also something called browser sync. So if I open up a new window, my windows are going to be synced up. So if I go to an auto metrics here, you can see that everything is being synced up between my two windows, which is of course very useful when you want to test and code. So that would be my number up. As you can see, I can totally work with it like that, but we're going to improve it. We're going to first improve it quickly because I see time is running. I'm going to improve some code to add some business code. And then we're going to deploy it to the cloud. Those are basically the same kind of features. That's why it's interesting to see it twice. Let me just show you first how I'm going to improve my application. So I'm going back here to start online. So start.exe.tech. Again, what I'm doing here, you can do it on the common line. Oh, sorry, I see a question from Sarah Sharad, which authentication type are you using, token-based or session-based? Yeah, oh, by the way, if you have questions, just don't hesitate to type them. I'm having a look sometimes and I will answer them. Yeah, so with Jipster basically, you've got three kinds of authentication. If we go here, you can see them. So I will start the other way. So session-based authentication, that's what you classically do with the Spring Security. So you've got a token which is stored in your session. It is very secure because it's session-based. It has a few issues to scale because it's session-based also, but honestly, it's not that bad. That's the one I would honestly prefer, but as of today, nobody uses it anymore. So I don't know, I will not recommend it anymore. It's a bit weird because now all the rage is using JSON WebToken, which is the first option here. So JSON WebToken is, this time it's stateless. We've got also token, but this token is stored in your browser. So you scale better. It's also easier to hack. We've got a nice library for that on Jipster. So it's very easy to improve and modify. I think people love it because it's easy and it's scalable. Then it's a little bit less secured than HTTP sessions. And then you've got, which is the best of both worlds here, if you want to use O2. So Jipster also support O2. So when you do O2, you've got an external server that is going to authenticate you. Typically, we work with Key Clock from Red Hat and Octa, but they are not the only ones because O2 is a standard. So it's an OpenID Connect. So you've got lots of other implementation. Like at Microsoft, we've got Microsoft Azure Active Directory. Active Directory works with that also. The advantage of using such an external server is that it's going to be more secured and much more powerful that what you can do by yourself. For example, if you want to factor authentication. But on the other hand, of course you need to have that external server. So you need to set it up and maybe pay for it. If you use Active Directory or Octa, both have got some generous free tiers, but at some point you need to pay. If you use Key Clock, which is open source, well, you still need to pay for a server, of course. And probably as it's security, you need to pay Red Hat to have security patches. So whatever's the option, you will take air. It will cost you more money than JSON web token, but it will be also a lot more secure. So I would maybe recommend this for security reasons. Anyway, here for my example, I'm using the first one because it's really very easy to set up and hack. So yeah, so my application is running. I'm going to improve it. I'm going to add some, what we call entities on top of it. So Jipster is a code generator and we have what we call subgenerators. So a subgenerator is something which is coming on top of Jipster and which is going to modify what has been generated. We've got a full API for that and we can generate many different things. The most obvious one is this one and it's also the most famous one. So that's why I'm going to show it to you. I'm going to take this one. This is what we call the GDL, the Jipster domain language. So it's our own language to describe a domain model. As you can see on the left here, I've got categories, products, customers. So here it's my domain model. I'm doing an online shop. So my online shop has got customers. Customers have got addresses. They're having wish list for products. Products are ordered into categories and I can add stuff here like, welcome, which is a string and which is required. And you can see it's being displayed here. I can then save it. And if I go back to Jipster online, I'm going to be able to take this online shop and apply that model to my existing app. So I created it in test. I'm going to apply it. So what we are doing now is that we are generating all the code for all those entities that we have described. And Jipster online is going to do a pull request on my app with everything. And I just need to merge my pull request to have all that code arriving. So it's pull request is created. It's very big because we've got as you can see, 154 pages files. It's very big for several reasons.  We also generate all the tests for you. So you've got all the test files. So if you just sub everything very quickly, you arrive at a lot of files being generated. I'm going to merge my pull request. And now all I need to do is go back to my IDE. I just do git pull. So this is going to get all my code from GitHub. As you can see, 144 files have just arrived. As everything is working without reload, I just compile here. And my backend is going to restart automatically with that new code. And also my front end is going to... Well, my front end already was started because it's all automatic. So if I go here, I can see category products. I think it's category where I did welcome. Yeah, so I got welcome here. So that generated my front end and my backend. And you can see I've got even some sample data which arrived. We use something called liquid base here and also something called Faker.js to generate some fake data. So what's interesting here is... You see, I asked to have this business entity. It generated me the backend, the front end, but also the sample data so I can have something like real life straight away. Of course, maybe it doesn't mean anything. For welcome, it didn't understand anything. So just put some random stuff. For a date, it understood it was a date. If I go to a customer, it understood that email was an email address. So it generated some random email addresses. If you don't like those, they are all generated as CSV files here. If I go to config, liquid base, fake data. All the fake data is here. So you can just edit it with Microsoft Excel, of course. I keep working, you know, as I work at Microsoft, I keep making jokes on Microsoft stuff. Of course, you don't need to use Excel to edit that. Well, you can if you want to.  And also test. So everything is working for me and my app is fully running. As time is running, and as I'm speaking too much, let's move to production. Everything we have seen here is, I've got one goal. The goal is to make it easier for you as a developer to work. As you can see, everything out reloads. You've got fake data. Everything is easy for you. We've got lots of documentation. And that's the goal of our development mode. Oh, you can see we are in development mode here because we've got a nice ribbon here, which says development. Of course, the application is not ready for production. It's not a production app. First of all, as I've got out reload here with Webpack, I don't have a front end, which is very powerful. No, it's not me. Magnified as it should be. It's easy to debug, but it's not a production ready. Same for my back end. For example, I don't have a real database. You remember, I said, when I started the app, I selected my SQL, which is a default. Well, you didn't see me start any my SQL. So what's happening is that I'm using infects H2. So I've got an embedded database. I can go to say it here and I can connect to it. Again, as a developer, everything is easy. Everything is set up. But it's absolutely not something which is good for production. In production, I want a real my SQL database. I don't want to have H2 running. So I'm going to switch to the other mode. So we are development mode. Now we are going to switch to production mode. So in production mode, everything is going to be different. The front end will be most, well, will be magnified and will be much faster, but more difficult to debug. The front, the backend will use, for example, a real database will use my SQL. It will not affect data because we are in production. We don't want to affect data in production. Well, so let's have a look at how we do this. The important thing is that everything is already set up and configured for you. So one of the issues I would say that we have some time with Jibster is people arriving and telling me, oh, you generate lots of stuff. Like I don't know what this is or what Docker is.  And then like one month later, we have people arriving saying, oh, I want to go to production. You say it works with Docker. What are the Docker files? And we're like, oh, yeah, well, you did everything. So again, we try to generate everything that is useful for you. If it is not, that's why we have subgenerators. Generators are going to improve your existing code. But otherwise, everything that we generate is usually useful. So don't delete when you don't know why it's here. So to go to production, I'm going to have several options with Jibster. The first one, as you can see, is using Docker. We generated Docker files for you. For example, here for my history, I've got a my history Docker compose configuration, which is ready, which has everything to be running with some specific configuration for Jibster. We forced everything to be in UTF-8 and to have UTC everywhere. Not everybody does it. And we believe that having UTC everywhere is really good. So we just configure everything for that from the Docker files to the front end to the Java code. That's a lot of work that we do to have something consistent that you don't always see at the beginning. So if you want to go to production, you can use Docker. And for that, let me switch to my Azure documentation. If you want to go to any good provider and not just Azure, of course, well, you can run your app in Docker. I'm just going to go to Azure just to show you what we propose here, but that we will not use right now. Azure has got a Kubernetes service where you can run your Docker apps like any Kubernetes service. So the good thing as a developer using Jibster is Jibster generates all the Kubernetes configuration for you. So you can deploy to any kind of Kubernetes cloud provider like Google, Amazon, and of course Azure. The good thing here is that you're independent of the cloud vendor. The bad thing is that you need to configure Kubernetes, but we try to configure it well for you. So that would be another option. Another option that we provide on Azure is App Service. So App Service is a platform as a service, which has got some specific support for PHP, Python, .NET, and of course Java. So here you can run your Java app in the platform as a service. So you just push your Jibster app here and it's going to be managed and supported automatically for you. So if you want to run your app, so I'm coming back here to my application and let me just show you, I'm not going to do that for this demo, but just to show you how it works. I'm going to, I can run Jibster again and tell Jibster as an app service. If you want to use Google App Engine, if you want to use Heroku, it's going to be the same one. I'm just showing you this one first and then I'm going to show you the other ones. So if I use Jibster as an app service, Jibster is going to configure App Service for me. So it's going to create an App Service instance. It's going to reconfigure my app to be able to be deployed automatically on App Service and everything will just run out of the box, I would say magically. And that's because we've got this specific sub-generator for App Service. I'm just going to check it to close it and to show a competitor like Heroku. Heroku, of course, is an awesome platform as a service which also supports Java. So instead of saying Jibster as an app service, I'm saying Jibster, Heroku, and again it's going to ask me questions and I'm going to be able to deploy automatically to Heroku. All those platform as a service are awesome because they manage everything for you. So compared to Kubernetes, A, you just push your code, it's going to be built automatically, for example, you don't care about the Java virtual machine. The Java virtual machine is supported by the code provider. So if you are on Azure, we have an agreement with Azure system. So you've got a Zulu JDK which is supported, even on JDK8. And you don't even have to care about it. We will support it and upgrade it for you without you doing anything. So it's probably more secured and less work to use the platform as a service as using Kubernetes. But then it's up to you. If I go back to Azure, we support all of them anyway. So it would be like my own recommendation, but then it's up to you. And then, oh, just to go quickly, to be consistent, well, to talk about everything, we've got some Azure functions. You can deploy your code as as functions like Amazon Lambda, the same thing here. We also support Spring Boot. We don't have specific support for this on Jibster. We are, well, we could do it because there's nothing really specific about that, but we don't support it yet. And then, because I want to go to the, well, I need to select one option. I'm going to show you the one I'm working on. We've got a specific cloud for Spring, so it's a cloud that we have created with VMware, so formerly Pivotal. So it's a joint work between the creators of Spring and Microsoft. So if you want to use it, first of all, let me just show you the documentation. We've got this grid on Microsoft, we've got this grid thing called Microsoft Learn. If you want to learn what Azure, just go there. You've got tons of documentation and everything. And if you want to learn more about Spring, we've got a full tutorial on deploying Spring applications to Azure. It's awesome because I wrote it myself. Oh, I got some good marks, so if you finish it, please do, please, well, give me a mark. Just tell me also, but if you want to give me a good mark, please do. I'm going to do quickly what is being done in the workshop. So the workshop is supposed to last one or one and a half. Honestly, it can go quicker or longer depending on how you do or what you want to look at. Here you do everything manually. I'm going to do it automatically here with Jibster, so you can tell it's going to go a lot faster. So let me show you what Azure Spring Cloud is all about. So it's also platform as a service, but it is oriented to what Spring. So I already created a couple of things. So I already created a Spring cluster here. I called everything because I was lazy. You should give some real names, of course. So I created a cluster and I created a MySQL database because I want to do some of the data in the MySQL database. Just to show you that I am not cheating, I have opened up the MySQL database already. As you can see, it's empty. I don't even have well, I've got the sys schema, but I've got no schema for Jibster. I've got nothing in it. And if I go here to my Spring cluster, so this is a specific service for the Spring application and it has got specific support for Spring. So if you use Spring Cloud, you probably have Spring Cloud config server. Here you can have a full Spring Cloud config server which is set up for you. So this config server is going to push configuration to your app. If you want to put Spring in production by yourself, you need to have a way to store your secrets or your configuration. So let me just show you what has been generated by Jibster and then let me show you why this is bad in production and why you should do better. When we go here, we've got some specific YAML configuration for Spring Boot. Let's go to the production YAML file. So here I am describing, for example, my data source. I'm saying, okay, my data source is here. This is the name of my schema. Here is my username and here is my password. So if you use Jibster, this will work out of the box with Docker because those are, in fact, this is, in fact, the configuration that we do with Docker compose. So it will work out of the box. You can tell it's not very good. First of all, it's not very secured. Local host with SSL false. Let me put that to true, by the way. Because on local host, I don't have certificates. The username is here. The password is here. So when I'm going to do git push and commit that to my directory, everybody will see my password, which is, of course, not a good idea at all. So I should not put my configuration here. Well, I could put it there if I'm lazy. But, of course, it's not a good solution from a security point of view. There are many ways to store this data. If you use Spring cloud, so Spring cloud has got what they call Spring cloud config server, which is a configuration server for Spring. And this is going to store your data in the git repository, but separate one, which is secured. And this is going to push the configuration to your app. So I've got a simple one here. Let me just show you. So this one is public. It should not be public, but it's public so I can show you and so you can use it. By the way, I can let me post this to the chat room. All it does, I'm not putting my database configuration here because it's public, of course. All it does is that it's going to send you a message telling you, oh, I've been configured by a Spring cloud config server. So that just tells you that it's all right. So this will put that message in a property which is called application.message. Let me just go to my app here and if we go to application properties here. So this is mapped on the application configuration and as you can see it's application.message. I want a string private string message. I want to generate getters and setters. I definitely have trouble with my shortcuts. So this message is by default empty. As you see I don't configure anything. So what's going to happen is that when I will push my app to production my config server is going to take that configuration here and put that into my message. So I should have that string which is automatically pushed to this class file. We'll see if it works. It will work. Otherwise the application will not start by the way. Let me just configure that. So what did I do? I didn't configure it. So I need to take this and I'm going to configure it here. It's a public directory. So this is how you should configure your application. It should be configured by an external configuration server. That's why Spring Cloud provides you. Spring Cloud also provides you with a second important thing. So at the moment I have no application which is deployed. As soon as I will deploy my application to other Spring Cloud they will automatically register to the Discovery server which is based on Eureka and that will allow my application to see each other and to request to them. So I say I've got a question. Can we use this application property style in other environments like Eroku? Yes and no. If you go to Eroku there are different ways to configure your application properties. You can, by the way, let me create a simple app just because I want to show you that. You can set up environment variables. So that's what I'm going to show you as soon as my app is created here. So you can put environment variables. That works. It's a bit annoying because you need to type everything and you need to transform your YAML to environment variables. So it's not that secure because everybody has got access to the environment variables. So that's one way to do it. With Eroku you can also use a Spring Cloud config server like we did here. So I've got good news for you. Let me just go to gipster.tech. So gipster.tech, we've got our own configuration server which we call gipster registry. I'm going to use my own search box because I don't remember where it is. Here it is. So that you can run on Eroku and you should be able to do it automatically. We've got a button somewhere. I don't remember where it is. We have a button to run this automatically on Eroku. Maybe I need to go to Eroku in fact. I've got production. Eroku Yes, it's there. So you can just click on that button and you would have a Eureka server automatically deploy to Eroku. So difference between Eroku and what I'm doing here with Azure Spring Cloud the main difference is here you've got a Eureka server which is managed by Azure Spring Cloud so you don't see it. You don't deploy it. You cannot update it. You cannot do anything about it. It's managed for you so you don't see anything about it. You're not charged for it by the way. It's just there. If you go to Eroku here you need to deploy it yourself and maybe upgrade it yourself. You've got something which is more manual and everything is automatic. Also here we've got support from Pivotal and if you do it here well you don't have support from Pivotal. Honestly both will work the same afterwards so it's mostly matter of having something which is easy to deploy and having less stress or maybe if you want to go to Eroku maybe here you want to tune everything. You've got more capabilities because you can do whatever you want. So it's a matter of choice. By the way you can also deploy this to Azure Spring Cloud as well. Lots of possibilities. Just to answer the question from Sharath, yes you can do it a little bit differently but it's the same idea. I just deployed an empty app. We've got to discover status. This is Eureka. All you see is my app is running and that's all you can see. Eureka is totally managed for you. You just use it but you don't support it or manage it. Let's have a closer look now at going to production with my application here. We developed it. I need to configure my I forgot to say one thing. We need to configure the database. As we saw my database is empty. I've got the database. I've got a database which we configured earlier. Which I configured before this meeting. Which is here. If you think about databases on Azure, so we support PostgreSQL, we support SQL Server. They all have their advantages and disadvantages and we don't have the time to check all of them. They basically all work the same from an API point of view. We need to switch between them. What you will need to do every time and what I've already done. That's why I want to show you what I did. By default they're all secured. I have unsecured them. I have removed the firewall so I can access it. That's why I can access my database from my computer here with my SQL Workbench. I have removed I have added my Oh, I got a bug. Time is running so I will have a look at it. I have opened up my firewall so I can access my database. Here it gives me my connection strength. I need to configure my database connection. Once again, you should not do it in your application.pro file. As time is running, I'm going to do it that way because otherwise it will be too late. Of course, I am going to show you my password so I go to the other screen to copy and paste the password. If I can find it quickly.  Password. I got my password here. Okay. So my app is configured. I'm going to deploy it. As I showed before, this time I'm going to use the command line. I did a Gipster as your app service. I did a Gipster service. This time I'm going to do Gipster as a screen cloud. As you can see, it's always the same stuff with Gipster. It's always working the same way. That's also why you are productive. It's because we take care in giving you a tool that is homogeneous across front-end, back-end, across clouds, cloud providers. So this sub-generator is scanning Azure, so it shows that I default Azure group, which is this one. It's good. My cluster is this also. It shows the name of my app. I'm going to put everything by default. I just clicked yes, and let me just explain that last option. So you can usually deploy Gipster application in two ways. Again, we are very homogeneous. So it's always kind of the same thing in Gipster. You can either build your app locally, which is what I'm going to do right now because I've got a nice MacBook. So it's going to build quickly, hopefully. Or you can deploy and build your application to the cloud, which is what I would recommend, in fact, for normal people. Here, for example, we support GitHub actions. So the idea would be that you just push your code to GitHub. You just do that. And then GitHub action is going to build your app and deploy it. And Gipster is going to generate the GitHub action workflow for you. So if I had said that I wanted to generate or to deploy my app with GitHub actions, it would have generated for me a GitHub actions workflow and everything would have worked automatically. The end result and that's our goal for Gipster is that you just get push. You don't even know that you are using a cloud or a Google. You just do git push and it's working automatically for you. That's a real goal, in fact. Now, I went a little bit quickly because I knew this was going to take some time. So just let me show you what I just did. We, in fact, while Gipster generated a couple of lines of code for me. Let me just show them to you. The first thing it did is in my Maven. Well, it added, we can say because it's green. It added a specific profile for Azure. Basically what that profile does is that it configures Spring Cloud config and Eureka. So I can configure. So while my application will take its configuration for Spring Cloud config and also it will automatically register in Eureka. So everything will work. That's the first thing it did. And also configures this which is called Zipkin. Zipkin is a distributed tracing solution which is totally outside of Azure by the way which we supported in Azure and we believe it's important to have monitoring in production. That's another thing that we try to always do in Gipster. We are very production focused. So we will always generate for you monitoring and security because we believe that you will want this when you will go to production. So monitoring is already configured for you. So the first thing it did is create a specific Maven profile for those dependencies. The second thing it did is that it created for me a specific Spring Boot profile. Spring Boot profile doesn't do a lot. I don't even think it does anything. It's another place where you can reconfigure some stuff that we put but it doesn't do anything specific. It's mostly some skeleton configuration files that you can choose later if you want to. What's happening now is that so Gipster is building my whole app. Currently it's magnifying the front-end. Remember we had a big Angular front-end so it needs to magnify it and create some models for those. It's also going to run all the tests. The front-end test also with Jest. So all of those takes some time. Here you can see all the Jest tests which have just passed. Now it's running the Maven test. We have a strong focus also on test. I didn't have the time to show everything to you but we have a strong focus on test. So it's going to test everything. And then once all the tests have passed it's going to package everything which will run it. There's a question. Do we have to adjust something for OpenJDK? By default we use AdoptOpenJDK for everything on Gipster because it's like the most famous OpenJDK distribution. If you are on the Q1 stable version we support GDK8 to 13. In fact it also works with 14 but 14 was just released so it doesn't remove the limit. So the next version will also support 14 but today you can just force it. So it basically works with all OpenJDK versions. I don't know when we will remove GDK8 because it's deprecated but most people are still using it so we need to see that. So that's how Gipster works. Then for Azure on Azure we have an agreement with Azure system. GDK which is supported. It also works and you've got no difference as a user. What is important for you is that when your app will be deployed here that application will have a supported GDK it will also have a supported Spring Cloud version. So everything is supported both by Azure Microsoft VMware for Spring and by Azure system for the GDK. So what's interesting here is that you've got something which is fully supported. Of course that depends on I don't know what you want to do but I would rather use a supported version and something which is automatically upgraded than do it by myself but of course it depends on what you'd rather do. Let me just show you that screen again quickly so this is where my Spring with applications are getting deployed. I don't know if you remember I created a test app. I didn't create this one. This was created automatically by Jibster so if it already existed Jibster would have reused it but as it didn't, well Jibster created it for me and oh and so it packaged my all app and it pushed it to this instance here and so this instance is currently upgrading and it's going to run my app. It's already running from what I can see here. Let me just have a look first at the logs because I don't like to take risk. I can have the logs here in the console which is, yeah it's already running so that's good. Yeah we've got logs on the console which is always better. So if I go to my app here so my app is running here it's secured for the moment so it's not it doesn't have a public URL. It's got a test on point with a token so you can check it. I'm going to give it a public URL so we can have a look. Here it is. Of course as this is supposed to be a microservice you should not expose it like that but I'm just doing a demo so I've got the front and I'm exposing it and so here you can see that my app is running. I can share it here. I shared it on the on the chat and here I can log in and if I go to my entities now they're empty because I'm using a real database so everything is empty. I don't affect data anymore oh by the way let's have a look at the database so I had nothing and if I go refresh all my database is here and I've got my data like tables, like categories so categories empty for the moment and if I create a new one yellow I'm not very, I don't have good ideas today so I created some data and if I run it again it's my data here now so I can see that I'm using the real production database and this app now is magnified so if I use something like an audit from Google Chrome I can and it's going to tell me that I've got a very, very good app the only thing missing right now I think is that we don't have HTTP2 by default because we know that not everybody supports it and that's why we don't have 100% everywhere I think that's why but otherwise like you can see we've got like nearly 100% of everything that's why this is SEO accessibility everything is really, really good and okay as time is running let's just show you two last things just going back to my app here because I remember sorry, 5 minutes yeah well I want to say it will be done in 5 minutes because I remember when I wrote the comments about these sessions that we would scale them so just to show how you scale them you just click on scale this one is easy easy and you say okay I want 4 CPUs I want more RAM I've got more instances and you say save and I'm scaling my app that one was easy but once again you need to have a good cloud platform for that so this thing I wanted to show you was logging well I already showed you the logs here so you can imagine that the logs are being aggregated by Azure Spring Cloud so let's not have a look at this you've got of course metrics from your GVM so you can have a look at your metrics and what's more important for microservices is that we've got here some simple distributed tracing I've got only one service so we're only going to see this one what Azure Spring Cloud does here is it's instrumenting all your applications because I have added I don't know if you remember I added Zipkin sorry when I go here I added Zipkin supports so Zipkin is adding some tracing data on all my requests and then Azure Spring Cloud is taking that data to monitor your app so if you have several microservices it's going to map them and give you performance data on all of those microservices and you'll be able to see that okay this request is slow and you can have a look at why is your request slow maybe you had an issue or that's because I didn't log in first and so on so here we've got something which is fully ready for production without honestly doing much as we've got only five minutes left if you have any questions I think it's time to put the question from Philippe Soras oh I know you hi Philippe the memory requirements seem a bit huge for microservice oh yeah by the way yes yes yes you are right the slider increments by step of one gigabyte yes for for a Zipster app I think it runs on 256 megs but it's really really small I would do like 512 megabytes that would run normally fine one gigabyte is big I think that's everything that's the only option at the moment on Azure Spring Cloud that's something I can have a look at so yeah by the way just to tell you my real job here I'm working in that team to give them also feedback from users and I didn't I don't know why we didn't yeah maybe we should have yeah something more simple than that yes well to have more options here yeah we just increment by one gigabyte by one gigabyte yeah I don't think those gigabytes are very expensive so but we need to check that by by default you've got I don't remember how much I think you've got like 32 gigabytes by default and so you can run a lot of them and then you pay by gigabytes and by hour probably and it's pretty cheap but that's something that you need to check yeah my company has 650 microservices and we're trying to reduce that oh yeah if you've got that many microservices at some point it's going to be expensive also you need to be able to scale them so if you have like 650 maybe you've got another thousands of instances so in that case yeah that can be quite a lot of money so that's something that yeah we can have a look at this because it's yeah it's outcoded here but that's yeah which is which is very you know it's I can totally show on that yes it's a plugin to generate GDL from an existing database we always we have this question very often there is a team which did that it's a Belgium I forgot the name of the plugin and gone so Gypso was never meant to do that so I was very surprised when I saw people doing this but I it's not there hang on let me go to tools modules and blue prints so we got a market test with all the modules of blue prints so that external people who are giving us some add-ons and there is one to do that I don't remember the name I never remember the name you need to have a look here it's here I'm not telling it works for every kind of databases but I remember it was very very smart and it's your only option at the moment would a new Spring Grail module help produce that oh yes we got I mean yeah so Philippe means GrailVM so there's GrailVM compilation arriving to Spring they have announced even something about that last week it's not there yet but yes it's going to arrive I'm most interested by it for Spring Cloud functions because for functions you need fast startup as you can see it's honestly working quite well and also I'm very happy to have the GVM here because we've got a good GVM team at Microsoft the important thing typically on Spring Cloud is to be able to monitor the GVM and be able to scale it up and down and I don't know if you know that but we just bought a company called G-Clarity and there are experts in that so what I my real focus at the moment on Azure Spring Cloud is to have great scale in and up and down using some good GVM tuning because that's where you will get money if you are able to scale up and down very efficiently that's where you will get money I mean you as a customer then for something like Azure functions when you need fast startup then yes GVM is a good option while the Spring team is working on it the GVM team is working on it I know both teams I know they are doing a lot of work on that it's not totally ready yet but as soon as it is clearly there will be work on that clearly and for Gipsa so we will do that also for Gipsa it's much more complex than Spring with application it will take us some time for the record we have a Quarkus version of Gipsa and it does not work with GVM yet because what we do on top of Quarkus is more complex and just a simple hello world so if you are doing a hello world it's going to work well with GVM but if you do something more complex well it's more work even with Quarkus we don't have it yet on Gipsa just to tell you how complex it is oh yes I see Pascal is answering about the database and this one is Bastia Mishou that's it so if you are on the chat you've got the answer about the database generation it's not met anymore but I think it was quite good already but you need to have a look at that we've got Guillaume asking you are using monoliths on your Azure Spring Cloud isn't it it's mostly it's only for my demo that's why at the beginning I said I'm going to use a monolith to have a front end if you want to do microservices Azure Spring Cloud is a good solution especially because as you can see you've got Eureka you've got the Spring Cloud config you've got Distributed Tracing this is all microservice stuff so if you are doing a microservice that's a great option if you are doing a monolith you don't really need all that you need to pay for that service and you're not going to use I would say most of it if you are just doing a normal monolith I would recommend Azure App Service which is a pass which is another service from Microsoft Azure and it's going to be cheaper and work as well for monolith so it's mostly for my demo that's why I did a front end if I didn't do this you see I could show you my front end here if I if I haven't created a front end I would have like some swagger stuff or some jizz and stuff I would have like nothing to show for the demo but it's mostly for graphical it has an option with OpenJDK there are other tools impacted by Gradle, Spring etc I don't get the I don't get the question I'm sorry I don't totally understand the question we do support Maven Gradle when I generated the app if I go back to start the Gipster.tech I had the option to use Gradle somewhere I don't remember where it is but I should have the option somewhere here it is I could have selected Gradle it's very well supported we've got I would say like 20% of our users using Gradle yeah basically it's going to work as well as Maven Can you hear me now? Yes Time is running We have an existing J for application and how do we migrate to the latest OpenJDK a new Gradle version with Spring because if you upgrade the Gradle it also has a dependency with the Spring Yes because you've got an existing application and you want to upgrade it Yes only the tooling part for example because if you only upgrade Gradle it also has a dependency with Spring Yes so the issue is mostly for upgrading and that's a very good and usual question with Generator the issue is that you have generated your app we are giving you a new version and how do you upgrade first of all as you and you are totally right about that you probably coded a lot of business code in your Java so if I go to here to my Java code you probably don't want to update any of that code that was no no you had to category you modified it you don't want to upgrade that probably what you really want to upgrade it depends of course normal people what would happen for them and what you will want to upgrade is the tooling so here I've got Maven for Gradle it's probably the same thing so I'm just going to take Maven as an example because it's here but for Gradle you will have the same thing so several things are going to happen first of all so if you run Gipster again we can regenerate that file and you can use something like Git to do a merge and have a look at what we upgraded for you if you do that well two things are going to happen maybe you have added some lines like added here so if you did that your merge should work fine because those lines do not exist in the normal Gipster apps so it will work then there's the opposite maybe we added some stuff and then if you didn't change those lines well it will also work the main issue you will get is for example let's say you have modified we were using this version you upgraded to 2.2.2 and Gipster did the same thing so we modified the same code both Gipster and you and there you will have a merge conflict and that's the biggest issue it's when you have merge conflicts we are trying to limit them as much as we can typically this is why so if I go on top here sorry where is it this is why we have this is why we are doing this now with Gipster and this is something we are going to push more and more we didn't do it everywhere on Gipster yet because at the beginning we had a lot of questions so what Gipster does now is that it gives you for example dependency management what we call a bomb, a bill of material so it's dependency management artifact for Maven we are also having our own Maven dependency which is called the Gipster framework we do that because to upgrade is going to be a lot easier you just upgrade the version of your dependencies and everything upgrades so here you have like no merge conflicts it's a dependency that you upgrade it's the code that you need to merge that's why initially Gipster was just a generator and that's what everybody sees it as a generator and Michael in fact said it was a generator as you can see it's not all a generator anymore it's also like a framework and we didn't want to do it at first because we're afraid that people would not be happy because it's more than a generator but in the end we are generating a lot of stuff that nobody touches nobody wants to for example here for all the dependencies it's very complex to test all the dependencies and to be sure that they all work together so we do that work and we nobody wants to do that so it's something for our security code it was audited by a lot of people including very famous security researchers so we know that our security code is really good and audited and documented and nobody wants to touch that because if you touch this you're going to create issues so all of those we are packaging them more and more into frameworks and so updating them would just be a matter of updating the version here and so that will limit the issue and that's I hope that answers your question we're going to try to help you get more and more by limiting what we generate it's only the beginning of course I hope I answered your question I'm seeing more a lot of questions it's really perfect for microservices not monolith it's good for for microservice mostly don't remove oh yes another comment was that it's while using the cloud it's quite costly basically so the demo I did here in fact discussing some money like everything just let me show you a couple of things so here I have selected a sprinkled cluster which is a bit expensive to be honest those things will change it's currently in preview there will be like different pricing tiers and everything so don't take everything as forever things are going to change I also selected the database and my database so as I work for Microsoft I don't pay so I don't really take care of that but what you need to do and what is clearly my recommendation so first of all you do like me I have what we call a resource group so I did a specific resource group for this meetup so all I will need to do is delete the resource group and everything will disappear so if you do that you are sure that you don't have any resources like hanging around that you forget and that you will have a big bill to pay at the end I can't even show you my own resource groups I am not doing anything secret here you said you have a resource group for this meetup I think we are running a bit late sorry I think we are running a bit late oh yes so I just finished on this my recommendation is that you do resource groups and then you delete them so you don't pay a lot of money my other recommendation is that you use something like Terraform to automate everything just to show you I have my own Terraform script here and basically I automate everything so when I need something like here I created that one hour ago just before the session and I am going to delete it just afterwards so I don't pay a lot of money it is going to cost me a few euros because I am going to be quick to create and delete everything and I am just having a look at the last questions people are saying thank you I thank you to everybody for coming so most people are saying thank you and as Mike said oh that was the last question, thanks well thanks a lot let me stop sharing my screen if I can find where it is I will stop sharing thanks a lot Julien thanks everybody thanks for staying there 39 people thanks a lot for coming with so many people if you want to play with the app like Michael enjoy it because I am going to delete very soon and if you have any question or if you want to participate to Jib so don't hesitate to join the fun we will be happy to have more people using it but also more contributors thank you Julien I just wanted to conclude and say my survey was not working before now it's okay it's actually quite cool to see that we have people from pretty much a lot of places mostly Singapore but also France Italy, Singapore, Vancouver India and so on so thanks a lot of you guys for joining our meetup and we will have another one next week like we said with Kosuke thank you Julien thank you bye bye