 Thank you for attending, this is your agenda for today, I'd like to know a little about you so I can play around with what I have to tell and what I won't tell because of the time. Tell you a little about me, about my company and then we'll dive into the case which is about building a tracking platform with Vertex, Angular, Redis and deploying it on platform 3 eventually. A little bit about you, who's here from a developer perspective and developing apps at the moment? Who's familiar with Vertex? Ah cool, that's a takeaway for most of you today, with Redis? Angular? Please, I'll explain a little then. Most of the times each hand goes up and I don't have to explain it and that saves me some time as well. Who's here from an operations perspective? Who is managing Cloud Foundry? Sort of. You're my arrows. I'm not able to do it. Alright, thank you. A little bit about me, during the keynote I saw that everybody was talking about their kits so I put in a slide. These are my two guys. The van behind them is my third kit. They think they own it and they say they own it but if the van goes for maintenance I have to pay the bills so we're not there yet but it's cool. It's a nice van, it's really something you should... We love the van. Yeah, the kits for the van. For the van. Ah, alright. Let's keep it simple. I'm the founder and managing partner of J-Driven so that's my day job. That's also the reason that the van exists because I was working 24 hours a day because working is fun for me but spending time with the kits is also fun. So we bought the van and now we're going out for the weekends with the van and that's also... I love to code, solder, surf, create all kinds of things when I'm out of work or when I'm able to combine it. I exist on Twitter, please follow me. You can ask me some questions afterwards, that's also no problem but reach out to me on Twitter if you have additional questions. This is my company, small consulting firm in the Netherlands. We are about 33 people big now. We're doing enterprise development for large customers and helping them to create beautiful software. We do that in all aspects of enterprise development, so architecture, software development but also continuous integration, continuous deployment and we're trying to do that to get away with our customers and get the customer and its organization on a higher level. And J-Driven also exists on Twitter. If you were in early, you already saw the website live but this is what we're going to build today, a web application which makes it possible for me to track where my van is or make it possible for other people to track where the van is because most of the time I'm inside. How did we manage to build that? I told you that when I'm away with my van I'm not willing to work. I'm not wanting to try to create something with a Raspberry Pi or something. I did not create a track device myself. I bought something online. This tracker is about $20. You can buy it on Alibaba or whichever site you want to use. It has GPS tracking in it and you can put a SIM card in it and then you can send text messages but you can also configure it to send data to an IP address and port. That's what we're going to use today. It also has some additional features which they tend to describe as security features like blocking your engine, building an alarm on it. But that's basically the next slide. If I tell you about specifications you don't want to use this professional. This is nice for a hobby. Nice to track something but don't use it to secure your car because it's not secure. Actually the website you saw is the part on the right so the combination of data flowing through the system and showing up on real time on the website. This slide is not to explain you the protocol in depth but I added this slide because at the time most integrations you build between systems are using JSON, XML over HTTP, maybe some messaging maybe some soap if you're lucky. But this is something different. What you have here is just a plain socket connection and sending bits and bytes over it and you have to reply back. So basically what the tracker does it makes a TCP connection as soon as it's live. It sends a login package and expects some bits and bytes back in the right order with the right checksum which you have to calculate yourself and then it starts sending location details on a frequency you can configure. And you have to acknowledge the fact that you have received it so it's pretty low level. It's pretty efficient and it's pretty badly documented. If you had some more time today I would have asked you what the mistake in the formula is here but this actually from the documentation and it's not gonna work. So what we had to do we implemented it from the specification but actually we stored lots of packets from the tracker itself and we reverse engineered the protocol afterwards. So each packet we received we put through a unit test and we see if we understand what's in it. Building the application we used Cloud Foundry to deploy it vertex and red is for the backend and Angular in the front end. There are some people familiar with vertex. I guess I have enough batteries so that's not an issue. There are some people familiar with vertex but I would like to give a short introduction. It's a lightweight high performance application framework. Well everybody says that so that's not that exciting but lightweight most of the times for my company when we develop on Cloud Foundry we develop using Spring Boot. And our last Spring Boot actually we're rebuilding this same case using Spring Boot at the moment to compare the two. It's okay but vertex is more lightweight than Spring Boot. Why is vertex more lightweight? Because it doesn't do that much for you. You just have a runtime environment and pretty simple APIs to play with. Cool thing about vertex is that you can write your pieces of program in different languages. I will use Java through my slides in a former version I used Groovy that had one benefit because the code examples fit on my slides. Java's a little more verbose but it's fine to have your type system behind you. But you could use other languages. You could use JavaScript and all kinds of languages. It's simple what I was saying is just a way of writing code using the APIs for this offer you. The APIs are asynchronous everything is asynchronous and that makes it possible for you to create really scalable lightweight apps which in fact very well suits the fact that we have to connect several sockets from GPS trackers. You don't want to manage the stage yourself the concurrency yourself. Vertex is very good at that. And it's extensible. I've worked with vertex from version one. Version one was really an abstraction above Netty. I don't know if somebody is familiar with Netty. It's a pretty powerful library to do fancy IO in Java. And it was very low level. And basically if you wanted to create a web server or a web application using vertex you had to parse the HTTP request yourself set the right headers and give the right response back. Well that's not anymore. It's now very powerful. You have features to use templating to use routes in HTTP so you can create very nice applications using vertex. From this picture I don't have the time to go into this in depth but the most important things to remember are verticals because basically verticals are the parts of our application we write our logic in. There are simple components that receive messages send messages communicate using the asynchronous API with other systems or receive data from other systems and the verticals themselves interact with each other using the event bus. So they will publish and subscribe messages to each other over the event bus. The cool thing about vertical is that vertex guarantees you that there's only one thread in the event loop that handles the logic in your vertical. So all your handlers you were just there you will see an example later on. Everything in your vertical is handled by one thread and that's pretty powerful because you don't have to juggle around with state and you can just trust it that the state you build up is only accessed once at a time. But the world isn't asynchronous. We still have things that are synchronous and that's where working verticals come in. What you do then is you will send a message over the event bus to another vertical and that uses a classical thread pool and will communicate with your legacy database or all kinds of other synchronous stuff. One thing to remember, a vertical complain if you don't remember is that you should not block the event loop. So don't do anything in your vertical that doesn't that is not asynchronous. Don't use the thread sleep there or something else use the scheduling API. Verticals, I mentioned most of it. This is a basic vertical to create a web server. It's just extending a class. I have a start method in which I implement my logic and what you'll see that we're doing there is registering handlers for messages on the event bus or as we do here creating an HTTP server sending something back if a response comes in and make it listen on port 8080. We'll go into some verticals in more detail later on. The event bus, the way to communicate between the parts of your application and you can do that using a publish subscribe. So I'll publish something you're interested. You will receive it and you do something with it. I can use send and receive which looks like a bit like a publish subscribe but is to do point to point communication. So I'll address you all but one of you will pick my sentence or my message up, do something with it and when I'll address you all again somebody else will pick it up so I can use it to round-drop in my load and I can reply on it so you can tell me something back. I can use that. Something that really helps making reactive apps with a web interface is the fact that you can bridge the event bus to the client side so you can make the application, the Angular application in the browser part of the messages that are growing on in your system. So for instance, if a location event comes in I'll publish it and I'll receive it in my web interface and I can show it on the map. More on that in the examples. This is some simple code which illustrates how to use the event bus. One thing to know is that and to remember is that the event bus isn't doing anything with guarantees so the fact that your message is received is not something you can count on. You have to keep it in mind. So don't build your next banking backend on Vertex unless you manage that yourself. This is the architecture we're going to build and basically we have the sensor in our van. It talks to a vertical that accepts the socket connections and publishes events with location details in it so it translates the bits and bytes to JSON. We'll store it using a vertical that persists as an address. We'll enrich it, which is out of scope for today but still in the slides if you download the slides later on. And we'll also publish the enriched location event to the web vertical which you'll pass it on to everybody who's looking from the web browser. And the cool thing to remember here is that the direction of the arrows is very natural. An event comes in, it flows through our system and it pops up enriched in our web browser. So we're not doing things here like storing everything in the database and getting it out when we need it. No, if a location updates comes in, we'll show it directly in the browser. Those are the two three variables we're going to have a deep dive in. This is the first one. This is the one that's talking with the trackers and this is very simple. This is even simpler than the web example you saw before. What it does, it creates a server on a port and a host and it registers a connect handler which gets triggered when a device connects. When a device connects, the handler is executed. We'll grab the socket ID so we have something to identify by and we register a connection handler. And what happens is each time packages arrive, the connection handler is triggered. And basically what we do, we create a message body from the role with some bytes. So behind that Java function is something that translates the table you saw before into readable JSON with a latitude, longitude, speed, GPS statistics like the demand satellites. And it publishes it on the event bus. And basically on that address is listening, is another component listening which we'll handle. This is a very simple vertical. We like to store the location details. So it's not a goal by itself to just show the location on a map we want to store all location details in Redis at this time. I was familiar with Redis before I created it and for me Redis was just a key value thingy and something used for a cache that performs pretty well but I didn't dive deeper into it until now. But it's pretty powerful for such cases because it supports transactions, publish and subscribe and also time to live so you can expire your data when you store it and Redis will arrange it for you. You can add clients to Redis and communicate with Redis from virtually any language. The clients libraries are very lightweight. Vertex has a client built in. And the cool thing is that when you look at Redis basically it's a key value store but the value can have different forms. So you can store string as a value. Think of it as a hash map in Java and this is pretty powerful for us because what we can do, we send messages to our system that contain JSON and we can put JSON into a string and store it in Redis. The reason why we use JSON is that if you are going polyglot and you're using different languages within your Vertex application JSON is a pretty easy format to marshal in each language so that's why we're using JSON also internally. We have lists, think of it as an array list you just append to the list. We have sets, each item is unique and we have a very powerful variant of sets and it's a sorted set and the cool thing of a sorted set is besides the fact that you just put in more data in set it's unique, you can add a score. And in our case we're using the timestamp of the moment we received the coordinate as the score and that gives us the power to grab the last element or grab all locations within a certain time frame just from a Cree value store. How we're using those messages what we are going to do here is we're going to store the enriched location details so the location in JSON we're going to grab the body we want to receive that so at which moment did we receive the message? We want to grab the device ID and basically what we do is we create a key in the form of tracker device that the location receives that so that's the key in our Redis store and we store each location update in a sorted set and we do that by specifying the key specifying the score we received at and putting the whole JSON message in there and that makes it possible for us to retrieve the most recent location or the most recent 10 locations if you modify the last 0 to a 10 but it also makes it possible for us to request the data by score so for instance request all coordinates within an hour and see what we're going to do there and the nice thing of this is that it's blazingly fast because Redis optimizes the way you wrote your data for reading so you have instant response if you want to request it and it scales out very very good so if you have thousands of trackers that's not an issue Angular, there were some people that not that familiar with Angular I'm not going to give you a deep dive in Angular now but what we basically did here Angular is a framework to build rich JavaScript applications in it has some patterns in it that are very familiar for instance Java developers so that helps to write great software it does some very neat things with binding your data you have in your application with the data that you're showing to your users and that's very powerful and we're going to use that here to show the data in real time but first we need a web server we have to push or make it able for our users to request all web resources so that's also a vertical in vertex what we do here is we in the start method we create a router the router we can use to specify on which path resources should be available and we add a static handler and static handler is just something that shows static files that's why it's called static handler from a certain path from your file system or your class path through the browser so basically what it says here as well we have a folder called web route and everything that's in there my index.html my JavaScript files my CSS files just to serve it out that's fine and we add one other thing that are those are four lines of code and they're the most powerful lines of code in this presentation because what they do is they allow you to distribute the event bus to the client side so basically I can use the JavaScript library and connect to the slash event bus path and I will receive all messages on the client side also so my location updates and all the details the reason we use permitted options is somebody willing to explain me why I put it in there why would you want to do that? suppose I have to enter it myself now what you don't want every event from the client to the server and from the server back because internally the communication with Redis also works with events so what I don't want is to send a comment from JavaScript to clear my Redis database so you can see this as kind of a firewall-y thing I define a regular expressions and only addresses that start with web are allowed to come into my system or allowed to come from my server to the client just to prevent some issues we don't want and finally we have to start listening that's what we do and this is all all the code we need to create a web server which serves our static files which create an event bus bridge which allows us to show the details on the map a little piece of the Angular code I'd like to show you not to understand every letter of it but basically the concept is the same as all the verticals we saw this is JavaScript code this is somewhere in one of my Angular controllers and what I'm doing here is well I have an event bus server that's an Angular-Rised event bus service and I just say well I want to listen to web.device.location and each time an event comes in with that address I'll store it on the scope in an hash map in JavaScript for the device edition basically what I'm doing here is I'm storing the last location of my verticals and the cool thing is that if I listen to the right events and I build up the state on the client side I'm able to add dynamically generated graphs to the right data and they will if my speed differs that's the actual speed per device it will adjust the graph because that's what Angular does with data binding and that's also working for the map so if you're trying to do something with maps have a look at leaflet leaflet is very powerful and gives you an abstraction on top of things like OpenStreetMap and Google Maps but also gives you the option to write your logic not bound to for instance Google and what you're doing here the TripPads is also an Angular variable on the scope which contains all paths that form the trip that you see on the map there and if I add another part to it to my trip it will show up in real time on the map so you will see the fan moving you'll also see the trip moving for deployment initially we developed this just as a demo not with Cloud Foundry in mind so the cool thing was how much time do we need how much effort do we need to make this run on Cloud Foundry we deployed it on Pivotal web services publicly available for the Cloud Foundry and basically there are two applications the platform, the website you are looking at and the part that analyzes the data and the receiver and the receiver is the the component that communicates with the trackers and we use one service that we share between both apps I'll tell you a little bit more about why we do that later on the first thing I was really enthusiastic about this conference because I wanted to see how many people are using Cloud Foundry I'm really surprised, happily surprised about the power of the community behind Cloud Foundry so I didn't realize that I needed TCP routing at that moment thanks so one of the guys at Pivotal helped me out I had some better access to TCP routing on run.pivotal.io and basically the way I use TCP routing here are those three comments if you have to do it manually and not in your manifest but I'm creating a random route on a random port and I'll request the routes later on I need that route, TCP route because my tracker only talks TCP so I'm not able to put that over the normal routing and that's also why basically you have to look at this and remember the port we're going to play with that later on because my application was configured just to run on its own what I'm doing here is grabbing the application configuration from the environment so I have to grab a port for each application that's what I'm doing here and I have to request all service configuration and use that to find out where my routers is what these credentials are things like that and one thing I didn't notice at first because the WebSocket implementation in Vertex falls back to long pool if WebSocket aren't supported which is pretty powerful but I didn't saw that it didn't work at least at PWS you have to use PWS you have to use port 443 for your WebSockets if you just use the HTTPS or HTTP port it won't work so that's something to realize and this was the initial application and then we have to use a TCP route and an HTTP route to the same application and that's not possible at the moment so what we did is we split up the application we wrote the receiver which has the TCP route so all traffic comes in over TCP and we separated the platform which handles the HTTP request that led to another problem and that's that the receiver in the platform application can communicate between each other and one of the features of Redis is very powerful is that you can store data in it and retrieve but you can also create channels in Redis and use that for publishing and subscribing so basically what we do here is cheat a little and use Redis as a bridge to publish my location updates and receive it in the platform some last remarks I really enjoyed the developer experience I was familiar with Cloud Foundry for several years but always used Spring Boot so the chance to do something with Vertex on it was for me a chance to get to know the platform better and do something manually that Spring Boot does for you the operation guys are my heroes because I tried to install it myself because I needed TCP routing in Redis and I didn't manage to do that in three, four long nights so that's not happening often but I didn't need lots of changes to migrate the existing app what you'll notice is that you want you develop an app for Cloud Foundry please have a look at the platform you're actually using because each Cloud Foundry installation has different options I have to use Redis to communicate but if you have the full power and you could do something with security groups and configuration you can allow the applications to talk directly and use the clustering of the event bus so please look at which Cloud Foundry you're developing for and TCP routing is very, very powerful it really helps in the IoT space in the talk I saw before you see it also as just opening up a port to use MQTT and directly on Cloud Foundry which is a fun talk by itself thanks for your time if you have any questions and we have some time left I don't know please ask them please ask them don't be afraid when do you start the trip? I just finished the trip last weekend I went to Donberg and I was very glad that I'm not here with the van because I took some time by my own car and the van isn't going to speed up more than 80 kilometers an hour thanks for your time if you're willing to have a chat or some additional questions reach out to me on Twitter or talk to me later on in the conference thank you very much