This Spring Shall Be Challenged
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Steinhauer, Holger
Spring Framework helped us through dark times and is still a very active and helpful project. But is it the only option for doing any kind of web projects? There are many new frameworks around and they have interesting approaches. Especially when we use Kotlin, we might get better Developer Experiences and much better performance results. This talk is about showing you some interesting alternatives and hopefully helps you with finding a good fit for your next project Let's have a look at a real life borrowed REST endpoint, written in Kotlin (dahhh) using Spring, Ktor, Micronaut and Jooby. We'll compare the efforts, timings and developer experience and collect pros and cons for that next project planning.
 Hello and welcome to This Spring Shall Be Challenged, does it have to be spring all the time. My name is Hager Schanhoer, this is my very first talk, so please bear with me and enjoy the talk. A few words about me. I'm a professional developer for over 15 years now, so I started coding in the fourth grade and then, well, the rest is history as they say. I really, really enjoy it. I'm more than a decade on the JVM, so back in 2009-ish, I started to use Java mainly and since 2019, I'm totally in love with Kotlin and had quite some projects with it. I'm also the founder of Schanhoer Software, so we are a consultancy company providing new services around selecting text stacks and implementing services and we are remote first, so if you're looking for help for your projects or need some support in finding your text stack, just get in touch. Beside this, I'm also co-organising the virtual Kotlin user group and the Kotlin user group and I do support for quite some time now, the Java event. I will put some links for these things into the, I think it's the last slide, so if you're interested, just check them out and get in touch if you have questions. Also, and last but not least, I'm also a podcaster, so my podcast is coding with Holger, the link is at the end as well and I do feel like I want to do one or two more, so let's see what time permits. Right, so what are we after today? Today, we will have a quick view on how I see, so it's a really opinionated view on how current projects are essentially specced or how the decision comes to place on what to use, which usually means spring. Then I will show you what the challenge will be. It's don't be too excited, but it is taken from a real world project I just worked on recently. I will introduce it to the contenders and show you the findings I had during really, really lovely time implementing the same thing over and over again in four different frameworks and give you a very opinionated and well, yeah, a very opinionated conclusion on what I found out. So what I see in projects nowadays is that if they are not already in progress, I see loads of managers deciding on what frameworks to use or technology to use and this is usually based on Google results. Interestingly, this was one of the first projects here in Germany I did as a freelancer, so they wanted to change their text tag and they did some Googling, so they thought they want to go with Kotlin, which was great, but at the same time they said we have to use spring, which turned out to be not the best decision. Spring is usually seen, besides Agile in Germany, to be a silver bullet and I would strongly disagree with it. We will see some interesting findings towards the end of the talk, but it doesn't need to be spring all the time on the backend. And also what I see is that a lot of companies are more concerned of finding framework followers, so people considering themselves as a React developer or as a Spring developer, rather than software developers with experience on the back, all front and side of things and having worked with a couple of frameworks, so being able to switch between frameworks, which by the way I don't like, obviously. So what's the challenge? The challenge is very simple. So I want to have a simple rest endpoint. It will be a get endpoint and it should return a list of articles with some data attached to it and this data is all hold in a database. A relational database in this case, it doesn't really matter a lot, but just mentioning it, I'm more fan of the traditional relational database, which would be a completely different talk in itself. But yeah, so it will be this one and it looks simple, but it turned out in this project I mentioned before, I teased before, that this was already point of interest for my previous client, one of my previous clients. So they thought that there must be something quicker, it must be possible to be, to have a quicker response. This essentially spawned the idea for this talk. The output will be JSON, so there is some transition or some transformation involved and we want to have authentication. For the sake of this demonstration, it will be basic authentication, but essentially we don't want to have all our services exposed without authentication, right? So I should stop clicking buttons randomly on here, sorry. So what are the contenders? The contenders are four, two, four, yeah, four different frameworks, including Spring. And how did I select them? So besides them being in the media or in one or more projects of myself, I had a couple of requirements to them, so they should be easy to use and easy on the resources. So I don't want to spend too much time on setting things up, so get all the dependencies together and I have to choose the right versions and all these things. This needs to be easy. And also at the same time, they should be easy on the resources, which means I don't want to be, well, in charge to do a lot of optimizations from the very beginning to get them to perform quickly. And yes, we will have to optimize and yes, we have to look into how we code things. But just spoiler, in this case, the implementations I did, and I will give you a link at the end to the code to it, so you will see it's rather easy or simply implemented. This is on purpose, so I didn't want to do any optimizations. I want to see how these frameworks perform, if done bluntly. They should support Gradle, because I like Gradle, because in Gradle, I can have my build file in Kotlin script, but this is a personal taste and it would be funny if they support me, and they usually do, so Gradle was a bigger thing. And they should have Kotlin examples. Well, Kotlin examples, Kotlin bits in the documentation, if they aren't Kotlin or pure Kotlin by themselves like Ktor. And from time to time, we do have, we can deal with configurations or with code differently in Kotlin than we do in Java. So I want to see how we can use them in Kotlin or quickly copy and paste things to get started quickly. They should provide bootstrapping. This is what I meant with, what I mentioned earlier already with easy to use, for example, or it falls into this category. So I want to have a CLI or a web service like the starter, ProRestart, Spring IO, I think it is. So the initial setup where I can say I want to have a web server or I want to have whatever and get a basic project created again. So I don't want to have to copy all the, I have to type all the dependencies and get the right versions. They should be open source, of course. We all love open source. This is one of the reasons why we are here at Foster, right? And at the same time, I headed over and over again that open source literally saved my vacant because I could fix bugs or I can contribute back by fixing bugs. On top of this, all the frameworks should have support for authentication. For example, all off sessions, the more easy the better, the easier the better it is. And last but not least, this is also something I learned very early on. It's always good to have metrics collected. So they should, all the frameworks should provide us with metric collection capabilities. So if we think of Spring, it would be a trader where it's a matter of adding a dependency and then get things like a health endpoint or an endpoint to collect information about a number of requests and all these things. And it's easy to extend. They should provide something like this as well. And most, more or less, it's usually done in micrometeon nowadays. So what a plus we need some little helpers for our contenders. And I chose a couple of things you might be or might not be aware of. So one of the things is E-Bean. E-Bean is a, I think, underdog in the ORM space. And I particularly like the query being subproject of E-Bean. I will show you in a minute. And we use this SNOM. And this, I chose this because I can use this in all of the frameworks either directly or by just using it. I also use coinDI, a dependency injection for the frameworks which do not come within own IOC container, I use Gatling for some basic performance load tests. And Kenny is in front of the service on my Linux VM I used to do some load tests to get a bit more of a realistic view on it. So I didn't optimize it by essentially spun up a couple of Linux VMs, one with a Postgres database, one with Docker on it to run the applications in the Docker container and one to run the Gatling tests to get a little bit more fire under the hood. So let's switch to some code. This is the project I will give you a link to. So if we look into the structure, you will already see what you will find the contenders, your wikator, micronaut spring. There's the performance bit which is the load testing part and shared which holds all of our really, really highly sophisticated code for the ORM which is essentially composed out of two bits. So if we look at this, we have the base model which brings ID and versioning. And we do have two instance which essentially holds information about when a particular entry was created and when it was modified. So nothing really exciting here but you can see that eBean provides a very JPA-ish, can we get this? Here we go. JPA-ish annotation support. So essentially we have this in here and behaves near the same as hibernate and when created, then modified our nice little extra features. And then we have all of our domain models in this little class here or this little file. So essentially we have an article which I already mentioned. It has to have a title. And then it can have an abstract, so essentially a short description on what's going on in here. It will have for the sake of this demonstration one image attached to it via a foreign key. It will obviously have a body. I can have once it's done and it has a publication date and a couple of keywords attached to it. An image is, this is a really, well, a stripped down version of what I had in the real project. For now it only has a file name and original name of an image. So this was much bigger in the other project, but just to keep this as roughly comparable to what I had before and keywords are essentially just a set of additional tags, keywords, categories as you want to call them or however you want to call it. And this is all we need for our OIRM. We do use, so if we go back here, so if we check this, our eBean comes, our query bean comes with a query bean generator which uses the Kotlin annotation processing tool. So this gets generated either by a extension in your IntelliJ or Eclipse or via gradle if you use gradle to build it and then they use kept. So this generates code and we will see this in a second, which generates all the needed stuff. So in comparison to Hibernate this doesn't happen to runtime. This happens during compile time which is a huge performance improvement. And performance tests I mentioned before, just a quick glimpse in here. It's really, really, it's simple. So we set up the HTTP protocol in here. We point it to a endpoint and then give it a scenario, the scenario in here just says, okay, get all the articles from this endpoint here. And we want to have ramp up user numbers of up to 1000 within a minute and it shouldn't take longer than two minutes at all. And then we run this against the, in this case, the remote instance. That's all we need on this bit. So let's head on. So the contenders here we are with Spring Boot and I use Spring Boot in well as I refer to it as Spring Boot. But what I do mean is essentially all the Spring Project Spring Boot combines and bundles with the correct version numbers, right? And we do have some pros and cons on mostly all of the other contenders and with Spring Boot, you all know it, it's around for quite some time. It has a really, really good documentation out there. So if you look into the documentation given by the project itself, but also if you look at pages like Belldom, it's end-on-one-stack overflow. So we have quite some resources there. And it has a huge community which also contributes to documentation and help. And it's backed by VMware. So yes, it is still part of Pivotal, but Pivotal was bought by VMware quite some time ago. So it has a big backer there. It's on the other hand also on the cons side, it is rather heavy on the reflection part. So nearly everything, all of the quote unquote magic happening in Spring happens during runtime via reflection via annotation processing in memory. So this takes quite a hit on the performance side. At least we say so. And it comes with loads of dependencies. We will see this in the size of the FET jar we produce with the simple Spring implementation. It comes with loads and loads of Java baggage. So it is initially written in Java because it was a contender or a competitor to Java E back in the times. And it still has. So they do love Kotlin. They say this and they show this. So for example, with Spring Foo, we get a more Kotlin like DSL for all the things. But also Spring security, for example, with the next version, they come out with a diesel like approach to configure your security, which will be nicer to do, right nicer to read. So everyone who tried to set the security up and get this form in a readable way will know what I mean. Last but not least, it's slow on the startup. And yes, with Spring Boot 2, they improve this a lot. And I mean a lot. But it's still one of the slows out of the bunch. If we look into the implementation, it's rather straightforward. It's all what you would expect from a Spring framework as a Spring project. We have our well, hooking point or our startup point, we have a simple class which is annotated. Then we just started and we have a classic MVC pattern. So the controller holds the rest controller logic. Well, logic, it's a map to slash article and we say, okay, get mapping here. So this is get endpoint, which calls in turn the article service, which is auto-wired in the DIContainer we use or used in here is the one from Spring. Then it goes into the service, which does a lot of really fancy business logic in the form of calling the repository and returning the result. And then we see Qwerubin's in action. So the subproject I mentioned from eBeam, we essentially say QRTiql, find list. So this returns an empty or filled list and QRTiql is generated by kept or by the enhancement program in this case IntelliJ and returns all the articles as a list. So this is more or less the whole magic to get this work. And on top of this, we need it, as I mentioned before, I wanted to have a basic authentication. We need the configuration. So this is something where you have to know Spring, it's a bit clunky, but if you have only one configuration, it's fine. If you have multiple ones, you have to know or you might have to tweak it. You have to be careful on the order these get loaded and all these nice things. So here it's really simple to say essentially just we say on HTTP security, we want to have all requests should be authenticated. We use HTTP basic authentication is what I wanted to say. And we have something here, which is also you have to know it right. So we need a bean which is then used automatically by Spring, which implements the user details service interface. And this provides us with a user details manager. And yes, this is the mouthful, but essentially this here says, okay, we have these two users and this user then has a role. And we use the memory variant of the user details manager. This can be this can get much more complex, but this is more or less all eight. And with this here, we say everything we have in the controllers, but whatever we define in the controllers will be suspect to the HTTP basic authentication bit. So going back to the next contender, it's Ktor sorry for rushing through, but I have to keep an eye on the time. So with Ktor, which is really interesting because I couldn't find any comments, at least not at this stage. One of the very, very big pros is it is pure Kotlin, which just feels and it just feels right. So if you use Kotlin, Ktor is definitely nice. Definitely worth have a look into it. It has a really good documentation. So JetBrains and all the other additional contributors, they did a really good job. It's easy to pick up. They have lots and lots of different examples in there for all the combinations you can think of. It's really nice. This also shows how active the community is. Check out the Kotlin Slack Kotlin links like in this case as well. You find lots of help on there as well as well as on Stack Overflow. And it's backed by JetBrains. So JetBrains has a vital interest in keeping Ktor alive to position Kotlin on the backend. And you can feel that Ktor gets a lot of love there from the Kotlin folks at JetBrains. Before we get to micro now, let's have a look at where's my mouse? Here's my mouse at the code. So let's get this close here and have a quick look into Ktor. It will look very familiar. So essentially we are used coin in here because Ktor doesn't come with its own IOC container. So in the coin space we have to, or we can define modules which then in turn just define what is it what we inject and we say, okay, we want to have single items of these types and the implementations are this one. We could essentially do more fancy things in here, simple numbers, but it's all I needed in here. And then we go in here. So the actual application module we extend here or we implement here is the whole setup for the Ktor implementation I did. We do install coins. So Ktor comes with a module on an application extension for a supporting coin directly. So I didn't have to do or we don't have to do any initialization bits. We want to have content negotiation. So we want to be able to say what goes out of our controllers. This will be always JSON this case, but it's nice to have in here and it's easy to configure. You can see here it's rather explicit and then the next bit is already the authentication part. And authentication, especially basic authentication is rather easy. So we have it here. So we say we have authentication installed here and we say we have a basic authentication, give it a name so that we can have multiple authentication configurations. And then in the basic part we can, we have to implement the validate, which essentially just can check the credentials either hard or against hard strings like here, or we can delegate it against databases. And then we get into the implementation. So we need the article service injected here. So this is coin network and we have routing. So this is a pattern we will see with the other frameworks as well. So we define routes. And I think with spring we can already do this or we might be able to do this soon with spring through or one of the upcoming spring and we see bits, but don't point me down on this one. And we say, okay, we want to have, so this part of the routing is needs authentication. We map the authentication against the authentication we did up here. And we say, okay, we have one get endpoint, which is slash article slash and then we want to respond with the result of whatever the service gives back. So called respond is already K to R. And then the rest is something which will look familiar because it's doing the same thing. So we have article service here. And this called the repository or gets the repository injected and then calls a repository to get everything. And we use Q article find list again, right? Cool. So then we get to micronaut. Micronaut looks very similar to spring. So it comes with with lots and lots of additional, additional projects like spring. So for example, they have micronaut data, which is well inspired by spring data or real rails. And they come with their own IOC container and all these bits and box. But the big thing which distinguishes micronaut from spring is they use the as well the kept capability. So they do annotation preprocessing during build time. So we get all the things spring tries to figure out during runtime during compile time and then have a faster runtime. And this also results in the fast startup. So definitely faster than spring. And it's backed by its own company object computing. I think they do consulting as well. The only con I could find is it brings some Java baggage. So again, we have the to deal with not quite so straightforward nonability. And one or two other things we have to be careful with looking into the implementation and keeping an eye on the time. We should go into too much detail, but essentially micronaut then looks very similar. So I tried to stick to the same thing here. So we this is the startup. So we it's it's build a pattern they use. We can configure most of the things here. We need to to to get this thing rolling. We say the controller is in we use what's called packages. We say look into these controller. So we have the controller here and this looks already very familiar. So with the micronaut comes with its own set of annotations, which are then interpreted by the kept plugin and we have the one thing I had to look at is how to do the authentication, which wasn't that straightforward. But I found a basic example and adopted it. So the example they deliver with or might not delivers in code is a really simple authentication basic authentication provider, which checks that the username equals the password. And I did use this one to create this authentication provider, which then checks for our authentication details we saw before. The rest is the same except that we don't use coin, but the the icon to our IOC container from micronaut. And we see here again at singleton is comparable to at compartment at on the spring side. Going further, so Yobi is my my secret favorite. I came across Yobi thanks to a good colleague of mine. And it flashed me how fast it really starts up. And it's really, really, really fast. And I should stop using really, but it is really fast. And it comes with a minimal setup. So it's it's it's really just bare minimum we need to get something running and working. And it comes with a very Kotlin eskity as a that's really it's it's rather nice to use. And they have a mindset of using thin extensions extension layer. So we we delegate the work we want to do outside of simple HTTP request mappings and implementing features to whatever we whatever frameworks we want to use. So for example, the the container I use is coin, they don't have a dedicated extension for this but it's easy to set up. But they have a thin layer fordues, for example, and they do have a pack for J P a C for J extension, which then is used for the authentication bit and pack for J is a huge well, Java based but it's a huge authentication framework. The cons the documentation is very spotty. So if you if you look for for things and you always have to be careful if it is for version one dot xx or two dot xx. And this makes it a bit hard at the beginning. It seems to have a small team. It's not that big, but I hope they grow. I think they also start to create a company around your B and with two dot xx they throw away loads of integrations they had for one xx because they changed the way the extension works. And this is again coming back to the spotty documentation of the easiest bit plus it you'll be now says it's a Java and Kotlin back in framework or micro framework, but it still has loads and lots of Java baggage because yes, it is written in Java, but I spotted a couple of of Kotlin implementation bits there already. So what did I find? I hope you don't mind that I'm not going into the code, but I have to keep this short. So I found that obviously, well, if you look at the initial jar size and start up that obviously what was what we essentially could expect that spring has the biggest jar size. So it's it comes with lots and lots of dependencies. So they take their their toll on this one with 27 megabytes is not the biggest one. But keep in mind that this example is really simple and really small. It also has a startup time somewhere between 1.5 and three seconds. Yes, it is fast. And this these these figures were taken on my MacBook Pro. I think it's a 2018 i9 6 core 32 gig. So not not the smallest one. So it is yes, it is is okay is fast by it. There are faster options there. And the initial heaps of usage. So I used your kit to to look into, okay, I'll start what does the usage look like. It is the biggest wave spring. It's 200 megabytes. And then you see the other figures on here. So the clear winner on the jar size and the startup time is definitely Yobi. So for Yobi, I had to implement some small help us which slowed it down already to get the time out. So it's it's somewhere in the middle seconds, it's really fast. And the smallest jar size because your be doesn't come with loads and lots of dependencies. I was a bit surprised about the heaps usage but we will see that it will go down a bit later on. And here we go with the memory usage once I did a request and a request here returns roughly 300 or 350 results. So I had a couple of ours as feeds I collected from a net politic.org and from from Spiegel and just put the some some details from there into a database. And I will I think release this code as well. Later on anyways. So going on here. So the winner here is if you look at into the heap usage, it's essentially it's K2R, which then cleans up the space rather nicely. And also when I use getling to to request, I think 100, well, do the same request with ramping up using the number of 100. It's still doing well on the heap usage. So it doesn't have lots of memory going around. So I was a bit surprised about the Yobi bit here. But beside this, it's still in the middle field and spring is in the middle field as well just to keep an eye on it here. Right. So also what we have here is I did the load test for what I mentioned earlier. And if we look into the figures of the screenshots of the console load tests I did from my local machine via DSL connection to a the implementation running in the Docker container on a Linux instance. And we can see here that spring is essentially returning let me get the numbers straight. It's returning 25. Okay. And 957 requests fail, which is interesting. The same thing we see on the Linux, so essentially a more beefy connection to which we are on the same data center. And we see that it takes definitely over 1200 milliseconds to complete, which is rather slow, but I didn't optimize this as I said, it's a blunt implementation. And yeah, so we see that it's not that reliable in this case without us doing a lot of things. And I should change the slides on here as well. Here we go. This is the Kato implementation. This already looks a bit better, slightly. So we do get back 93. Okay. And 97 failed. And on from lino to lino instance, it's quote unquote only 77% failing. For my chrono it's improving compared to Kato already. And especially compared to spring. So we get 197. Okay. Back and from local to the Linux instance and from lino to lino. And I'm not getting sponsored for by the word. Sorry. It's 267. Okay. Which brings us to 77% failure rate. And with Yobi surprise, this is really, this was definitely a surprise. So we have the success rate or the failure rate from lino to lino goes down to 38%. So we get more successful responses back than errors. Again, this is not optimized whatsoever. It's just running in a Docker container getting hit after a few warm up requests. So what does this mean in the end? So this means that spring is not necessarily so bad as many people want to see it. And it might be just fine. But if you start a new project, I would definitely recommend to look into Kato or Yobi because Kato because of its well, Kotlin rules. And because there's a lot of work going on, especially on the optimization part of self optimization. And Yobi because it's, it's really, it's a nice one. And I would like to see this grow. And as you can see, it's, it's from the reliability bit. Yeah. So with spring, it gives us a good feature resource balance. And Kato solid, as I just mentioned, it's, it's definitely it's far away from things you might find with not mature and not production ready. Yes, it is production ready. It's continuously getting better. There's a huge community behind it and it growth grows and grows. And definitely have a look into this. And it's, it's fun to use micron out. It's if you need something more complete. So like, like the, the spring approach, but a bit faster, have a look at my criminal. It feels okay. Documentation looks a bit ugly, to be honest, but it's, it's designed, but the content looks okay and helped me out. And the annotation processing helps a lot. And lastly, Yobi's definitely promising. So as you saw, it's, it's, it's fast. It's a result. It gives us a lot of, of, what's the word? Flexibility. This brings us to the end and to the questions. So thanks for bearing with me. Thanks for going with me through this and shoot away. Yeah, I think we okay. So hi everyone. Thank you very much for being as live. I want to say thank you to Olga for the amazing talk. Also, I catch the opportunity to thank you for doing a lot of Q&A's with other speakers today. And but now it's time for questions for your talk. And we have quite a lot. So one came from the last minute and it's from Nicholas. Yes. And he asks, why didn't you evaluate Quarkus? Really, just, I had to limit myself. And I didn't manage to squeeze Quarkus in. I have Quarkus on the radar as well. And I will take this opportunity to, to improve the talk on this one as well, or have a single talk on this. Yeah, this I can and say about, I can say about it. I haven't used it yet. I know it's around. And I know I've got some traction. So yeah, there was nothing, nothing, the theories behind it. Okay, so the next question, that's from me. I have to admit that I played a little bit with Spring and so on. But I saw that there is this tool on on Start Spring I O that allows you to sort of like bootstrap a project. And there is the opportunity to be coupling. Have you ever tried it? What was your experience? Do you think it's valuable for people that want to onboard? Yes. So essentially, you have three easy ways to start. It's either start Spring I O, or it's the, the, it's in the Spring CLI you can install. It's essentially a command line interface to the same things. Start Spring I O gives you and you can use IntelliJ, the, the Spring start. I'm not sure about the clips. I'm pretty sure they use a similar thing. And it all gives you the same essentially. So it's, it's, it's growing. If I compare it to early times with Spring, and you can now configure nearly everything. And you can decide if you want to have a, as a zip file, or if you just want to have a, as a plane directory when you use the CLI. And you can choose between Gradle or Maven. You can then if you use Gradle, you can choose between Gradle, between KTS and, and, and Ruby is also normal Gradle build files. It's, it's really easy to, to kick off there. And from, from my experience, just, just as a, how I approach it, I usually go with the minimum setup, which is either a web project or a REST project, or a REST interface project. And then just add the things I need afterwards. So step by step, because you get quite a lot of dependencies in, which is not bad, but you don't always need them. So, but yeah, it's, it's a pick and choose. It's definitely worth using. And it's, it's making things much easier. Awesome. So we'll give it a try. Yeah, then there has been a lot of interesting discussion going on, on, on the channel actually invite people to join the talk, private talk in some minutes, if you want to even chat directly with Olga. I should have, I should have given, I should have given a trigger warning to Nicholas. I forgot about this. Sorry, Nicholas. We picked some, some messages that got upvoted. And one is about pros and cons to what you talked about, if you're using GraalVM. Can you, can you talk a little bit in depth about that? I can, I can tell you, I didn't use it yet. I, I saw a lot of also things around GraalVM. I never used it so far. And I might be wrong on this one, as I said, I haven't used it yet. But last time I looked a bit into how it was like, Spring isn't completely capable of running in GraalVM. It might be wrong by now or there might be a cookbook, cookbook somewhere describing what you have to do to use it. But I think especially the whole reflection part, Spring makes, what makes Spring so magical and easy to use was not quite comfortable with Graal. And I'm happy to take the opposite things. And with some things, I would be highly interested in this, but I haven't, yeah, this all I can say to Graal. Okay. So there was also a bit of discussion around the Springfoo. And it like, again, what do you, what can you say about it? So Springfoo, thanks a lot for, for bringing this up. Yes, it is, it is more a incubator or sandbox environment. And then so new Spring things grow in there. And there is quite a lot of work going on. I remember a talk in late 19, I think I've seen where they already worked on a more diesel-like approach for the, for the whole web routing. I know with one of the newer features, newer versions of Spring Security, we get a more Kotlin-like diesel for Spring Security, finally, which will make, well, formatting the security configuration much easier. So it's actually, we can actually read it. So yes, it is definitely worth looking into this one. So thanks for, for clarification on this one, Nicolas. Yeah. Yeah. And then the last point was about the actuator. So, yeah, added to the list of pros in Spring Boot. Would you add it to the list of pros? Yes, no, why? Yeah, it's a definite yes, no. So yes, it is definitely, it's one of my favorites as well. Just to give a quick intro, because we had this discussion shortly before this year. So what actuator is, it gives you a really nice, easy way of plugging in a module which enables a lot of monitoring and metrics in your code. So you get a, things like a health interface, you get a ping interface, you get some, some, some basic metrics around how many requests come in, and it gives you a framework on what, how to easy add your own metrics, which we also use in a couple of projects before, or sorry, in a couple of projects before I worked with, where we put in some, some business metrics as well to just have them handy and have them, then request by other things. And yes, it's really easy to plug in with Spring Boot 2, the actuator project, switch to micrometer, which is now more or less the, the implementation for doing metrics. And with this, it's usually easy to use, to have the same thing in all the other frameworks. So there is for K2O4, I think Yobi even also have a ready to use layer for it. MicroNaut definitely relies on it as well. So it's everywhere, it's micrometer. So yes, it is good. And yes, it should be a pro, or could be a pro on the list. On the other hand, you can have the same thing with maybe a little bit more of overhead of implementing it, a really, really small impact if you use any other project.
 Hello and welcome to This Spring Shall Be Challenged, does it have to be spring all  the time. My name is Hager Schanhoer, this is my very first talk, so please bear with  me and enjoy the talk. A few words about me. I'm a professional developer for over 15  years now, so I started coding in the fourth grade and then, well, the rest is history  as they say. I really, really enjoy it. I'm more than a decade on the JVM, so back in  2009-ish, I started to use Java mainly and since 2019, I'm totally in love with Kotlin  and had quite some projects with it. I'm also the founder of Schanhoer Software, so we are  a consultancy company providing new services around selecting text stacks and implementing  services and we are remote first, so if you're looking for help for your projects or need  some support in finding your text stack, just get in touch. Beside this, I'm also co-organising  the virtual Kotlin user group and the Kotlin user group and I do support for quite some  time now, the Java event. I will put some links for these things into the, I think it's the  last slide, so if you're interested, just check them out and get in touch if you have  questions. Also, and last but not least, I'm also a podcaster, so my podcast is coding  with Holger, the link is at the end as well and I do feel like I want to do one or two  more, so let's see what time permits. Right, so what are we after today? Today, we will  have a quick view on how I see, so it's a really opinionated view on how current projects  are essentially specced or how the decision comes to place on what to use, which usually  means spring. Then I will show you what the challenge will be. It's don't be too excited,  but it is taken from a real world project I just worked on recently. I will introduce  it to the contenders and show you the findings I had during really, really lovely time implementing  the same thing over and over again in four different frameworks and give you a very opinionated  and well, yeah, a very opinionated conclusion on what I found out. So what I see in projects  nowadays is that if they are not already in progress, I see loads of managers deciding  on what frameworks to use or technology to use and this is usually based on Google results.  Interestingly, this was one of the first projects here in Germany I did as a freelancer, so  they wanted to change their text tag and they did some Googling, so they thought they want  to go with Kotlin, which was great, but at the same time they said we have to use spring,  which turned out to be not the best decision. Spring is usually seen, besides Agile in  Germany, to be a silver bullet and I would strongly disagree with it. We will see some  interesting findings towards the end of the talk, but it doesn't need to be spring all  the time on the backend. And also what I see is that a lot of companies are more concerned  of finding framework followers, so people considering themselves as a React developer  or as a Spring developer, rather than software developers with experience on the back, all  front and side of things and having worked with a couple of frameworks, so being able  to switch between frameworks, which by the way I don't like, obviously. So what's the  challenge? The challenge is very simple. So I want to have a simple rest endpoint. It  will be a get endpoint and it should return a list of articles with some data attached  to it and this data is all hold in a database. A relational database in this case, it doesn't  really matter a lot, but just mentioning it, I'm more fan of the traditional relational  database, which would be a completely different talk in itself. But yeah, so it will be this  one and it looks simple, but it turned out in this project I mentioned before, I teased  before, that this was already point of interest for my previous client, one of my previous  clients. So they thought that there must be something quicker, it must be possible to  be, to have a quicker response. This essentially spawned the idea for this talk. The output  will be JSON, so there is some transition or some transformation involved and we want  to have authentication. For the sake of this demonstration, it will be basic authentication,  but essentially we don't want to have all our services exposed without authentication,  right? So I should stop clicking buttons randomly on here, sorry. So what are the contenders?  The contenders are four, two, four, yeah, four different frameworks, including Spring.  And how did I select them? So besides them being in the media or in one or more projects  of myself, I had a couple of requirements to them, so they should be easy to use and  easy on the resources. So I don't want to spend too much time on setting things up,  so get all the dependencies together and I have to choose the right versions and all  these things. This needs to be easy. And also at the same time, they should be easy on the  resources, which means I don't want to be, well, in charge to do a lot of optimizations  from the very beginning to get them to perform quickly. And yes, we will have to optimize  and yes, we have to look into how we code things. But just spoiler, in this case, the  implementations I did, and I will give you a link at the end to the code to it, so you  will see it's rather easy or simply implemented. This is on purpose, so I didn't want to do  any optimizations. I want to see how these frameworks perform, if done bluntly. They  should support Gradle, because I like Gradle, because in Gradle, I can have my build file  in Kotlin script, but this is a personal taste and it would be funny if they support me,  and they usually do, so Gradle was a bigger thing. And they should have Kotlin examples.  Well, Kotlin examples, Kotlin bits in the documentation, if they aren't Kotlin or pure  Kotlin by themselves like Ktor. And from time to time, we do have, we can deal with configurations  or with code differently in Kotlin than we do in Java. So I want to see how we can use  them in Kotlin or quickly copy and paste things to get started quickly. They should provide  bootstrapping. This is what I meant with, what I mentioned earlier already with easy  to use, for example, or it falls into this category. So I want to have a CLI or a web  service like the starter, ProRestart, Spring IO, I think it is. So the initial setup where  I can say I want to have a web server or I want to have whatever and get a basic project  created again. So I don't want to have to copy all the, I have to type all the dependencies  and get the right versions. They should be open source, of course. We all love open source.  This is one of the reasons why we are here at Foster, right? And at the same time, I headed  over and over again that open source literally saved my vacant because I could fix bugs or  I can contribute back by fixing bugs. On top of this, all the frameworks should have support  for authentication. For example, all off sessions, the more easy the better, the easier the  better it is. And last but not least, this is also something I learned very early on.  It's always good to have metrics collected. So they should, all the frameworks should  provide us with metric collection capabilities. So if we think of Spring, it would be a trader  where it's a matter of adding a dependency and then get things like a health endpoint  or an endpoint to collect information about a number of requests and all these things.  And it's easy to extend. They should provide something like this as well. And most, more  or less, it's usually done in micrometeon nowadays. So what a plus we need some little  helpers for our contenders. And I chose a couple of things you might be or might not  be aware of. So one of the things is E-Bean. E-Bean is a, I think, underdog in the ORM  space. And I particularly like the query being subproject of E-Bean. I will show you in a  minute. And we use this SNOM. And this, I chose this because I can use this in all of  the frameworks either directly or by just using it. I also use coinDI, a dependency injection  for the frameworks which do not come within own IOC container, I use Gatling for some  basic performance load tests. And Kenny is in front of the service on my Linux VM I used  to do some load tests to get a bit more of a realistic view on it. So I didn't optimize  it by essentially spun up a couple of Linux VMs, one with a Postgres database, one with  Docker on it to run the applications in the Docker container and one to run the Gatling  tests to get a little bit more fire under the hood. So let's switch to some code. This  is the project I will give you a link to. So if we look into the structure, you will  already see what you will find the contenders, your wikator, micronaut spring. There's the  performance bit which is the load testing part and shared which holds all of our really,  really highly sophisticated code for the ORM which is essentially composed out of two bits.  So if we look at this, we have the base model which brings ID and versioning. And we do  have two instance which essentially holds information about when a particular entry was created  and when it was modified. So nothing really exciting here but you can see that eBean  provides a very JPA-ish, can we get this? Here we go. JPA-ish annotation support. So  essentially we have this in here and behaves near the same as hibernate and when created,  then modified our nice little extra features. And then we have all of our domain models  in this little class here or this little file. So essentially we have an article which I  already mentioned. It has to have a title. And then it can have an abstract, so essentially  a short description on what's going on in here. It will have for the sake of this demonstration  one image attached to it via a foreign key. It will obviously have a body. I can have  once it's done and it has a publication date and a couple of keywords attached to it. An  image is, this is a really, well, a stripped down version of what I had in the real project.  For now it only has a file name and original name of an image. So this was much bigger  in the other project, but just to keep this as roughly comparable to what I had before  and keywords are essentially just a set of additional tags, keywords, categories as  you want to call them or however you want to call it. And this is all we need for our  OIRM. We do use, so if we go back here, so if we check this, our eBean comes, our query  bean comes with a query bean generator which uses the Kotlin annotation processing tool.  So this gets generated either by a extension in your IntelliJ or Eclipse or via gradle if  you use gradle to build it and then they use kept. So this generates code and we will see  this in a second, which generates all the needed stuff. So in comparison to Hibernate  this doesn't happen to runtime. This happens during compile time which is a huge performance  improvement. And performance tests I mentioned before, just a quick glimpse in here. It's  really, really, it's simple. So we set up the HTTP protocol in here. We point it to  a endpoint and then give it a scenario, the scenario in here just says, okay, get all  the articles from this endpoint here. And we want to have ramp up user numbers of up  to 1000 within a minute and it shouldn't take longer than two minutes at all. And then we  run this against the, in this case, the remote instance. That's all we need on this bit.  So let's head on. So the contenders here we are with Spring Boot and I use Spring Boot  in well as I refer to it as Spring Boot. But what I do mean is essentially all the Spring  Project Spring Boot combines and bundles with the correct version numbers, right? And we  do have some pros and cons on mostly all of the other contenders and with Spring Boot,  you all know it, it's around for quite some time. It has a really, really good documentation  out there. So if you look into the documentation given by the project itself, but also if  you look at pages like Belldom, it's end-on-one-stack overflow. So we have quite some resources  there. And it has a huge community which also contributes to documentation and help. And  it's backed by VMware. So yes, it is still part of Pivotal, but Pivotal was bought by  VMware quite some time ago. So it has a big backer there. It's on the other hand also  on the cons side, it is rather heavy on the reflection part. So nearly everything, all  of the quote unquote magic happening in Spring happens during runtime via reflection via  annotation processing in memory. So this takes quite a hit on the performance side.  At least we say so. And it comes with loads of dependencies. We will see this in the size  of the FET jar we produce with the simple Spring implementation. It comes with loads  and loads of Java baggage. So it is initially written in Java because it was a contender  or a competitor to Java E back in the times. And it still has. So they do love Kotlin.  They say this and they show this. So for example, with Spring Foo, we get a more Kotlin like  DSL for all the things. But also Spring security, for example, with the next version, they come  out with a diesel like approach to configure your security, which will be nicer to do,  right nicer to read. So everyone who tried to set the security up and get this form in  a readable way will know what I mean. Last but not least, it's slow on the startup. And  yes, with Spring Boot 2, they improve this a lot. And I mean a lot. But it's still one  of the slows out of the bunch. If we look into the implementation, it's rather straightforward.  It's all what you would expect from a Spring framework as a Spring project. We have our  well, hooking point or our startup point, we have a simple class which is annotated.  Then we just started and we have a classic MVC pattern. So the controller holds the  rest controller logic. Well, logic, it's a map to slash article and we say, okay, get  mapping here. So this is get endpoint, which calls in turn the article service, which is  auto-wired in the DIContainer we use or used in here is the one from Spring. Then it goes  into the service, which does a lot of really fancy business logic in the form of calling  the repository and returning the result. And then we see Qwerubin's in action. So the subproject  I mentioned from eBeam, we essentially say QRTiql, find list. So this returns an empty  or filled list and QRTiql is generated by kept or by the enhancement program in this  case IntelliJ and returns all the articles as a list. So this is more or less the whole  magic to get this work. And on top of this, we need it, as I mentioned before, I wanted  to have a basic authentication. We need the configuration. So this is something where  you have to know Spring, it's a bit clunky, but if you have only one configuration, it's  fine. If you have multiple ones, you have to know or you might have to tweak it. You  have to be careful on the order these get loaded and all these nice things. So here  it's really simple to say essentially just we say on HTTP security, we want to have  all requests should be authenticated. We use HTTP basic authentication is what I wanted  to say. And we have something here, which is also you have to know it right. So we need  a bean which is then used automatically by Spring, which implements the user details  service interface. And this provides us with a user details manager. And yes, this is the  mouthful, but essentially this here says, okay, we have these two users and this user  then has a role. And we use the memory variant of the user details manager. This can be  this can get much more complex, but this is more or less all eight. And with this here,  we say everything we have in the controllers, but whatever we define in the controllers  will be suspect to the HTTP basic authentication bit. So going back to the next contender,  it's Ktor sorry for rushing through, but I have to keep an eye on the time. So with Ktor,  which is really interesting because I couldn't find any comments, at least not at this stage.  One of the very, very big pros is it is pure Kotlin, which just feels and it just feels  right. So if you use Kotlin, Ktor is definitely nice. Definitely worth have a look into it.  It has a really good documentation. So JetBrains and all the other additional contributors,  they did a really good job. It's easy to pick up. They have lots and lots of different  examples in there for all the combinations you can think of. It's really nice. This also  shows how active the community is. Check out the Kotlin Slack Kotlin links like in this  case as well. You find lots of help on there as well as well as on Stack Overflow. And  it's backed by JetBrains. So JetBrains has a vital interest in keeping Ktor alive to  position Kotlin on the backend. And you can feel that Ktor gets a lot of love there from  the Kotlin folks at JetBrains. Before we get to micro now, let's have a look at where's  my mouse? Here's my mouse at the code. So let's get this close here and have a quick  look into Ktor. It will look very familiar. So essentially we are used coin in here because  Ktor doesn't come with its own IOC container. So in the coin space we have to, or we can  define modules which then in turn just define what is it what we inject and we say, okay,  we want to have single items of these types and the implementations are this one. We could  essentially do more fancy things in here, simple numbers, but it's all I needed in here.  And then we go in here. So the actual application module we extend here or we implement here  is the whole setup for the Ktor implementation I did. We do install coins. So Ktor comes  with a module on an application extension for a supporting coin directly. So I didn't  have to do or we don't have to do any initialization bits. We want to have content negotiation.  So we want to be able to say what goes out of our controllers. This will be always JSON  this case, but it's nice to have in here and it's easy to configure. You can see here it's  rather explicit and then the next bit is already the authentication part. And authentication,  especially basic authentication is rather easy. So we have it here. So we say we have  authentication installed here and we say we have a basic authentication, give it a name  so that we can have multiple authentication configurations. And then in the basic part  we can, we have to implement the validate, which essentially just can check the credentials  either hard or against hard strings like here, or we can delegate it against databases. And  then we get into the implementation. So we need the article service injected here. So  this is coin network and we have routing. So this is a pattern we will see with the  other frameworks as well. So we define routes. And I think with spring we can already do  this or we might be able to do this soon with spring through or one of the upcoming spring  and we see bits, but don't point me down on this one. And we say, okay, we want to have,  so this part of the routing is needs authentication. We map the authentication against the authentication  we did up here. And we say, okay, we have one get endpoint, which is slash article slash  and then we want to respond with the result of whatever the service gives back. So called  respond is already K to R. And then the rest is something which will look familiar because  it's doing the same thing. So we have article service here. And this called the repository  or gets the repository injected and then calls a repository to get everything. And we use  Q article find list again, right? Cool. So then we get to micronaut. Micronaut looks  very similar to spring. So it comes with with lots and lots of additional, additional projects  like spring. So for example, they have micronaut data, which is well inspired by spring data  or real rails. And they come with their own IOC container and all these bits and box.  But the big thing which distinguishes micronaut from spring is they use the as well the kept  capability. So they do annotation preprocessing during build time. So we get all the things  spring tries to figure out during runtime during compile time and then have a faster  runtime. And this also results in the fast startup. So definitely faster than spring.  And it's backed by its own company object computing. I think they do consulting as well.  The only con I could find is it brings some Java baggage. So again, we have the to deal  with not quite so straightforward nonability. And one or two other things we have to be careful  with looking into the implementation and keeping an eye on the time. We should go into too  much detail, but essentially micronaut then looks very similar. So I tried to stick to  the same thing here. So we this is the startup. So we it's it's build a pattern they use.  We can configure most of the things here. We need to to to get this thing rolling. We  say the controller is in we use what's called packages. We say look into these controller.  So we have the controller here and this looks already very familiar. So with the micronaut  comes with its own set of annotations, which are then interpreted by the kept plugin and  we have the one thing I had to look at is how to do the authentication, which wasn't  that straightforward. But I found a basic example and adopted it. So the example they  deliver with or might not delivers in code is a really simple authentication basic authentication  provider, which checks that the username equals the password. And I did use this one to create  this authentication provider, which then checks for our authentication details we saw before.  The rest is the same except that we don't use coin, but the the icon to our IOC container  from micronaut. And we see here again at singleton is comparable to at compartment at on the  spring side. Going further, so Yobi is my my secret favorite. I came across Yobi thanks  to a good colleague of mine. And it flashed me how fast it really starts up. And it's  really, really, really fast. And I should stop using really, but it is really fast. And it  comes with a minimal setup. So it's it's it's really just bare minimum we need to get something  running and working. And it comes with a very Kotlin eskity as a  that's really it's it's rather nice to use. And they have a mindset of using thin extensions  extension layer. So we we delegate the work we want to do outside of simple  HTTP request mappings and implementing features to whatever we whatever frameworks we want  to use. So for example, the the container I use is coin, they don't have a dedicated  extension for this but it's easy to set up. But they have a thin layer fordues, for example,  and they do have a pack for J P a C for J extension, which then is used for the authentication  bit and pack for J is a huge well, Java based but it's a huge authentication framework.  The cons the documentation is very spotty. So if you if you look for for things and you  always have to be careful if it is for version one dot xx or two dot xx. And this makes it  a bit hard at the beginning. It seems to have a small team. It's not that big, but I hope  they grow. I think they also start to create a company around your B and with two dot xx  they throw away loads of integrations they had for one xx because they changed the way  the extension works. And this is again coming back to the spotty documentation of the easiest  bit plus it you'll be now says it's a Java and Kotlin back in framework or micro framework,  but it still has loads and lots of Java baggage because yes, it is written in Java, but I  spotted a couple of of Kotlin implementation bits there already. So what did I find? I  hope you don't mind that I'm not going into the code, but I have to keep this short. So  I found that obviously, well, if you look at the initial jar size and start up that obviously  what was what we essentially could expect that spring has the biggest jar size. So it's  it comes with lots and lots of dependencies. So they take their their toll on this one  with 27 megabytes is not the biggest one. But keep in mind that this example is really  simple and really small. It also has a startup time somewhere between 1.5 and three seconds.  Yes, it is fast. And this these these figures were taken on my MacBook Pro. I think it's  a 2018 i9 6 core 32 gig. So not not the smallest one. So it is yes, it is is okay is fast by  it. There are faster options there. And the initial heaps of usage. So I used your kit  to to look into, okay, I'll start what does the usage look like. It is the biggest wave  spring. It's 200 megabytes. And then you see the other figures on here. So the clear winner  on the jar size and the startup time is definitely Yobi. So for Yobi, I had to implement some  small help us which slowed it down already to get the time out. So it's it's somewhere  in the middle seconds, it's really fast. And the smallest jar size because your be doesn't  come with loads and lots of dependencies. I was a bit surprised about the heaps usage  but we will see that it will go down a bit later on. And here we go with the memory usage  once I did a request and a request here returns roughly 300 or 350 results. So I had a couple  of ours as feeds I collected from a net politic.org and from from Spiegel and just put the some  some details from there into a database. And I will I think release this code as well.  Later on anyways. So going on here. So the winner here is if you look at into the heap  usage, it's essentially it's K2R, which then cleans up the space rather nicely. And also  when I use getling to to request, I think 100, well, do the same request with ramping  up using the number of 100. It's still doing well on the heap usage. So it doesn't have  lots of memory going around. So I was a bit surprised about the Yobi bit here. But beside  this, it's still in the middle field and spring is in the middle field as well just to keep  an eye on it here. Right. So also what we have here is I did the load test for what I mentioned  earlier. And if we look into the figures of the screenshots of the console load tests I  did from my local machine via DSL connection to a the implementation running in the Docker  container on a Linux instance. And we can see here that spring is essentially returning  let me get the numbers straight. It's returning 25. Okay. And 957 requests fail, which is  interesting. The same thing we see on the Linux, so essentially a more beefy connection  to which we are on the same data center. And we see that it takes definitely over 1200  milliseconds to complete, which is rather slow, but I didn't optimize this as I said,  it's a blunt implementation. And yeah, so we see that it's not that reliable in this  case without us doing a lot of things. And I should change the slides on here as well.  Here we go. This is the Kato implementation. This already looks a bit better, slightly.  So we do get back 93. Okay. And 97 failed. And on from lino to lino instance, it's  quote unquote only 77% failing. For my chrono it's improving compared to Kato already.  And especially compared to spring. So we get 197. Okay. Back and from local to the  Linux instance and from lino to lino. And I'm not getting sponsored for by the word. Sorry.  It's 267. Okay. Which brings us to 77% failure rate. And with Yobi surprise, this is really,  this was definitely a surprise. So we have the success rate or the failure rate from lino  to lino goes down to 38%. So we get more successful responses back than errors. Again, this is not  optimized whatsoever. It's just running in a Docker container getting hit after a few warm up  requests. So what does this mean in the end? So this means that spring is not necessarily  so bad as many people want to see it. And it might be just fine. But if you start a new project,  I would definitely recommend to look into Kato or Yobi because Kato because of its  well, Kotlin rules. And because there's a lot of work going on, especially on the optimization  part of self optimization. And Yobi because it's, it's really, it's a nice one. And I would like  to see this grow. And as you can see, it's, it's from the reliability bit. Yeah. So with spring,  it gives us a good feature resource balance. And Kato solid, as I just mentioned, it's,  it's definitely it's far away from things you might find with not mature and not production  ready. Yes, it is production ready. It's continuously getting better. There's a huge community behind  it and it growth grows and grows. And definitely have a look into this. And it's, it's fun to use  micron out. It's if you need something more complete. So like, like the, the spring approach,  but a bit faster, have a look at my criminal. It feels okay. Documentation looks a bit  ugly, to be honest, but it's, it's designed, but the content looks okay and helped me out.  And the annotation processing helps a lot. And lastly, Yobi's definitely promising. So as you  saw, it's, it's, it's fast. It's a result. It gives us a lot of, of, what's the word? Flexibility.  This brings us to the end and to the questions. So thanks for bearing with me. Thanks for going  with me through this and shoot away.  Yeah, I think we  okay. So hi everyone. Thank you very much for being as live. I want to say thank you to Olga  for the amazing talk. Also, I catch the opportunity to thank you for doing a lot of Q&A's with  other speakers today. And but now it's time for questions for your talk. And we have quite a lot.  So one came from the last minute and it's from Nicholas. Yes. And he asks, why didn't you evaluate  Quarkus? Really, just, I had to limit myself. And I didn't manage to squeeze Quarkus in. I have  Quarkus on the radar as well. And I will take this opportunity to, to improve the talk on this  one as well, or have a single talk on this. Yeah, this I can and say about, I can say about it.  I haven't used it yet. I know it's around. And I know I've got some traction. So yeah,  there was nothing, nothing, the theories behind it. Okay, so the next question, that's from me.  I have to admit that I played a little bit with Spring and so on. But I saw that there is this  tool on on Start Spring I O that allows you to sort of like bootstrap a project. And there is  the opportunity to be coupling. Have you ever tried it? What was your experience? Do you think  it's valuable for people that want to onboard? Yes. So essentially, you have three easy ways to  start. It's either start Spring I O, or it's the, the, it's in the Spring CLI you can install. It's  essentially a command line interface to the same things. Start Spring I O gives you and you can use  IntelliJ, the, the Spring start. I'm not sure about the clips. I'm pretty sure they use a similar  thing. And it all gives you the same essentially. So it's, it's, it's growing. If I compare it to  early times with Spring, and you can now configure nearly everything. And you can decide if you want  to have a, as a zip file, or if you just want to have a, as a plane directory when you use the CLI.  And you can choose between Gradle or Maven. You can then if you use Gradle, you can choose between  Gradle, between KTS and, and, and Ruby is also normal Gradle build files. It's, it's really easy  to, to kick off there. And from, from my experience, just, just as a, how I approach it, I usually go  with the minimum setup, which is either a web project or a REST project, or a REST interface  project. And then just add the things I need afterwards. So step by step, because you get quite a  lot of dependencies in, which is not bad, but you don't always need them. So, but yeah, it's,  it's a pick and choose. It's definitely worth using. And it's, it's making things much easier.  Awesome. So we'll give it a try. Yeah, then there has been a lot of interesting discussion going on,  on, on the channel actually invite people to join the talk, private talk in some minutes,  if you want to even chat directly with Olga. I should have, I should have given, I should have  given a trigger warning to Nicholas. I forgot about this. Sorry, Nicholas. We picked some,  some messages that got upvoted. And one is about pros and cons to what you talked about,  if you're using GraalVM. Can you, can you talk a little bit in depth about that?  I can, I can tell you, I didn't use it yet. I, I saw a lot of also things around GraalVM.  I never used it so far. And I might be wrong on this one, as I said, I haven't used it yet.  But last time I looked a bit into how it was like, Spring isn't completely capable of running in  GraalVM. It might be wrong by now or there might be a cookbook, cookbook somewhere describing what  you have to do to use it. But I think especially the whole reflection part, Spring makes, what makes  Spring so magical and easy to use was not quite comfortable with Graal. And I'm happy to take  the opposite things. And with some things, I would be highly interested in this, but I haven't,  yeah, this all I can say to Graal. Okay. So there was also a bit of discussion around the Springfoo.  And it like, again, what do you, what can you say about it?  So Springfoo, thanks a lot for, for bringing this up. Yes, it is, it is more a incubator or  sandbox environment. And then so new Spring things grow in there. And there is quite a lot  of work going on. I remember a talk in late 19, I think I've seen where they already worked on a  more diesel-like approach for the, for the whole web routing. I know with one of the newer features,  newer versions of Spring Security, we get a more Kotlin-like diesel for Spring Security, finally,  which will make, well, formatting the security configuration much easier. So it's actually,  we can actually read it. So yes, it is definitely worth looking into this one. So thanks for,  for clarification on this one, Nicolas. Yeah. Yeah. And then the last point was about the actuator.  So, yeah, added to the list of pros in Spring Boot. Would you add it to the list of pros? Yes, no, why?  Yeah, it's a definite yes, no. So yes, it is definitely, it's one of my favorites as well.  Just to give a quick intro, because we had this discussion shortly before this year.  So what actuator is, it gives you a really nice, easy way of plugging in a module which enables  a lot of monitoring and metrics in your code. So you get a, things like a health interface,  you get a ping interface, you get some, some, some basic metrics around how many requests  come in, and it gives you a framework on what, how to easy add your own metrics, which we also use  in a couple of projects before, or sorry, in a couple of projects before I worked with, where  we put in some, some business metrics as well to just have them handy and have them, then request  by other things. And yes, it's really easy to plug in with Spring Boot 2, the actuator project,  switch to micrometer, which is now more or less the, the implementation for doing metrics. And  with this, it's usually easy to use, to have the same thing in all the other frameworks. So there is  for K2O4, I think Yobi even also have a ready to use layer for it. MicroNaut definitely relies on  it as well. So it's everywhere, it's micrometer. So yes, it is good. And yes, it should be a pro,  or could be a pro on the list. On the other hand, you can have the same thing with maybe a little  bit more of overhead of implementing it, a really, really small impact if you use any other project.
