Technical and Deployment Architecture (Part 2)

Loading...

Del curso dictado por Johns Hopkins University

Capstone: Photo Tourist Web Application

18 calificaciones

Johns Hopkins University

Capstone: Photo Tourist Web Application

18 calificaciones

Curso 6 de 6 en SpecializationRuby on Rails Web Development

In this Capstone project for the Photo Tourist you will implement a Ruby on Rails web application that makes use of both a relational and NoSQL database for the backend and expose the data through services to the Internet using Web services and a responsive user interface operating in a browser from a desktop and mobile device. You will have a chance to revisit and apply what you have learned in our previous courses to build and deploy a fully functional web application to the cloud accessible to your co-workers, future employers, friends, and family. In developing the Photo Tourist web application, you will get to work with different data types and data access scenarios (e.g., fielded data display and update, image upload/download, text search, access controlled information) to provide your users the ability to show off their photos and information from trips they have taken and to seek out photos and information from trips taken by others. Using the application you develop, your users will be able to • Create an account • Upload and download photos to the site and make them accessible to others • Provide descriptions of trips and photos that others can read • Organize photos by location and trip, • Find photos based on location • Find photos based on text searches of descriptions • Locate the place where the photo was taken on a map

De la lección

Technical Architecture and API Development Setup

In this module, we will start your journey into being part of an end-to-end application development as a Rails/AngularJS fullstack developer intern. You will learn the technical architecture and software requirements of the targeted application you will be a part of developing. You will also get a chance to shake off any rust that may have accumulated on your Rails development skills. As a part of the technical architecture, you will learn of the various layers, technologies, libraries, and services used in the development, deployment, and operation of the targeted application. You will get an early sense that this course is "no joke" when it comes to challenges, but you will be shown a path through most of them. You may be able to skip the application installation until the end if you are using the same computer that you used in the first five (5) courses of the specialization. None of the new software installations are required for this module -- but are included in a single lesson for modularity. You will develop an end-to-end, API-to-Database, resource solution for ActiveRecord/RDBMS and Mongoid/MongoDB using Rails scaffold generator. You will establish a Git repository for this work, provision database and Rails resources on the internet for staging and production deployments, and deploy your solution to the Heroku to be accessible from the Internet. If you are a seasoned Rails developer and competent with ActiveRecord, Mongoid, and Heroku -- you may want to initially skip the review lectures, review the final Git commit for module one (1), and try your hand at the optional assignment at the end. Aside from the technical architecture lesson, this module is mostly a quick breeze through many of the topics of courses one (1) through three (3). A similar, small-scale review of courses four (4) through five (5) will be covered in the next module. Please enjoy! Also, if you have not done so already I recommend that you read the Course Overview description which provides additional context on what you will be doing in this course. To access, please click the Resources tab on the left navigation.

Course Introduction7:15

Module 1 Introduction3:44

Technical and Deployment Architecture (Part 1)11:22

Technical and Deployment Architecture (Part 2)14:31

Technical and Deployment Architecture (Part 3)14:15

Development Environment Setup4:56

Software Installation: MacOS13:49

Software Installation: Specifics for Windows29:39

Software Installation: Specifics for Linux and Docker15:49

Conoce a los instructores

Jim Stafford
Adjunct Professor, Graduate Computer Science
Computer Science, Whiting School of Engineering

[MUSIC]

Welcome back.

In this section, we're going to finish up the last five topics of the core

application architecture areas which deal with security, image handling,

geocode and geolocation queries, maps and communications.

That fills out the lower potion of the core application stack.

Now remember,

the purpose of going through this is not to teach you specifically these topics.

It's just to give you a picture of the overall

scope of the application we're going to be dealing with in the capstone.

One of the main purposes of the capstone is to do something useful with

the different technologies you've been learning in the other courses.

And what useful application wouldn't involve some form of authenticated

access to the application?

Whereas we might need to establish accounts, we might need to login, logout,

and we might need some role specific authorizations.

For example, in our application,

it's an information collaboration with images and things.

If I post an image, who's allowed to edit or delete that image?

If I am managing a thing,

who's allowed to see the details of the thing that I am posting?

On the server side, we're going to be making use of the Devise gem.

The Devise gem is a very mature and commonly used solution for

account management and core authentication.

And Devise has countless other extensions,

which can make it a very complicated gem to research and fully understand.

