Now that we have our application created we can go and create our data model. So we're going to go and create a scaffold and I'm going to jump back into Sublime Text. And I want to look at our model here so remember that we created a class for our proposal and I'm going to go and copy the code inside of freelance-camp-fe/app/proposal/proposal.ts because I want to use the code and it will tell us all of the items that we need right here. So I'm going to go back into other microservice application. So notice right here I'm back in the freelance_camp_proposal Rails app and I'm going to go in the seeds.rb file. Now you may wonder why I'm going in the seeds.rb file when we haven't actually created a model yet. And that's a perfectly good question and if we ran this it would throw an error and it wouldn't work but I simply want to put this data here as a placeholder so that when we do run our scaffold it will generate everything.

So I'm going to create a new proposal so it's going to be Proposal.create! with a bang. I only brought this code, not because any of this is valid Ruby code whatsoever but just because it makes life a little bit easier for creating the data. So here I have a create statement. And I'm going to want an i.d. which we're already going to have. So we don't need to set the i.d. The next thing we're going to have is a customer ( let me indent this all properly). So as you can see part of the nice thing about keeping our naming the exact same between applications is that I can do things like this and simply you know port them over. So I'm going to come here get rid of all of the question marks because we're not going to use those. And now we can simply pass in our value. So here we're going to pass in customer: and we're going to say this is going to be "Customer #{proposal}"and this is because we're eventually going to create a block and we can do it right now so I can say 10.times do |proposal|. And now here we can add in all that data. So the portfolio_url: this is going to be a string that's going to link to a portfolio so I'll just do mine which is http://portfolio.jordanhudgens.com. For tools: let's say this is going to be "Ruby on Rails, Angular 2, and Postgres. For estimated_hours: this is going to be an integer so for this one we'll say this project's going to take 80 hours and actually let's make estimated_hours: a little bit more dynamic. So we can do (80 + proposal). So what this is going to do is every time proposal iterates it's going to increase 80 so it will increase the number of hours which will give us a different calculation. So for hourly rate: we'll say this is going to be 120 and then for weeks_to_complete: we can say this will take 12 weeks to complete and client_email: is going to be 'jordan@devcamp.com'. And this should be everything that we need.

10.times do |proposal|
  Proposal.create!(
    customer: "Customer #{proposal}",
    portfolio_url: 'http://portfolio.jordanhudgens.com',
    tools: 'Ruby on Rails, Angular 2, and Postgres',
    estimated_hours: (80 + proposal),
    hourly_rate: 120,
    weeks_to_complete: 12,
    client_email: 'jordan@devcamp.com',
  )
end

I will now comment all of it out. Just because our scaffold generator is not going to work without it. And I'm going to now create the code for our generator so that I can have it right here so I can see all of the data items I'm going to create. So I'll say rails g scaffold Proposal and if you're wondering why I'm using scaffolds because if you've taken any of my previous Rails courses especially my more advanced ones I said you shouldn't be using scaffolds all the time. One is because if you are familiar with Rails than I assume that you know how to build all this independently so there's no need to kind of go through the duplicate motion of doing this when we can have a generator do it all dynamically. If I was building this for a real-world client I'd probably use a resource generator but I really want to focus on the connection between angular and rails because that's really what this whole course is about is being able to build a microservice based architecture system that has microservices that handle data for specific features and then have those pulled in, communicated with, with a front-end application. So like I said real-world app I'd probably use a resource generator instead of a scaffold but it would definitely double the amount of time that we're spending going through the material and I think it would take away from what we want actually focus on.

So all of that being said that's the reason why I'm using scaffolds in case you're wondering. So I'm going to create a customer: and this is going to be of the type string. Next one is going to be a portfolio_url: which is going to be of type string followed by tools: which will be of type string, estimated_hours: which will be of type decimal then we have hourly_rate which will be of type decimal followed by weeks_to_complete which will be of type integer and then client_email: which is going to be of type string.

rails g scaffold Proposal customer:string portfolio_url:string tools:string estimated_hours:decimal hourly_rate:decimal weeks_to_complete:integer client_email:string

The reason I did this was just so that we could have it all on one line here and have it in the text editor, instead of typing it all directly in the terminal. I think it's a little bit easier for you to read. So here in the terminal, I'm going to come and I'm going to run our scaffold and this is going to run through and build everything for us. And now I can run

bundle exec rake db:migrate

I got an error. It looks like I never actually created the database so that would be a little bit of a problem. So I'm going to say

rails db:create

There we go. And now I should be able to migrate it.

bundle exec rake db:migrate

And we're good to go. So now if we go back in the code and look at the schema.rb file we see that we have "proposals" and it has all of these items. Now this is a question and this is something that I've thought about quite a bit when I was planning this application was, do we really need all of these items? So each one of these is specific to a proposal and you may think, for example, the only reason we are really sending the information like the email is when we want this application to email a client and then you may have the customer name and the client name but in the e-mail you're not going to send any of this information in. And if you think about it for longer than two seconds you may figure out the reason why. Remember this microservice is what's actually storing all the data. So even if we are going to send an e-mail out that only points to a link to the freelance app that freelance app is going to be pulling all this data in and so even when it seems like you may not be using it, the microservice is what is storing all the data and if that seems overly obvious and common sense than that's perfectly fine. The reason I wanted to clarify it is because there was a time where I was just staring at the code when I was planning this I was like why in the world am I sending all this data then a couple seconds later I realized oh yeah its because this is the only thing that's actually storing the data. This is our only database. There is no kind of persistence in the front end app it's all right here.

So all of that being said, I'm going to uncomment the code in the seeds.rb file so that we can go and create some proposals so let's come to the terminal and run

bundle exec rake db:setup

This is going to clear out the database and it's going to populate it. So now if I type in

rails c

and then type

Proposal.last

you can see that we have that there.

And now if I type

rails s -p 3002

because remember we have ports going at 3000 and 3001. I should be able to navigate in the browser to proposals. I'm going to go to localhost:3002/proposals and as you can see there are all of our proposals in JSON. So now that we have this application and we have it configured to work as an API we're going to go back to the angular side and build out the connection but we're not done with Rails yet because the reason why I'm doing this and following this pattern is because I want to show you how easy it is to add new features to an application without having to touch both sides of the application. So, for example, we're going to copy a lot of the same processes that we did in order to get our documents API working. But now what we're going to do is do that and then remember we have a big feature left here we want a feature where whenever we create a proposal then it will send an email out to the potential client that is going to have a link for them to go see the proposal. And so that's a pretty cool feature and it's going to be 100 percent based on the rails side. So I want I'm purposefully not adding the feature in right now so that after we have our API connections set up and we have that all working then I want to show you how we can come edit this module edit this microservice add in the feature and not a single line of code will have to change inside of the front end microservice. And that is one of the ultimate goals with this type of architecture is that you can work on different nodes you can work on different components in the whole architecture without them affecting the other one. So, in other words, we add this when we go back and we add this email feature we are going to be able to do it and not make any changes to the documents application or to the front end application. And that is exactly the goal that we have is to be able to separate all of our different kinds of goals so that every feature can live on its own.

Resources

• Code at this stage