this_spring_shall_be_challenged_0_155.png this_spring_shall_be_challenged_156_431.png this_spring_shall_be_challenged_432_2531.png this_spring_shall_be_challenged_2532_3839.png this_spring_shall_be_challenged_3840_5975.png this_spring_shall_be_challenged_5976_6023.png this_spring_shall_be_challenged_6024_7583.png this_spring_shall_be_challenged_7584_8027.png this_spring_shall_be_challenged_8028_8159.png this_spring_shall_be_challenged_8160_8231.png this_spring_shall_be_challenged_8232_15851.png this_spring_shall_be_challenged_15852_15947.png this_spring_shall_be_challenged_15948_15995.png this_spring_shall_be_challenged_15996_16535.png this_spring_shall_be_challenged_16536_16583.png this_spring_shall_be_challenged_16584_16655.png this_spring_shall_be_challenged_16656_17267.png this_spring_shall_be_challenged_17268_17687.png this_spring_shall_be_challenged_17688_19391.png this_spring_shall_be_challenged_19392_19439.png this_spring_shall_be_challenged_19440_20651.png this_spring_shall_be_challenged_20652_21347.png this_spring_shall_be_challenged_21348_24995.png this_spring_shall_be_challenged_24996_25283.png this_spring_shall_be_challenged_25284_29063.png this_spring_shall_be_challenged_29064_31091.png this_spring_shall_be_challenged_31092_31235.png this_spring_shall_be_challenged_31236_31559.png this_spring_shall_be_challenged_31560_32255.png this_spring_shall_be_challenged_32256_32315.png this_spring_shall_be_challenged_32316_32399.png this_spring_shall_be_challenged_32400_33995.png this_spring_shall_be_challenged_33996_34091.png this_spring_shall_be_challenged_34092_35243.png this_spring_shall_be_challenged_35244_35675.png this_spring_shall_be_challenged_35676_37583.png this_spring_shall_be_challenged_37584_38651.png this_spring_shall_be_challenged_38652_39515.png this_spring_shall_be_challenged_39516_39839.png this_spring_shall_be_challenged_39840_43211.png this_spring_shall_be_challenged_43212_43295.png this_spring_shall_be_challenged_43296_45623.png this_spring_shall_be_challenged_45624_47243.png this_spring_shall_be_challenged_47244_50699.png this_spring_shall_be_challenged_50700_50771.png this_spring_shall_be_challenged_50772_51695.png this_spring_shall_be_challenged_51696_52247.png this_spring_shall_be_challenged_52248_52799.png this_spring_shall_be_challenged_52800_53123.png this_spring_shall_be_challenged_53124_53351.png this_spring_shall_be_challenged_53352_53423.png this_spring_shall_be_challenged_53424_53711.png this_spring_shall_be_challenged_53712_54167.png this_spring_shall_be_challenged_54168_56159.png this_spring_shall_be_challenged_56160_56267.png this_spring_shall_be_challenged_56268_58955.png this_spring_shall_be_challenged_58956_60167.png this_spring_shall_be_challenged_60168_62135.png this_spring_shall_be_challenged_62136_62315.png this_spring_shall_be_challenged_62316_65531.png this_spring_shall_be_challenged_65532_65655.png