TIL_17_Jul_2017 - Phoenix programming - Part 1 - Basic structure

[vinhnglx]

• Just remind again, |> aka pipe operator, takes the value on the left and passes it as the first argument to the function on the right - it's called pipelines.

There's a side benefit, pipelines are also functions - means you can make pipelines of pipelines. For example, what a Phoenix program might look like, using pipelines:

connection |> phoenix

• The layers of Phoenix:

  • From a classic HTTP request.

    connection
    |> endpoint
    |> router
    |> pipelines
    |> controller

  • Inside controller

    connection
    |> controller
    |> common_services
    |> action

[vinhnglx]

• Phoenix uses Brunch for asset pipelines - thank god, they didn't create their own asset pipelines. But I need a try with Brunch. I used Grunt, Gulp, Webpack (a little bit) but never heard about Brunch. lol. ....

[vinhnglx]

[debug] Processing by Kitty.HelloController.world/2
  Parameters: %{"name" => "vincent"}
  Pipelines: [:browser]

This is an example about process a parameter from outside in Phoenix. The external parameters have string key "name" => "vincent", because external data can't safely be converted to atoms, because the atom table isn't garbage-collected.

[vinhnglx]

• Atoms are really nice and a great way to send messages or represent constants. However, there are pitfalls to using atoms for too many things: an atom is referred to in an "atom table" which consumes memory (4 bytes/atom in a 32-bit system, 8 bytes/atom in a 64-bit system). The atom table is not garbage collected, and so atoms will accumulate until the system tips over, either from memory usage or because 1048577 atoms were declared.

This means atoms should not be generated dynamically for whatever reason;

[vinhnglx]

• The code in web directory is reloaded, and the code in lib isn't. lib is the perfect place to put long-running process, like Phoenix's Pub Sub system, database connection pool or any your own server processes.