However, keeping it at its core account management and core authentication

capabilities is rather trivial, or rather simple and straight forward.

And if we're able to insert this very

popular gem in the middle of our application, we will open ourselves to

countless amounts of authentication schemes throughout the Internet.

Devise does support ActiveRecord.

It also supports Mongoid.

However, another gem that we'll be adding on top in order to

help support web services, the devise-token-auth gem, does not,

though our choice was reduced back to just doing ActiveRecord and

putting our credentials in the relational database.

Meeting in the middle and implementing our web services authentication

is the devise-token-auth gem and

the ng-token-auth module that is provided by the same developer.

The devise-token-auth gem interfaces with Devise and the user store in the active

record in order to implement the web service bearer token protocol.

In the web service bearer token protocol, the client is going to authenticate and

the gem is going to generate a token which needs to be supplied on the next request.

That token or

some tracking of that token is going to be stored into the active record database.

On the client side, the ng-token-auth is taking care of authentication

with a user password prompt and then remembering the bearer taken and listening

to the htp protocol going on between the client and the server within Angular.

And sucking off the token and

putting it on to the next request in keeping track of the token switchovers.

The module also takes advantage of the browser cookie store.

And will store whatever it needs in order to recover from a browser refresh or

if we log out of our machine and log back in the next day to be able to start out

with the next bearer token that's involved.

Now if the bearer token expires,

then we're right back in a login authentication.

If we come back soon enough, we're able to pick up where we left off.

For authorization, there is no end-to-end solution, but

where we can start is with the Pundit Authorization Gem.

This a lightweight framework that allows us to isolate authorization decisions

from business logic, keeping the two from being intertwined with one one another.

And then in support of the client we can do something like server-side redaction,

making sure that information the user has no access to they don't get it.

We also can do server-side marking and say, the user who asked for

this information has the following roles relative to this information.

Then on the client side, what we can do is use standard directives like ng-f,

ng-show, ng-hide.

And be able to add or remove certain buttons from the user's ability.

If the client were to make those requests,

the server would simply say, you're not authorized to do those kinds of things.

But on the client side, we don't want the client to get that far.

So we will use those markings and these conditional content directives

in order to provide them the correct user experience relative to that information.

One of the main emphasis of the capstone is photo sharing.

And let's face it, photo sharing is fun.

We like to share photos of our trips that we're going on, and

we'd like to do that within our application.

However, obviously, if we're going to share photos within our application,

we're going to have to address image handling.

And one of the first use cases that we're going to have to solve with image handling

is where we get our photos from.

And we bring in a particular module, and on the Angular side,

an ng-file upload, which through a simple input tag and

some extra configuration are going to be able to read the photo

directly from the camera or from a file system, if that's where the source is.

Now one of the problems we have to solve with getting all these collaborative

photos is consistency.

And so what we need to do is insert a module that will give us the ability to

crop these images to a consistent aspect ratio.

And we bring in ngImgCropFullExtended.

ngImgCropFullExtended does integrate directly with ng-file-upload.

And it's a fork of the ng-img-crop module that's also available on the Internet.

And you'll see a lot of documentation that speaks in terms of ng-file-upload and

ng-img-crop.

However, you'll also notice that ng-img-crop hasn't been updated in

over two years.

And most of the updates to that library have been carried forward

recently into the image crop full extent fork.

And so that's what we'll be using.

We're going to restrict our applications to jpg images, and when the client

posts the jpg image to the server, there's a number of things that have to be done.

And one of the first things that has to be done is to determine

the dimensions of the incoming image.

And what we're going to do is take advantage of the EXIF information

that's available inside of a JPEG that has that simple information and

use the EXIF reader gem in order to pull that out.

Now when we work with images,

we're going to want to work with images of different sizes.

There are times where we're going to want full size images,

and there are other times where we're just going to want thumbnails for lists.

And so when we get our original in, we're going to want to turn around and

create a standard set of sizes that our clients know that they can extract.

In order to create those sizes, what we're going to do is take advantage of

a negative image manipulation software called ImageMagic.

We're going to install that locally and hand it jobs to do, and

it's going to give us back the images to work with.

In order to interface with that, there were a number of choices.

MiniMagic is probably the most simplistic, and that's really all we need,

which we need to resize our images.

So it's a gem that basically gives us a shell interface

