 Hello developers! My name is Matt Rable. Today I'd like to show you how to develop a reactive microservices architecture using J-Hipster. If you're a Java developer, you're probably very aware that microservices have really taken off in the last five or six years, mostly because of Spring Boot. And Spring Boot and Spring Cloud have really made it easy to develop a microservices architecture. And with Spring Boot 2.0, they actually brought Spring Web Flux to the table. So let's show you how to use those frameworks to develop a microservices architecture using the awesome open source project J-Hipster. Let's get it up! This screencast is based on a blog post that I wrote back in January. And if you click on the changelog, you'll see that I actually updated it recently for J-Hipster 7.0.1. And so what this blog post goes through is talking about Spring Boot, Spring Security, and how J-Hipster marries all those together to make it easy to generate microservice architectures. Spring Boot introduced a framework called Web Flux to complement Spring NBC. If you're familiar with Spring NBC, it works great for developing many types of job applications and APIs. Spring Web Flux makes it so you can use reactive programming to make your system scale more on less hardware. And so if you have over 500 requests per second, you might want to look into Spring Web Flux. Otherwise, Spring NBC will probably have the same performance up until 500 requests per second. So if you read through this article, you'll see there's a number of topics covered. We're going to build a reactive microservices architecture. We'll define it with JDL. That's J-Hipster's domain language. We'll run it. We'll test it. We'll prepare it for production. We'll make it use Okta for OIDC. Then we'll create Docker images and run it using Docker compose. And then I'll talk a little bit about why or why not you might want to go reactive at the end. So if you scroll down a bit, you'll see there's some examples of Spring NBC's code for creating points, for instance. You'll see it looks pretty straightforward, very synchronous in a sense. And then the same code with Spring Web Flux, you'll see it's more fluid. It uses Streams API for the most part. And you know, it does a flat map and then map and then returns everything from that. So it's non-blocking and it makes things a little bit more difficult to wrap your head around. But like I said, you'll get much better performance at high load. So you will need to have Java 11 and Docker installed to do this tutorial. And I'll show you, you may need to tweak your Docker settings to have a bunch of more RAM than is allocated by default. I think it's two gigs by default. I typically run with anywhere from six to 10. So I do have a 64 gig RAM laptop MacBook Pro. And so if you're able to or you're not able to do the same sort of things, it might be because your memory isn't quite there. So you can see you can find the completed source code for this example on GitHub. And I have that open in my browser here. And I also have a demo.adoc open in that folder. So this is the instructions that I'm going to use that basically just condensed the blog post. So it's, you know, easy to follow. And I'm not copying and pasting out of the blog post. So I wrote it in ASCII doctor. And you can see I can use my handy Danny ASCII doctor plugin for my browser. And it renders quite nicely there. So I'll put that on the left and then go down here. So the first thing you'll need to do is install j hipster generator dash j hipster. And I already have installed so I don't need to do that. I can just run j hipster version. And you'll see I have the seven dot zero dot one version and then Java 11 and node 14. So you'll need all those installed to do this tutorial. And then I will create a reactive stack directory and take does make their and CDs into it. So it's all in one command that comes with oh my ZSH. And then I will go ahead and do get init. And the reason I'm doing this is because j hipster will create different directories for each application in my microservices architecture. And if it doesn't detect, it's going to get repository will create, you know, get repos for each one of those. And we're just going to do it all in a mono repo. I'm going to use this JDL to generate our microservices architecture. You can see at the top here, we have an application that is a gateway, and this will use spring cloud gateway. So in spring boot two dot four, spring cloud gateway is the best way to do any sort of gateway. They've deprecated the use of Zool in spring cloud. So you can no longer use that to develop a gateway with spring MVC. There is an open issue to add spring MVC support to spring cloud gateway. But basically reactive is forced for a gateway. We're using OAuth 2 for authentication. We're using Gradle. And I'm going to use view because that's new in j hipster seven kind of fun to use a new web framework. And then test frameworks is Cyprus. And Cyprus is new in j hipster seven as well, before we just had protractor support. And then you'll see here, we have a blog that we're also going to develop. And that is going to be a microservice. And you must make sure that the authentication type matches, right? So that's where using OAuth 2 again. And then we also have a store. So the store is going to be a microservice as well. The difference is the blog is going to use Neo4j. The store is going to use MongoDB. We're going to use Eureka for service discovery. So we'll use j hipster registry to actually allow all these applications to talk to each other. And then we'll have a number of entities. So you can see we have a blog, a post and a tag. And those are all for the blog microservice. If we were to go up to the blog microservice, you can see them listed right there. And then we also have a product that's just used by the store microservice. And then we have relationships, the blog has a many to one relationship to user, as well as post to a blog. And then many to many posts can have many tags. And then we have pagination rules here at the bottom, as well as a microservice indicator and a deployment type for Docker compotes with this architecture definition, we can actually create everything. So we'll go ahead and copy that. And just to let you know, there's also a JDL samples repository. So in fact, we don't even need to copy this because it's the same one that's in the JDL samples repository. So when you type J hipster JDL, it'll look first on your file system, and then look in that samples repository. So a shortcut we can do is j hipster JDL reactive MS. And even though we don't have it locally, it'll pull it from the samples repository. You can see this took a couple of minutes to generate everything that time will depend on your hardware, your internet connection, as well as whether you're recording a video or not. So usually this is around a minute, but it does create all the applications in parallel. So it's as fast as it can be. The MPM install is what really slows things down. So that does happen for the gateway, because that's where all the UI code is. And so now that we have everything generated, we can start it. And one of the things that J hipster does is it generates Docker containers for all the different things you need that aren't quite in the project. So we have key cloak involved, we have Neo4j, we have MongoDB, and we have the J hipster registry. So first of all, I just want to look at the JDL that was downloaded and make sure that matches, you know, what we looked at earlier. And also to make you aware that reactive true is the basic difference between spring NBC and spring web flux. That's all you need to do to be reactive in your microservices. So you can see it's there for the gateway, the blog and the store. And so we can go into the gateway to start things off, and we can start up key cloak. The long way is Docker compose dash f source main Docker. And it'll start up key cloak for you. I also have a number of shortcuts installed with an oh my zsh plugin that J hipster provides. So from now on, I'm just going to use those commands. So I can start up Postgres with jh Postgres up, and then jh registry up. And one cool command you might find useful is jh registry logs that will tail the logs. So you can see if the registry is starting up and all that that should be enough that we can start the gateway. And then we'll go in and start the blog as well. And we have Neo4j in this. So we need to do jh Neo4j up, start that Docker container, then we'll run our app. And then the last one is the store that uses Mongo. So jh Mongo up, we're still in the blog, go to the store, jh Mongo up, and then start that one with Gradle W. While those are all starting up, I'm going to open up a new terminal just to make sure I have key cloak in my Etsy host file. So you'll see I do at 127 001. That is necessary when you're running everything in Docker. Right now we're running everything, you know, just using Gradle. So it's not an issue yet. But when you get to the Docker phase, what'll happen is it'll redirect to key cloak in the URL. And so that's why you need it here. If you have a better way, and you know, Docker networking, then please let us know if we can fix that, but we haven't found a better solution than that. So now everything's up and running, we should be able to log in. We'll go host 8080 make that a bit bigger. And it redirects us to key cloak admin admin can also use user user. And now we're logged in. If we were to look at our entities, we can see we have a blog and we have some data in there that's from a previous demo I did so I can delete that. You always got to practice before these things right. And look, we even have a product in there. Let's add a new product. I happen to like beer, Belgian beer, which can be a bit pricier. So we'll say $10 for 10%. Add this icon here, you can see it even saves images in your database that alerts coming from view since we're using view on the front end, and everything appears to be working. If we go to the administration, we can see the current routes under the gateway, we can see the metrics for all the timings and how fast things are happening. We can also look at the health of the project and see that everything's up, everything's working nicely. And there's also swagger if we wanted to actually, you know, execute some commands in our browser, we could check out the user's account information, for instance, execute it. And you'll see not only the curl command, but you'll see the response there. So that's all working quite nicely. And we can log out here. Keycloak is a superb OIDC and OAuth solution. It's open source, you can run it in a Docker container. I have no problems with it. I admire it very much. And I love to use it with Jay Hipster. However, going to production, you might need something that's always on and maybe you don't want to manage your identity provider. So that's where octa kind of comes into play. And we use spring security to do our OAuth implementation. So everything happens on the back end. And people have asked about this, why don't you do it on the front end? Why don't you do the authorization in view or angular or react? Well, part of the reason is that if we had to do it on the front end, then we'd have to do it in all three of those various frameworks. And they might not have OIDC libraries that make it happen. Second of all, if you're storing the access token on the client, it's not quite as secure. So that's why we do it on the back end. We do all the OAuth close there, all the OIDC logic, and it just works great. And we don't have to worry about the front end, you know, coding each of those to make it work. So spring cloud gateway makes it very easy to relay and access token between a gateway and the downstream microservices. So it's just five lines of YAML that you can see there. It's just a token relay filter that makes it very easy to implement and very easy to use. And so to make this work with octa, first of all, we'll shut all these down. We can even take keycloak down with jh keycloak down. And in the gateway project itself, we use the octa CLI. So if you don't have the CLI installed CLI to octa.com, that'll get you the information that you need to install it. And I'm going to run octa register, it'll prompt me for my first name, my email, and it'll create a new octa organization for me. And it'll prompt me to verify that that email works. Then I can get my verification code for my email, paste it in. And it's created everything for me. And you can see you can set your password opening this link. So I'll go ahead and do that. There we are. Now we're all set up. We can close that tab and we can run octa apps create j hipster. This will prompt us for an application name. So I'll say reactive microservices. And it'll already know what we need for the redirect URIs. You can see we have the first one is for our gateway app that's going to handle the OIDC authentication. And this is what spring security expects. We use OIDC at the end instead of octa because we want to be generic between key cloak and octa. And then this one is for the J hipster registry. So you can use OAuth and OIDC to log in there as well. So we'll just accept the defaults and accept the post log out redirect URIs as well. So you can see it not only created an app for us, right? That's right here. And it has a client ID, but it also created groups for role admin and role user, which J hipster expects. And then it added our user into those. So if we log in with our user will be an admin. And then it writes it to this dot octa dot ENV file. So you can see our issuer URI, our client ID and our client secret. And the reason we put it into an ENV file is we don't want to check it into source control. So that's what we're trying to prevent. So we can add these settings to our J hipster registries configuration. And what it will do is share those for all the microservices. And how it does that is spring cloud config, it's embedded and J hipster registry. And so all the apps will look for configuration in spring cloud config and use it if it's there. So we can take this value right here, and we'll open up a new terminal, and we'll go into source main Docker, that application dot YML, and go down to the bottom, and we'll add it there. And then we can grab our values from right up here, paste that in there. So now we should be good to go. And if we stop J his registry, or jh registry down, that stops the J hipster registry. Now I have seen this error before. So when it happens, you don't really have to worry about it, you can do Docker PS to see what's still running J hipster registry is not in there. So you can do J hipster registry up. And now make sure nothing's running for Java kill all our microservices. And then we can start everything up again. So in our gateway, we'll do a gradle there. And in our blog, we'll start that as well. And one thing I forgot to mention, even though we installed Cyprus, we didn't run it. So on the gateway, when using key cloak, you could actually run MPM run e to e from the command line in that same gateway directory. And it would do everything and make sure everything worked out that everything started, we can hit local host 8080, make that a bit bigger, and sign in, you'll see it took us to octa. And it logged us in. So you're like, how did that happen? It's because we'd logged in before a member when we changed our password. So if we were to use an incognito window, and do local host 8080, this time you would actually see the octa login screen. So I can enter my credentials, you don't need your whole email, you just need the part before that. And then you can log in that way. And of course, all the entities are still there. And all the data is still there because we didn't change anything, right? We didn't change any of the back end code. You'll see you can use Cyprus to test octa. So I didn't show you how you do it with key cloak, but it's very easy. You just run this command MPM run e to e from the front end gateway. So now what we'll do is we'll stop all of our Docker containers, because we're going to run everything in Docker now. So back here, stop all our apps, and stop all our Docker containers, verify they're all stopped with Docker PS. And now we can build Docker containers for each of our apps. So we use this Gradle command, pass in the prod profile, and boot jar and jib Docker build. So jib is the one that's going to be doing the Docker build. So we'll start with the store, and we'll do the blog. And then we'll do the gateway. While those are all building, what we'll do is we'll modify the Docker compose file that was generated. First of all, we don't need key cloak anymore, because we're just going to run with octa. And then there's a different place where we have to specify the octa values here. This is in Docker compose central server config application dot yaml. So I will go ahead and open everything up in my ID. So the first thing is to remove key cloak from Docker compose just down at the bottom here needing that. And then in the gateway project, that's where we had the settings before. So that was under source main Docker and grab those values. And then in here in the central server config, it's just a different location when you're running everything with Docker compose will put the values there. And then let's see if all our containers have been built, we still have the gateway going here. Now our gateway is completed. So we can use Docker compose up, we'll have to see the into the Docker compose directory. And you can put dash D on the end. And then you won't see any output. But I like doing it this way without the dash D. And you can basically see the logs from all the different containers starting up. So it looks like everything started, we can open a new incognito window. And the first thing is to check on the registry to see if they say everything started. So 87 61, you'll notice it takes us to octa to log in. And it says everything's up, we can also look at the configuration. And you'll see our octa values are in there. And there is a way to encrypt those values. So you aren't checking in client secrets, I'll show you that in a future tutorial. Right now, I want to go to local host 8080 prove that everything works. Since we already logged into octa, it should bring us back here. Yep. And we're seeing tags. We're seeing products. And everything's working like we expect it to. So you might be wondering about Kotlin. We do have Kotlin support for Jay hipster. So there's a Kotlin blueprint. And you can install it using npm install dash G generator Jay hipster Kotlin. At the time that I wrote this demo, there wasn't support. But if you'll notice if you go to the releases page, it does have support for Jay hipster 7.0.1. Unfortunately, when I tried this specific JDL, there were some issues. So hopefully those will be fixed very soon. You might be wondering, how do I deploy this to the cloud? Well, Jay hipster has support for AWS, Azure, Heroku and Google Cloud Platform. So it's pretty easy to actually get it to those endpoints. The problem is if you're actually deploying to say Heroku, you'll have to deploy each individual app and probably what you want to use is something like Kubernetes, right, to basically do it all. So in a future video, I'll show you how to do that. But it's pretty easy. All you need to do is run the Kubernetes generator for Jay hipster. So that's Jay hipster k8 or Jay hipster Kubernetes, if you want to spell it out, Ray sang and I did a talk on this. And you can can see it's right here embedded in my demo. It's also embedded in the blog post. So if you start watching at 4618, you'll see Ray take a very similar architecture to this one and put it up on Google Cloud. And then you might be asking yourself, you know, should you go reactive or should you wait for project loop? So spring NBC is probably good enough for most crud apps, especially if you have less than 500 requests a second. But if you're dealing with, you know, millions of customers and millions of dollars a month for your cloud bill, and you can make things faster than maybe look into spring with flux project loom might make it so the non reactive code actually works as fast as a reactive code. You might want to look into that. I think that might be a couple years out from what I've seen companies are having a hard time even jumping from Java eight to Java 11. So project loom might be in Java 17. And if it is, and you can upgrade great, try it out. Let me know how it works. Currently, I'm investing my knowledge in reactive and I'll keep my eye on project loom. I think the beauty is that if you know the non reactive stuff, which you probably do, then you don't need to learn anything new for project loom. And by learning how to do spring web flux and code in reactive style, you will actually make yourself more aware of cool things like the stream API. So you can find this code for this example on my repo at Java microservices examples under octa developer. And then it's in the reactive J hipster directory. So if you were to go level up, you can see there's regular J hipster, there's spring boot and spring cloud and spring cloud gateway. And of course, you can find the blog post itself reactive Java microservices. I think if you Google for just that, it'll come up. So hopefully you've enjoyed this screencast. If you liked it, follow my team on Twitter octa dev. I'm at m rabel. We also have a YouTube channel at octa dev on Twitter. So subscribe and enjoy more videos like this one.