 Thanks for joining everybody. My name is Micah Silverman. I am a senior security hacksawer for Okta. That is literally my title. And tonight I'm gonna be talking to you about ViewJS and Spring Boot, but I've kind of buried the lead because a big part of what we're gonna look at later on is bringing all this together with Jay Hipster. Now before we get rolling, I have a QR code up on this slide. I have the same QR code up on the next slide. And I have this same QR code on the last slide. So if you wanna take a picture of it or grab a screenshot, you'll be able to get this slide deck and all of the tech references that we have during the presentation for yourself. So don't feel like you need to take screenshots or take pictures of your screen throughout the presentation. Just a quick little bit about me. Like I said, I work for Okta. I'm on our developer advocacy team as our senior security hacksawer. I like to find things and break them and then hopefully fix them. I contribute quite a bit to our blog and I have referenced there a OpenIDConnect Primer, three-part OpenIDConnect Primer. If that's something you're interested in, check it out. I also write code and I contribute to a few open source projects. And the one I am most proud of is the JJWT project, that's Java JWT. I also got to co-author this book, Mastering Enterprise Java Beans, just in time for that technology to be irrelevant. Now go ahead and grab that QR code if you want, but I will show it again at the end so don't feel like you have to grab it right now. Quick little overview of my history with computer languages. I thought this might be instructive. I found it entertaining. Where I start is with BASIC in 1980. So first I want to invite you all to get off my lawn, but I started with BASIC in college. I went to my college program was Pascal as the primary language. And fortunately, a year or so in, we switched over to C in the department, which I am very grateful for because I have literally never written any Pascal professionally, although it was a pretty cool language, but I have written a lot of C professionally. In the 90s, I jumped into Perl, so my first CGI Common Gateway Interface programming for the internet was with Bash and with C, but then I switched over to Perl. And 1995 rolled around and this new language came on the block called Java and there was something about it I liked right away. I'd never dealt with an object oriented language. Prior to that, I only kind of glancingly looked at C++, but never did anything of any significance. And I jumped right into Java. So you can see from 1995 when it was released up to now I have always been on Team Java. Now pretty soon after, JavaScript came on the scene in the browser and I started working with it right away, although it took me a pretty long time to really get deep in it. And I would say around 2010 is when I really got immersed in JavaScript and became what I would consider to be proficient. Along the way we had a number of other Java technologies, Servlet, Spring, Spring Boot, I dove into those. I had a moment where I was working for a company that was a Ruby shop and about three weeks after I started there, they switched over from Ruby to Node.js and I'm grateful for that because right around 2010 I really got to deep dive into JavaScript, the good part because of Node.js. I really got to get into the non-blocking, async, you know, initially nested callback hell but then better approaches and I really got to dig into JavaScript. About two, three years ago I started saying, well, I've done a lot of backend programming. I should at least be dangerous enough or proficient in front end frameworks. I'd done a lot of jQuery, but I jumped into Vue.js. I found it very accessible. I found it pretty easy to work with and I could create reasonable interfaces and modern web spa applications. So that's been my journey. Now for the rest of the late afternoon, early evening, depending on where you are, we're gonna be talking, we're gonna be layering in this application. We're gonna start with Spring Boot to expose an API. We're gonna take a first pass at Vue.js. Then we're gonna bring Jay Hipster into the picture and once we have Jay Hipster, we're gonna work with some Vue.js components and we're gonna upgrade our security and we'll have time for questions at the end. We've got a big pile of tech we're throwing in here, Node.js, Java, Spring Boot, Vue.js, Jay Hipster, Docker and we'll use Heroku a little later on. Let's start with Spring Boot. This is probably what myself and the people in this room know the most, so we're gonna actually spend the least time on it. But we're gonna start using with the Spring Initializer. If you've never used the Spring Initializer, it's super handy. You can give it a list of dependencies. It has parity between what you can do on the command line and on the website as well as the integration with IntelliJ, so they've done a really good job of making this uniform and easy to work with. So the only dependency that we're starting out with is web so we can have a nice RESTful API. I give it a few parameters here for a base directory, a group ID, a package name, it's a Maven project. Don't hold that against me. It would work just fine as Gradle if you're a Gradle person. So let's kick it off there and I'm just gonna execute this curl command. That gives me this tar ball which I can then expand and now I'm ready to open this project in IntelliJ. So I'm gonna navigate my way into IntelliJ and I have in the progress API folder, I have a nice POM file and I can open that as a project and this will take a moment just to compile and for IntelliJ to recognize it but we have a nice open empty project here that we can run right away from our Spring Boot application. Now the first thing I wanna do here cause we're gonna build on this is to write a quick little API and I'm taking advantage of a feature of IntelliJ that if you're not familiar with it, it's super handy both for prime development for stuff that you do a lot and also if you're a person that speaks at conferences or meetups, it's really handy to have these live templates. So where I'm starting is with a live template called boot progress and that just populates this so that you don't have to watch me type and the only thing that I have left to do is to import classes where there are multiple types that would match that. Let's take a quick look at this little API. It's very simple. It is slash API slash progress and what we're emulating here is an API that's going to advance a progress meter. So it's gonna return map string. This is kind of the quick and dirty way to get back a JSON response. In real life, we'd probably want to come up with a pojo that the Jackson mapper would automatically serialize and deserialize for us but we're gonna keep it simple. It takes a parameter which is not required and that parameter is a percent value and all it's gonna do is return a map that has a key called progress and it's gonna add five to whatever percent we pass in. If we pass in 10%, it'll return 15. If we pass in 20, it'll return 25. Pretty straightforward. And the way that we manage that in here is with this optional, I really like optional and basically I do a little bit of math trickery here. If this parameter isn't present, then I'm gonna set its value to negative five and then I'm gonna add five to it. So effectively, if we don't pass in a value at all, it becomes zero. Anything that we pass in, it will come back with five more than that. About as simple as you could possibly get. I'm gonna fire up my Spring Boot App here and let me get back to my command line. I'm gonna use a command line tool called HTT Pi. If you're not familiar with it, it is a modern curl replacement. It works really well with the REST APIs and it gives you some nice syntax highlighting and formatting that you don't get from curl natively. So I'm just gonna hit this endpoint. I'm gonna pass in 20 and I messed it up. Let's see what I did wrong. API progress, let me jump back here. Oh, I know what I did wrong. Of course, I need to make this a REST controller in order for this to be recognized as such. So I just forgot to add the REST controller annotation. This whole presentation is all live coding, so very dangerous, but hopefully very useful. Let's try that again. There we go, so I passed in 20, I get back 25. If I pass in 25, I get back 30. If I pass in nothing, I get back zero. So that's our API, pretty straightforward. Now with that behind us, let's take a look at ViewJS. Prior to this presentation, I did a global install for ViewCLI and CLI service. It's super handy, and what I wanna do here is I'm gonna create a project that uses TypeScript rather than JavaScript, and that's for two reasons. One is TypeScript is strongly typed JavaScript, which looks and feels very familiar to us Java programmers. Also, when you're using ViewJS with J-Hipster, that is your only choice. It always uses TypeScript, so you're gonna have to learn a little TypeScript if you wanna be able to use J-Hipster with ViewJS. I'm also going to install BootstrapView and Axios. BootstrapView is a view integration for the Bootstrap layout and component manager. Super handy for backend dwellers like myself, who are kind of hapless and terrible on the front end. It gives us a number of reusable components, and we're gonna use the progress meter that's built into Bootstrap, and then BootstrapView is just a deeper integration, specifically for ViewJS, and Axios is the de facto standard library for making HTTP calls from your ViewJS programs. You can use it outside of ViewJS, but it's an HTTP client library. All right, so let's get started with that, and where we're gonna start here is by setting up our Bootstrap. So I'm gonna use View, Create, Progress, Frontend. So that's gonna create the folder Frontend, and it's gonna add in a bunch of stuff, and ordinarily I might just be inclined to choose default, but I'm gonna select manually select features because I wanted to use TypeScript. Now, you do have the option of making that the default for future projects. I haven't done that just because I wanted to show you what it looked like, so I'm selecting TypeScript, and now I'm gonna accept the defaults for everything else, and this takes a moment to finish installing. We're not gonna wait for it because I cheated a little bit, and I have a preset folder that we're gonna work out of so that you don't have to watch Yarn and NPM doing its job here. So under preset, I already have Progress, Frontend, and in IntelliJ, we can just open that folder, and IntelliJ has some nice plugins and nice interface for working with View projects. It colorizes everything nicely, and it all works. All right, so here is our ViewJS app, and from here I can run, I can bring up a terminal right inside of IntelliJ, super handy, and if I look at the readme here, it tells me how to get going. I can just do Yarn serve, and that will fire up my application. Should take just a moment. Something failed to compile. Let's see if I broke something. Oh, I think I failed to do NPM install, so we're probably gonna have to wait for this anyway. Now I'm gonna pause here and jump back over to preset. Just gonna build this tarball once more so that I have it for the future. All right, let's try that again, Yarn serve, and one of the nice things about running it this way is that as we make changes, it will automatically be reflected. It'll automatically reload so that we can do some rapid prototyping here. All right, so now if I go to localhost 8081, here is our boilerplate view JS app. All right, not a bad start. Now the first thing we wanna do is to make an API call, and we're gonna use Axios for that. Axios uses promises, and Axios can call the spring boot backend, and we're gonna have to deal with cores, cross-origin resource sharing. If you're not familiar with that, it's just a way to identify which origins are allowed to interact with our server, and it's a protection against JavaScript making network calls without permission. So let's dig in here, and we're gonna keep it simple to start with. We're gonna go into our app view, and in this component, in this app component, you can see that we have this class called app that we can start adding stuff to, and view JS has a lifecycle, and one of the lifecycle components is mounted. So I have a live template for that, and what mounted does is when this component is loaded, mounted, once it's fully ready to work in view JS, the mounted function will be run once automatically. You can see it's complaining about Axios because I need to import Axios from Axios. There we go, okay, and all we're trying to do here, nothing is gonna display, but we can look in the browser's developer tools, and we can see this in action. And you can see here, what it's doing is, it's going to get, it's gonna hit our endpoint with a percent 10, so we expect 15 to come back, and then it's gonna get back a promise when that promise is resolved, it's gonna take that response, and it's gonna output the data that we got back from that response. So let's open up the developer tools, let's focus on the network, and I'm gonna refresh this page, and if we look here in the console, we can see that we're getting a cores error, so the browser is intervening on our behalf because it knows that it's not allowed to access 8080 from 8081. Our Spring Boot server is running on 8080, our Vue.js app is running on 8081, and we haven't set things up so that it can allow that connection to happen. So I'm gonna jump back to our Spring Boot app, and I'm gonna add a little something here to manage cores definition. So I have a little template for that, and let's break this down. Spring Boot has a very rich configuration framework that can draw configuration settings from a lot of different sources, which is really great for rapid prototyping, development, staging, and production. So here I'm referencing an environment variable called allowed origins. That's an array. I'm assigning it to this array, and it's a list of origins that are allowed to interact with our Spring Boot app. So we want to be able to whitelist localhost 8081. Now down here in this web MVC configurer, we have this course registry, and we're just saying for any path, we want to allow any path that is being requested from an allowed origin. So this gives us a really nice dynamic way to set this up. I'm gonna stop it, and there's a number of different ways that we can set this allowed origins configuration. We could do it from application properties or application YAML. I'm gonna do it as an environment variable, and when we're setting it up from an environment variable, we switch from the lowercase dotted form to the uppercase underscore form. That's just by convention, and Spring Boot figures this out all automatically. And now I'm gonna give it a new origin of 8081. I'm gonna fire up my application. And now when I go back here and I refresh the page, this time I get back a response, and I can see that the progress is 15. So now my Vue.js app is now able to make API calls using Axios, not bad progress there. All right, now we want our Vue.js app to visually represent this progress bar. We don't wanna have to always look in the developer tools in order to see our API calls being made. So let's layer that in now. We're gonna use Bootstrap View. So Bootstrap is for responsive web apps. It's really great as a starting point. Professional front-end designers either don't like Bootstrap or move away from it very quickly, but for backend dwellers like myself, it is a godsend. It's an easy to use layout system. It's got a lot of built-in components, including a progress meter, which if I had to construct from scratch would take a lot longer. So let's go back to our code and jump over here to our application. And now we're gonna work in our template. I wanna be able to show this on the screen. So where it says welcome to your Vue.js plus TypeScript app, which I can see right up here. Underneath that, I wanna be able to now show a component that has the visual progress meter. So where I'm gonna start is in the main.ts folder. This is main.TypeScript. And I wanna be able to incorporate this. And so this is gonna be TS Bootstrap. And all this does is bring Bootstrap View globally into my application. So I'm importing Bootstrap View and Bootstrap View icons. This is available because I installed Bootstrap View earlier. I'm importing some basic CSS and I'm telling Vue to use that globally here. That's the first piece of it. Then I'm gonna jump over to Vue.js and I'm gonna add in my container progress. All right, so I just added this be container tag. So this is what Bootstrap View looks like. It gives us a set of tags that hooks into Bootstrap. So I have a container, I have a row, I have a column and then the real meat of what's going on is right here. I'm showing this progress meter and I'm using these values, I'm binding it and this is part of the Vue.js data binding system. So colon value, it's gonna look in the app class that backs this Vue and it's gonna look for properties, value and max in order to work with this progress bar. Now I haven't defined those yet so let me throw those two values in, just the properties for now. So we have public, we have public max equals 100 and public value equals 20. So we'll start our progress meter at 20, the max is 100. And now this page should automatically refresh itself. There we go. And it's complaining, I broke something. That's because I haven't set up any kind of handler for my click event. So okay, fair enough, let's jump back here and I actually have a template for this piece. Let me get rid of this and now instead I'm gonna call it TS progress. That is not the one I was looking for. Bear with me a second here. Sorry, TS advanced, that's the one I want. Okay, so now I have this advanced function and I just noticed that the alignment of my mounted here is a little off. Let me fix that, there we go. So now I have this advanced handler, it gets an event, it's going to prevent default on that event, typical JavaScript stuff. And then it's gonna use Axios just like we saw before to take the current value and pass it into our API. And then with the response, it's going to get back the progress response and then we just have a little bit of a ternary here that says if the response is greater than 100, set it back to zero. So this will make our progress meter wrap and otherwise it'll just show the progress value. All right, let's let this refresh and see what we get. All right, it's not complaining anymore, but oh, there it is, I put it underneath. I meant to put it above and there it is underneath. So it was probably showing us this before. Let's just see why that isn't showing up where I expected it to. Oh, because I put it underneath. So I want this to appear higher. So I'm gonna actually put this after the image and before the hello world, let's do that. There we go, that's what I was looking to do. All right, now we have it all connected up so that when I click on advance and if we go here to network, we can see that it's calling our API and it's advancing as we go. And when I advance past 100, it resets it back to zero. If we look at that last call, you can see the response was 105. And so our ternary kicks in and sets it back to zero for us. So pretty good. Now we have an end to end app making use of Bootstrap View. It can advance our progress meter. Of course, this is not a thrilling real world example, but we got here pretty quickly, so not bad. Let's see what's next. Now what we have so far is a good building block. We're missing a few things though. We're missing security and we're missing a single integrated app. What we have right now is a progress front end and progress API in separate projects in separate windows within IntelliJ, but really it's all part of the same project. We have a front end and we have a back end. So I want security, most modern web apps need security and I want it all to be integrated into one app and that's where Jay Hipster is gonna come in for us. So I'm gonna kill these examples here and prior to this I installed Jay Hipster, so that's generator Jay Hipster. If you're not familiar with Jay Hipster, it's a free and open source application generator. It generates applications with a front end of your choice and a spring boot back end. The front end is your choices, your default choices are angular and react, but Jay Hipster also has this whole system called Blueprints to be able to add significant functionality and there's a well-supported ViewJS Blueprint that is what we're gonna use. So I installed the generator Jay Hipster, generator Jay Hipster View, that's the blueprint that we want and out of the box we're gonna have a single project that's all ready for security and where we're gonna start is using Key Cloak for OAuth and then we're gonna switch over to Okta a little later on, but let's dig into Jay Hipster first. All right, going back to my live directory, I'm going to make a folder called Progress App, this is our unified app and CD into it and now I'm gonna run Jay Hipster and ordinarily that would be enough to get going but I'm also gonna give it this Blueprints ViewJS to tell it right off the bat, I don't wanna use Reactor Angular, I wanna use ViewJS. Now from here Jay Hipster is gonna ask us a bunch of questions, I'm gonna have a monolithic application, I'm not gonna use Web Flux, the base name of our application we'll call Progress App, the base package you can see I've done this before, com, a fit nerd, Progress API, I don't wanna use the Jay Hipster registry, here's the important bit for security, so security is a first-class citizen with Jay Hipster, we have to make a choice, we could ignore that choice but I'm not going to, I'm gonna choose OAuth and you can see that out of the box it works with both Key Cloak and Okta. We're gonna start with Key Cloak for local simplicity sake and prototyping and then we're gonna switch over to Okta after. Now in real life you'd probably have a backend database, you might have a caching layer, we're not gonna use either of those for our example, I am gonna leave it as a Maven project and I'm not gonna add in any other additional optional packages. Now when we get to framework, our only choice is ViewJS cause we kicked this off saying that's the one that we wanted to use, we'll leave it as default, ordinarily I would have internationalization support but I'm gonna turn that off just to keep things simple and I'm gonna accept the defaults for everything else. Now this takes a good long while to get installed and generated and going so I'm gonna use a little bit of Smoke and Mirrors here because in my preset folder I already have this set up. So let's go to Progress App in preset and I'm gonna choose the POM XML there, I'm gonna open it as a project in a new window and here now is our unified project and the readme for it has a bunch of information about how to get going. We wanna run NPM install, then we can run the Spring Boot back end and the ViewJS front end. So let's do that just to see this in action and this is just gonna take a moment for IntelliJ to recognize that, there we go, okay. So if we look at the structure of our app, you'll notice that we have source main Java, we also have source main resources and web app for all of our view stuff and our settings. Let's fire up the back end as we normally would from IntelliJ and I'm gonna bring up a new terminal and I'm gonna fire up the front end, so NPM, oops, it switched over to Jay Hipster as it launches it. I'm gonna run NPM start, it's gonna do the web pack dance. Okay, let's get rid of this and now we have local host 9000. So now we have our fully functioning Jay Hipster app including authentication. Now one of the cool things about Jay Hipster is that out of the box, I've gone too far, I've lost my presentation but I know what I need to get it back. Hopefully it's still here, there it is. Bear with me a sec, let's get to where we were and I'll present again. All right, so one of the cool things about Jay Hipster is that it has this Docker folder and it has this Docker build for Key Cloak so that right out of the box, we can run Key Cloak in a Docker container and have OAuth security built right into our app. Now I did that earlier in a separate window so I already have Docker running, Key Cloak is already running in the container so we should be able to authenticate from this application and now we're in an authenticated state as admin, awesome. Now let's start to layer back in everything that we worked on before so that we have the front end to back end communication that we want and where we're gonna start with that is with our Java app and we're basically gonna recreate in our progress app what we had before. Now you can see there's a lot more to this basic app but just like before, we're gonna make it also a REST controller and we're gonna add in our, we're gonna add in our spring boot controller method here and so this will be boot progress, there we go and I just have to resolve some imports where there are dupes, there we go. So same API as before, that's all ready to go so I'm gonna restart the back end and now on the front end, let's start where we started with ViewJS and that is let's just get the app to be able to make a call to the back end. So I'm gonna go into web app and there's an app view and there are a couple of things that are different here. One of the things you'll notice is that we now have a nice clean separation from our view component with the object that backs it, our app component TS. This is a good thing to keep these things separated but I have my default class here and I can add in the mounted function just like I did before and I need to import Axios just like I did before, there we go and this is doing the exact same thing that it did before, only we have something really nice built into J-Hipster and that is all calls to an API endpoint can be proxied alleviating the need for us to set up cores while we're prototyping. What that means is that our ViewJS front end is running on port 9,000. Anytime the application accesses something that begins with API from port 9,000, it recognizes that that's a back end spring boot call and it's gonna proxy that for us. So this allows us to get started a lot faster and not have to worry about cores and setting our spring boot application up with all that. So now in my terminal, I should be able to see that it's reloaded and let's go take a look here at our console and it's complaining about something, let me just reload, there we go. So now we can see in the console that we're getting the response from the API just like we did before. So this is good, we have our J-Hipster app, we have security and now we're starting to layer back in our progress meter component. All right, let's continue on with that and now I wanna be able to bring in our visual progress meter component but now that we're in J-Hipster land here, I wanna expand, I wanna do it in a better way than we did the first pass through and so what I want is in between this welcome Java Hipster and this is your home page, I want to have our progress meter sandwiched in there and so where that lives in the web app is it under core home and this is the home view component. So you can see up here it says welcome Java Hipster, this is your home page, sandwiched right in between, I wanna have a custom tag called progress meter. This will make everything clean and reusable once I set up my progress meter component which I haven't done yet, I'll be able to reuse it wherever I wanna be able to reuse it. All right, now right now this isn't gonna do anything because I haven't defined progress meter and I haven't properly integrated it so let's do that next. All right, so now in the shared folder which already exists for me over here on the left, I have this shared folder. I'm gonna add a new folder to shared called progress, new directory, we'll call it progress and in that progress, I'm gonna add two new files, one is progress view and the other is progress component TS. So I'm just following the same pattern to have a good separation between my front end view and the code that backs it. All right, let's start with our view component first and I have a nice template shortcut for that already set up. And hopefully this will look somewhat familiar. It's a little bit different than where we started but the core of it is still in there. We have this progress, B progress meter tag which uses bootstrap view and we have the button and it's referencing our progress component TS file. That's where the actual code is gonna be. Now there are a couple of differences that I wanna point out here. One is while we have the bootstrap view tag here B progress surrounding it, we have regular bootstrap tags. So when you're using bootstrap outside of view JS, you work with these class attributes. So here we have the row class, here we have a column that takes up nine positions of our grid. For whatever reason, the people that made this great blueprint for view JS, they included bootstrap view but only for certain components. So here we have a mix of bootstrap view like B progress is included but over here we have vanilla bootstrap tags for our divs. Why they did it exactly that way, I'm not 100% sure but we still have our progress, our bootstrap view progress integration. So we can use B progress. All right, now we need to fill out the component side of it. Oops, I messed up my own live template. There we go. And hopefully this looks familiar to you. It's just now encapsulated in its own file in its own class. So we have this progress class. It exposes two properties, max and value and it has the same advance function that we saw before and it's using that local reference so that it will automatically get proxied. So very similar code to what we have before. Now we're very close here. We have our progress view component defined. In home view, we're using this progress meter tag but we haven't yet bound this progress meter tag to our progress component and that's the last piece of the puzzle. And to do that, we're gonna do that in our home components TS file. So the first thing we're gonna do is import the progress component that we just created. And so that's gonna be from shared. Gotta spell it right, shared. This is one of the reason I have all these live templates because I'm terrible at live typing. And this is gonna be our progress view component. So now we're importing this progress component and we wanna make it available to our home component. And so we can do that by setting it up in the component annotation here. And we're gonna give it a key. The key is gonna be progress meter. Hopefully that looks familiar because that's what now becomes our dynamic tag. And we're gonna bind it to our progress component that we just pulled in. And I messed this up a little bit. It's almost right. I need to set this up in its own components object and then this goes inside components. There we go. Let's see. And it is complaining about this shared progress, progress dot view. There we go. Okay. So now we've wired everything up to recap. We started out by expressing the ideal scenario. So ideally I have a progress meter tag that I can reuse in different places. And then we went and backfilled that in by creating our progress component, the code that backs it. And then finally in our home component by referencing that now as a standalone component and it's the progress meter key that allows us to now use that as a tag. We went through that kind of quick. Hopefully it is clear. And let's see what we get back when we get set up. Great. So there is our component and it should be completely functional. Let's make sure that is the case. Awesome. Now, one thing that I didn't point out which I will do so now is that our API is proxied, but all API endpoints also require authentication. So if we sign out, we'll now see that when I try to advance this meter we get back a 401 response because it's unauthorized. So ideally, I don't even wanna show the progress meter until we're authenticated. Well, J-Hipster makes it super easy to do that or it's kind of a mix here of UJS and J-Hipster that allows us to do that. Back in my home component, I have this vif attribute and it recognizes authenticated. What this is saying is that it's not gonna render the progress meter component unless I'm already authenticated. So we'll give that a chance to reset. So now in this unauthenticated state I don't see the progress meter at all. After I authenticate, I now do see the progress meter. Very good. All right, last piece of the puzzle for tonight is to switch from key cloak over to octa. All right, our next step is gonna be to switch over from key cloak to octa and to do that we need to provision an octa org, create an oauth to application in octa. It'll actually be an open ID connect application. Now that provisioning is made super easy with octa's Heroku add-on and so we're gonna look at that and then we'll update our J-Hipster app with some simple configuration changes. Let's take a look on the octa side of things. Now over here I'm logged into my Heroku account. If you already have a Heroku account you can take advantage of the octa add-on and so the first thing I'm gonna do is create a new application and I'll call this application let's say octa Heroku demo, how about that? Excellent. Now creating this application doesn't do much it's just a shell within Heroku but what we can do from here is add add-ons. Now there are a lot of add-ons in the Heroku elements marketplace things like MySQL and Postgres and Redis and others we're gonna add in octa's Heroku add-on and when I click provision that's gonna kick off the provisioning of this octa org and it will be preconfigured with the OpenID Connect slash OAuth2 applications that we need to wire up our J-Hipster app. This provisioning takes about 25, 30 seconds should be just about done, there we go. And now from here what is very nice is I can single sign on over to my octa admin console. So this is what the octa admin console looks like if you've never seen it before. Also I have a whole bunch of environment variables that have been created for me including everything that I need to connect my J-Hipster app to my octa OpenID Connect app. The three bits of information that I need here are the issuer, the secret and the client ID. So I've just copied those and now over here located in the source main resources config folder in my J-Hipster app is the application YAML file and you can see that that's preconfigured to talk to Keycloak running in our Docker. So now what I'm gonna do is switch over these settings by just replacing the client ID and the client secret as well as the issuer. Now once I've done that I can just restart my spring boot app and now everything I need to connect my J-Hipster app to octa is all set. What we're gonna see in just a moment I'm gonna bring up an incognito window. We're gonna see that we have an issue that we're gonna resolve very quickly in over an octa. So the way that this communication works for this OAuth flow called the authorization code flow is that we're redirected over to octa where we authenticate and then octa is gonna redirect back to our app. This is the safest way to manage authentication with an OpenID Connect app because the credentials never go anywhere but the service provider which is octa in this case. Also as a side note you can customize the look and feel of this. You can change, you can have a custom domain here so that you don't ever have to see octa in the mix if that's not something that you want your users to see. The problem here is that octa won't redirect just anywhere it has to be whitelisted and so we wanna take this redirect URI that's been set up by our J-Hipster app and we wanna configure octa to recognize that. So from our octa admin console I can go over to this Heroku Created OpenID Connect app and on the general tab I can edit it here and I can add in that redirect URI as one of the valid redirect URIs and now octa will redirect to it. While I'm here I'm also gonna set up our log out redirect URI that also has to be whitelisted and so now I have that set up and I'm gonna save this and now when we jump back to our app and we go to local host 9000 this time when I click sign in I'm redirected to octa's hosted login page which again can be skinned and customized to have the look and feel of your brand. Now in order to authenticate I'm gonna go back over here to my Heroku configuration variables, my environment variables and I have a default admin email and password that were automatically set up for me and so I'll paste them in here. Now I can authenticate again. It's asking me to set a security question that's a one time operation that I need to do because it's the first time that I'm logging in and now we're back into our J-Hipster app as this logged in user and I can interact once again with the progress meter and if I go ahead and log out we still have the same functionality that we did before where I no longer see the progress meter. So pretty good. We went from zero to a separate spring boot and Vue.js app to J-Hipster layering in authentication in our single one stop shop application. Now what's left to talk about this was a long presentation so that we couldn't cover everything. Vue.x is a Vue.js library for state management. So for instance, if we wanted to reuse our progress meter component across different other components and have it show the same progress in all those components we might use something like Vue.x to manage its state. It has really great storage capabilities for data bindings. We also didn't talk about JPA or caching. Those are elements that you'd probably have of a real modern web application and we didn't talk about deployment. Now I'm not affiliated with Heroku in any way but I do really love their service. It's super easy to deploy Java spring and spring boot apps, J-Hipster apps, it's really easy to deploy to Heroku. So I encourage you especially for prototyping and demoing but even for production apps to deploy to Heroku. That brings us to the end here. I have the QR code up once again that will bring you to the GitHub repository that has this slide deck as well as links and references to everything that we talked about today. Thank you for your time and attention.