to this native application that we're going to install locally.

And at the end of this use case, when the image is posted to the server,

we should have one file, the original image, as well as about three

to five different sizes that clients can request based on size.

So what good is a picture of a place or a thing if you don't know where it is?

Is it a mile from us?

Is it 50 miles, 1,000 miles, or the other side of the Earth?

So what we would like to do is add some geocode information so

we can give the user perspective of where these things are.

When we speak of geolocation, we're primarily talking about

marking objects with latitude and longitude information.

Now our business objects are in ActiveRecord relational database, so

that's where we're going to need to place them.

If you remember in course three we added latitude and longitude information to

the Mongo database, and used Mongo's built-in geolocation capabilities.

But we're not going to have access to that if we put them in the relational side.

So what we're going to do is on top of the relational database in ActiveRecord,

we're going to add a gem called Geokit Rails,

which gives us geolocation queries that gives us the same effect.

How far is it from an origin?

Order things based upon distance and good capabilities like that for

the relational database side.

Okay, now that we have a place to store the lat and

long for business objects in the relational database,

we need to be able to get that information from some source.

Enter the Geokit gem, which is going to help us query

Geocode providers where what we're going to do is supply them a lat and

long, where we're going to supply them a partial street address.

And they're going to be able to give us full location information back,

and which we can store or keep around what we want.

And the provider we're going to use is the Google Maps Geocode Service.

This is a free service below 2,500 requests per day.

All we need to do is sign up for a free API key, and

bake that into our application.

Now one of the things that Google does recommend is that you put

some kind of persistent cache on your side, which we will do,

that as you ask Google questions and you get a response back,

you should cache that for a period of time so that you don't exceed your limits.

So what we're going to do is we're going to take Mongoid and MongoDB.

And we're going to key it up by latitude, longitude, and a normalized address.

And remember, the answer's coming back from Google so

that we can stay within license constraints.

In order to give our users the best perspective of the photos and

the things they're about, we would like to show their position on a map.

Our map is going to be able to show them images and

information about our tourism area.

To implement the maps is conceptually straightforward.

We're going to integrate the Google Maps JavaScript API into our Angular

application and then we're going to obtain the Geocode information with the lat and

long in business data from our API, and

ask the library to display that onto the map.

Now the Google Maps Service is free for under 2,500 page reloads a day,

which is well within the bounds of what we'll need for our application.

And when we finish, we'll have something pretty cool and pretty useful for

you to continue to play with.

To round out the core application,

we're going to be finally talking about communications.

And in order to have some simplicity about our application,

we're going to restrict things to just JSON.

And on the server side, what we have as our core implementation or

our logical framework is the Rails Controller,

which supplies RESTful interface to our resources.

We explored that in great detail in course three,

as well as some other implementation details in course two.

Hidden behind the scene is Rails ActionPack, which handles communications

from request to response and all the layers that it has to go through.

We don't really see all that going on, but our successful communication relies on it.

For JSON marshalling, we're going to take advantage of the same implementations that

we used in courses two and three to keep some consistency.

It is a DSL paste in the view of the model view controller and

it forms the marshall output that the client is going to consume.

As I said, it's one of many different JSON marshalling options.

There are others that are more language-based that can be more

performant and have more features to them.

This is more document-based that allows us to describe the information

in more document form.

On the client side, we're going to take advantage of a module called ngResource,

which provides a RESTful client to the resource and

access like the peer to the rails controller.

It's implemented on top of the HTTP

servers that you used quite a bit in course five.

However, it has more RESTful kinds of semantics to it, and how things are done.

Now under the covers, when you do actually have to change the payloads and

do some manipulation, we will rely on Angular built-in JSON marshalling,

in order to hand JSON back over to ngResource,

in order to complete that overall protocol stack.

We have finished going through the remaining five of the seven

core application areas, which those being security,

having authentication and authorization, image handling,

handling everything from a file upload to resizing and storage.

Geocode and geolocation queries and

getting information from the Google maps Geocode API, mapping,

and integrating in all of our geolocation information and

business information in with Google Maps and

communication in order to exchange JSON information to and from the server.

What we're going to go to next is to finish up the technical architecture and

talk more about development through deployment.

Explora nuestro catálogo

Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.

Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.

© 2018 Coursera Inc. Todos los derechos reservados.

Descargar en la App Store

Consíguelo en Google Play