Week 2 Diagnostic

week-2-diagnostic.markdown

1. Describe the request-response cycle. Start with the client making a request.

• The client makes a request which gets routed to the DNS. The request includes headers which have an HTTP verb, a path, and other relevant information. The DNS server tries to resolve the path, and if it cannot, it passes it off to other servies (like the .com server) that will eventually resolve the request and pass the ip address of the correct server back to the client. The client can then send the request to the correct server. Once the server receives the request, it processes it based on whatever was in the request and compiles a response which consists of a status code, other headers, and a body which is a string of HTML if something is going to be rendered (or some other string based on whatever the request was). The client can then render the string to the screen for the user.

2. Explain when each of these HTTP verbs would be used: GET, POST, PUT, DELETE.

• GET: get information from the server to view on the screen (possibly retrieve a record from a database table, or just get a view to render, or both)
• POST: send information to the server (usually create a record in a database table)
• PUT: update information in the server (usually a row in a database table)
• DELETE: remove information from the server (basically remove info from a database table)

3. What are all of the necessary routes for full CRUD functionality in Sinatra app? Why do we need seven routes when there are only four CRUD actions?

• GET x 2 (once to see an index of info, once to show a specific entry) = 'Read'
• POST x 2 (once to load a form, once to submit the form data) = 'Create'
• PUT x 2 (once to load an edit form, once to submit the form data) = 'Update'
• DELETE x 1 = 'Delete'
• There are 7 routes because CRUD is meant for a database so it doesn't match up exactly with web applications.

4. Describe the function of models in the MVC structure.

• Models interact with the database. They retrieve and store information from the database and are ruby objects that can then be used in the rest of the app. Models also interact with the controller, but not directly with the views.

5. Describe the function of views in the MVC structure.

• Views are what is rendered to the screen for the user. They interact with the controller. The controller renders the appropriate view for a specific route. Views do not interact with the model directly.

6. Describe the function of controllers in the MVC structure.

• The controller interacts with the views and the models. They receive the route request from the client, interact with the appropriate model to get (or put, post, or delete) info from the database, then determine which view needs to be rendered for the client. The controller is kind of like the 'smart' part of the application that is the bridge between the views and the models.

7. What is the difference between model tests, feature tests, and controller tests? Give an example of functionality tested using a model test, functionality tested in a feature test, and functionality tested in a controller test.

• Model tests only test one specific model and how that model interacts with the corresponding database table. If you have a table of kittens who each have a breed and a cuteness score, you could test that your model can calculate the average cuteness of all calico kittens.
• Feature tests are based on user stories, and are features that a user might interact with directly on your web app. For example, if your user can fill out a form to add their cute kitten to the cute kitten database, the flow of visiting the edit page, filling in the details, hitting submit, and then being redirected to the new kitten's page would be a feature test.
• Controller tests test that the correct response is given based on a certain request. So if your user tries to add a kitten that's already in the database, you might test that the controller responds with a 403 forbidden status code and a message saying the cute kitten can't exist twice because we don't clone kittens.
• PS - I'm a cat lady.

8. What does ActiveRecord do? Why do we use ORMs like ActiveRecord?

• ActiveRecord is a layer of abstraction on top of vanilla SQL code so that we can use SQL queries more easily (and naturally) on ruby model objects. Instead of having to directly run SQL code, we can do something like 'database.from(:kittens).where(:score => 10)' which reads much more like regular ruby code. Behind the scenes, ActiveRecord is actually sending the real SQL query to the database.