Parking Lot

20180625-20180626.md

Why isn't using POST for everything considered RESTful?

Context/Rephrasing: Why can't we use POST as the HTTP verb for every request/response in the HTTP request/response cycle?

In the mid-90's, when the web was new, everything was a GET or a POST. Through developing the HyperText Transport Protocol (HTTP) it was determined that this wasn't flexible enough, and opened many other HTTP methods (aka "verbs") such as PUT, PATCH and DELETE.

Even today, when the "web" is more than 20 years old, <form> tags will still only send data using GET or POST, but modern frameworks have a bit of a way around that, and there are other ways using JavaScript to send data using other methods/verbs.

When we consider how "endpoints" (URIs) are built in our applications, it's far easier to say "if I'm trying to GET this URI" or "I'm trying to DELETE something based on this URI" by having several different endpoints with short blocks of code, like this:

get '/tasks/:id' do
  ...
end

delete '/tasks/:id' do
  ...
end

If we processed everything as a POST method, our code would be far less friendly looking, and we'd need a LOT of branch logic to try to figure out what it was we were trying to do. We'd also need to pass lots of other data/parameters to know what it was we really wanted to do:

post '/tasks/:id' do
  if params[:what_i_really_meant_was] == 'delete' do
    # delete a thing
    # render a response or redirect
  elsif params[:what_i_really_meant_was] == 'put' do
    # update some attributes of a thing
    # render a response or redirect
  else
    ...
end

This code is far bigger, making it more prone to bugs, and also puts more work on the presentation layer to also send extra parameters to override or otherwise indicate your true intention.

---

YAML, wat dis?

Context/Rephrasing: While talking about database setups, someone asked what YAML is.

YAML is another Markdown Language (the ML in YAML). It's actual name is "YAML Ain't Markdown Language". It's a way of storing data, usually for configuration data, in an heirarchical indentation-based format, like this:

database:
  development:
    name: my-project-development
    username: superuser
    password: soop3rs3cr3+

We don't get into YAML in mod 2, you may see it deeper in mod 3 and onward.

---

Is ActiveRecord based on a design pattern

Context/Rephrasing: We discussed how MVC is a "design pattern", then shifted into an ActiveRecord class.

Technically, ActiveRecord is kind of a combination of a number of other design patterns, depending on how you configure your application. For example, if you only ever want one connection to your database for your app, ActiveRecord may use a Singleton pattern to give you a 'single' connection. But if you want database "pooling" where you have multiple connections to the database, ActiveRecord may use the Factory pattern to crank out lots of similar things. It may also use the Factory design pattern for generating lots of models, etc..

Some call ActiveRecord an Anti-Pattern, because they feel ActiveRecord doesn't really follow certain rules or conventions that they expect an ORM to have.

TL;DR: no, but don't worry too much about "design patterns" in mod 2.

---

Can you define "endpoints"

Context/Rephrasing: We were discussing how to build URI's, and I may have called them "endpoints"?

An "endpoint" is a "URI" path, the portion of the URI that does not contain the domain name.

Remember it this way:

• http://google.com/tasks/4 -- this is a URL because it includes http:// telling us HOW to get the resource
• google.com/tasks/4 -- this is a whole URI that defines a unique resource
• /tasks/4 -- this is also a URI, but what we call an "endpoint"

---

What is a Production Environment

Context/Rephrasing: We were discussing model testing and to make sure we were only including certain gems like a database scrubber in our "test" group in our Gemfile, and that we'd never want those kinds of things in our "production" environment.

As we develop our software, we generally have 3 or 4 different environments in which we work:

• Development

  • This is how we build our applications on our laptop, we have a rudimentary version of everything installed
  • Our laptops are fast for small data sets, so this is optimal
  • Very verbose errors and stack traces

• Testing

  • This is how we test that our code behaves as we expect (#aaawtf)
  • We generally run this on our laptops but we can also set up external servers to constantly run our tests too
  • Very verbose errors and stack traces

• Staging

  • Some companies will put your application on a server that works/acts a lot like what the actual production environment is going to be -- real server hardware.
  • Will generally access a limited version of the real database so you can still test your application in a "real world" environment, but don't have to worry about breaking real customer data
  • Error messages are likely logged instead of sent as stack traces in the browser

• Production

  • These are the full servers that answer real requests on the Internet for your customers.
  • Your application is in front of real users' eyeballs and needs to run quickly and smoothly.
  • Error messages here are user-friendly and hide things like stack traces because we don't want to expose how our code works. Errors are typically logged into a separate database to track recurring problems.

---