So hopefully now you're a little bit more familiar with the differences between micro services and monolithic kind of applications. Now that you have a little bit more of a background on it I want to take a deeper dive back into the application we're going to be building. So here we have our three micro service apps. We have a angular two app which is going to be our front end. A Rails app which is going to handle our proposals. And then a document app which is going to handle the documents. So each one of these are going to be their own application.

So when we push these up and if we were to deploy these this one would be its own app on Heroku or Digital Ocean. This would be the same and then this angular app would be its own application.

Now if you have studied or worked with older versions of angular then you may be kind of confused at how this would work because in angular one it requires you to build it on some type of server side system. So even if it was node it still needed to be built on something like Express or something like that. I've also built applications using angular one on framework's like Rails or like Sinatra. And that's OK but I wasn't really a fan of it because it never really felt like a natural fit. In angular two they rewrote the entire language completely from scratch and what they've done is they've made it possible for these applications to live by themselves. So this is how all of these are going to be put together.

Now I want to talk about how they're going to communicate because we have these applications but if they're each on their own server and there's no direct connection between them how is it actually going to work? And that is where we get into services. So a service or a service oriented architecture, which is really what micro services are, is where you have separate applications that communicate via API's. So instead of a monolithic application where you have everything inside the app it makes it really easy to just make a database query or something like that. We can't do that here. Here we have to set up a connection to API's. And that's how it's going to get its data and that's how it's going to be populated.

So take a few examples. The easy one is going to be docs. Docs are simply going to list out all of the documents coming in from the rails API. This is going to store a full list of documents in the database so it's going to be persistent and you can add to them, you can take away, you can edit them, all in this app and you never even have to touch the the angular side in order to do that. And what this is going to do is make a JSON feed available. So what is going to happen here is our docs component is going to make a call to the rails app using JSON. So it's going to call and it's going to return that JSON object and when it does that then our docs component is going to be able to read it, parse it, and display it. But the really cool thing about this is our application is never actually going to really store the data, it's simply going to be rendering it. So when we talk about things like a separation of concerns, micro services completely embrace that because what they've done is they have taken away and that coupling which means that we could go make changes to this doc and as long as we don't change things like the attribute names or something like that then this is still going to work.

So you could have a developer go and make a bunch of changes to the application in terms of how it works and adding features, you can do things like that. And this feature should still work if you're doing it properly. So that is this side where we're just going to make a call and then we're going to get a response.

And if you have studied the way the HTTP communication works this little dotted line is called the request. So we're going to make a HTTP request and then we're going to get a response back. Say that we sent a bad request or say the server is down. This response might be an error. So if everything's down then it's going to give an error. And the cool thing about this is imagine if you had all of this in one application and something broke on the doc side. If someone went to the full app the entire thing would be down and no one would get to see anything. What you'll see is by doing it this way everything else in the application will work but if there's an error here it's some kind of problem. All that would happen is that docs just won't be able to show me the documents. But it won't take the rest of the application down which is another reason that this kind of architecture really is scalable. It's great for large applications and it's a really fun architecture type to work with.

So moving on to our proposals. Proposals are going to be a little bit different because they're going to do more than what we did right here. We are going to have some component of that. So we're going to send list items. We're going to make JSON data available here. Our proposal can send a request and it will receive a response. Just like right here.

That is a full index. That's a really easy one to do and that's the reason why I made the docs like I did so it be straight forward. With proposals that side of it is going to be identical. We're just going to say, how many proposals are there? Bring them all back to me and let me see them. That's easy.

Then we're also going to create another type of request. This is going to be a request where we're asking for a specific proposal. We'll be doing things like pass in an ID so that we can bring back that unique proposal. Then it will send back a response. And lastly, and this is one that's really fun, we're going to be able to create items remotely. From our angular app we're going to be able to enter information in and then it is going to go contact to the proposal application and it is going to create a record in there, which If you've never done it before is pretty awesome because you will actually have one application communicating with another and you will create real records in this database that then will be cycled back and you can go view them.

So this is going to be really fun. This is part of the reason why I've been wanting to build this type of application as a course for quite a while because it's pretty exciting and it's also one of the most prevalent design patterns in modern development. So if you have never heard of it but you want to become a Rails developer or an angular developer, anything like that, then it's really helpful to have this kind of architecture as one of your skill sets because there a good chance you're going to be asked to build an application just like this.