[MUSIC] In this lecture, we're going to be talking about Technical Architecture, the capabilities and technologies that'll be making up our solution. And we're going to be breaking that down into layers so it'll be easier to talk to. We'll also address the Deployment Architecture. How we're going to take things like the API and the database and deploy them outside of the development environment and make them accessible by the Internet? And how we have different options in how we're going to be deploying our web client? Now some people might think of this lecture as a bit of an alphabet soup. We're going to be talking about a lot of capabilities and technologies in a short amount of time. But I would prefer to think of it as an organized walk-through of vocabulary that's going to span the overall course. And hopefully build an overall bounding context to what you're going to be learning in order to build an end to end full stock application that we're going to be able to access and collaborate, and administer, dealing with photos, information in that. When we go over to the technical architecture, we'll be going over bottom to top as you see them laid out in this diagram. And we will be covering about seven areas within the application before following up with two areas of development and testing and then wrapping up with deployment. Let start out by talking about where we're going to store things, whether they'll be in a database or a file. On the relation database side, we have access to two databases, SQLite and Postgre. SQLite comes with Rails but think of it as more of like an early learning database or the database that you would use if your application have very low dependency on SQL constructs. PostgreSQL on the other hand is a fully supported production database that you use during Course 2 when you deployed to Heroku, except that in Capstone I'm going to promote that you use it during development as well to lessen the transition between development and deployment. To cut down on the amount of time that when you go to deployment you find out I gotta fix this, I gotta fix that. Why don't we have the same thing in both environments? Our interface to the database is primarily going to be ActiveRecord that puts a very nice Object/Relational Mapper in front of us, where we talk objects and methods to our data. There are times, however, when we're going to want to drop down into SQL for complex queries. Cases where we might build up snippets of where clauses and select clauses or there are going to be times where we're going to want to do full scale just raw sequel commands, like for the unions and things, to give us more power. During the course of the semester we're going to be using the relational database to store our core business objects and their relationships. They could have been stored in Mongo but our choices would have been more limited, and we have much more flexibility by storing them into the relational database. We're not tied down since we don't know all the ways that we're going to want to use the application. We're also going to use our relational database to store user accounts. Now we could have put our user accounts into either the relational database or Mongo, however, there were certain gem choices made that forces to stay into the relational database side. We're also going to make use of the MongoDB No SQL Database as part of the course. Primarily as a content store and a persistent cache. This of course consists of MongoDB and also we're going to use Mongoid as the object document mapper as we did in course 3. It provides a nice active record like interface to the back end document store. We're not going to be making use of GridFS as we used in course 3. And we're not going to need to drop down to the raw MongoDB Ruby API. The Mongoid API is going to be good enough for how we're going to use Mongo as a part of the course. Now, as I said, we're going to use MongoDB for storing image content. One of the primary obstructions for storing image content is a file. And many of the gems that we had as a choice of using if we had used the file obstruction, we could have used them right out of the box, and then you could have done things a lot more seamlessly than we'll be doing in the course. However, when you go from development to deployment in Heroku, there is no such thing as an out-of-the-box writable persistent store that's guaranteed to be there during the life of your application. What you need to do is bring in sort of like an Amazon File Services and things like that. And rather than do that, I was like, we'll we have Mongo, why don't we just go in and use it kind of like we did in course 3, where we were restoring files in there. Except there was no need to bring in GridFS. Because everything's going to be a bounded size under 16 megabyte document limit. And they're not going to be infinite in size. So rather than using GridFS, you just use the BSON::Binary type and store it within a document. Those documents were related to our relational database which has the business object that we have a photo on file. In Mongo we're going to store the actual content of the photo and serve that out to our users. Also going to use it as a persistent cache. We're going to contact the Google geo code API in order to find positioning. Well, we are metered in how many requests we make. And Google advises us that we ought to cache the answers that come back. And this is exactly what we're going to do inside of Mongo. We're going to normalize our query parameters and use those as primary keys into the cache, and then we're just going to store the resulting document so that follow on calls, we're not having to go out to Google but we can just grab what it said the last time. Pretty neat, very easy. On the browser side, we're not going to make direct use of any file storage. However, we are going to use a module, the ng-token-auth module that's going to store Current login information into the Browser Cookie Store so that when we refresh the browser or come back another day, we're not going to have to constantly re-authenticate ourselves with the application. Let's take a look at some of the application frameworks and languages that we'll be using during the scope of the course. On the server side, of course we're going to have Rails. And we're going to stick to version 4 in order to be consistent with the first three courses that you've taken. Even though version 5 has been out, it won't be a problem. But if you're Googling and you find yourself on a Rails 5 documentation site, please be aware that you might be looking at some Rails 5 specific extensions. I find that not to be a problem much at all. And if it did was a problem, it was more esoteric areas and ActiveModel. But I don't see it being an issue. On Web Servers, version 4 comes with WEBrick. Version 5 is apparently switching to Puma. It's just a different web server. You can put WEBrick back in. There are other web servers that we won't be discussing during class like in the past I've used the Thin, T-H-I-N web server. I liked it because on the platform I was developing on from command lined up and running was fractions of a second, whereas WEBrick, in that particular platform I was using on actually took tens of seconds to come up. The actual servers themselves. WEBrick is more development, single threaded, pretty mundane. And when you deploy, I guess you can deploy the WEBrick. But in this course I'm going to try to get you use to being able to switch web servers. So develop however you want to develop, WEBrick or Puma and matter of fact if you're on Windows you're going to be forced not to develop in Puma. But Puma is multi-threaded environment which obviously is a much better for production. But not necessarily for development. Like for example, I find that if I'm debugging a live application server and I put a byebug or a binding pry breakpoint in the server. If I'm in WEBrick, everything seems sane. It stops and continues and lets me stop it as long as I want and go around. Whereas in Puma and that multi threaded environment, if I pause the application server for more than about 30 or 60 seconds I pretty much have to trash that session and restart a new one in order to continue. It doesn't play as well with breakpoints. But it starts up pretty quick and I typically use it as a default because most of my debugging is in my unit testing. One of the other things that we're going to be adding to Rails is the API to the Rails-api gem. And what that does is, it scales back Rails into a set of gems that are geared more towards just being an API and database server on the web. It takes away, by default, some of the things that you're used to with views and the asset pipeline but we can put them back and as a part of this course I'll show exactly how to put them back into the overall framework as we need them. We're also of course going to be using ActiveModel and Ruby which could be infinite in what we talk about in this marvelously dynamic language. On the client side, we're going to be making use of, of course, AngularJS version 1.5 in order to stay consistent with what you covered in Course 5. AngularJS is a Javascript framework and it helps us build components that are going to manipulate HTML with the use of CSS in order to give ourselves a nice client interface. As we take a look at the languages involved in our full stack solution, Ruby, Javascript, HTML, CSS, you're going to find yourself with plenty of opportunities to make some tactical errors because you're thinking that your fingers were thinking that they're in the previous language. Don't be too hard on yourself, it happens to me all the time. So if you spend a better part of the week working on the JavaScript side of the house and then you go work to Ruby and start writing the Ruby with a JavaScript-ish Syntax it may take you an extra couple of minutes to remember some of your old tricks but you'll be fine. I'm want to pause coverage of the technical architecture where in this one we got the ball rolling, talking about the overall scope. And the first two of the seven core application areas that'll be part of the Capstone and those two areas being in the database in persistent storage and application frameworks. Up next, well we'll finish out the topics. The seven core topics plus testing, development, and deployment.
