Phoenix: Inflame the Web

@troush69 | github.com/Troush

Alex

~7 Commits to Elixir Core

~1 Commit to Phoenix.HTML

~2 Commits to Ecto

3 month of production Phoenix

~ 1 year of Elixir lurking

Ahhahhhahah…

Presentation.Supervisor.start_link(self(), {:slide, 1})

Все любят этот слайд40core/128gb box. 2 million clients, limited by ulimit

Phoenix Structure

The EndpointThe RouterControllersViewsTemplates

mix phoenix.new kyiv_elixir

Mix file

In Elixir (actually, in Erlang/OTP), an application is a component implementing some specific functionality, that can be started and stopped as a unit, and which can be re-used in other systems.

KyivElixir Application

Endpoint● handles all aspects of

requests up until the point where the router takes over

● provides a core set of plugs to apply to all requests

● dispatches requests into a designated router

Plug Module

Plug Function

Plug Function

The Router● parses incoming requests and

dispatches them to the correct controller/action, passing parameters as needed

● provides helpers to generate route paths or urls to resources

● defines named pipelines through which we may pass our requests

● Pipelineso allow easy application of

groups of plugs to a set of routes

Controllers● provide functions, called

actions, to handle requests● Actions

o prepare data and pass it into views

o invoke rendering via views

o perform redirects

Complex Action

Pattern Match Them ALL

Override Action

Dispatch Function

Core Association

Let’s Talk Ecto

Ecto is a domain specific language for writing queries and interacting with databases in Elixir

Ecto Example. Controller delete action

Owner.ex model file

Views● render templates● act as a presentation

layer● define helper

functions, available in templates, to decorate data for presentation

Override render

function

Templates

are what they sound like :)are precompiled and fast

form_for

Current Folder Structure

1.3 Folder Structure

Your controller is not a Repo interface

Your controller is not a Repo interface

Your controller is not a Repo interface

Umbrella Apps

Phoenix is not your App

New Umbrella App

# issue/lib/issue/ticket.ex

$ cd apps/

$ mix phoenix.new issue_web

Don’t write large apps

Application is your microservice

Channels

Phoenix.Transports.*

Phoenix.Socket.Transport behaviour

Implementing the transport behaviour

Establishing the socket connection

Handling of incoming messages

Handling of outgoing messages

Managing channels

Providing secure defaults

Phoenix.Transports

The transport allows to abstract away how upper layer i.e. channels receives or sends messages. Channels only need to call the right function of transport module and let it handle the raw work of communication.

Channel

Channel has two components, one is the channel behavior implemented by the developer and the second is the channel GenServer that is spawned up by phoenix that consumes the developer written module.

Communicating with the transport (receiving from & sending to transport)

Listening for requests to send a message that was broadcasted

$ mix phoenix.gen.html Issue issues name:string description:string$ mix phoenix.gen.channel Issue

#channels/issue_channel.ex

Phoenix.Channel Callbacks

handle_in(event, msg, arg2)

handle_out(term, arg1)

join(topic, auth_msg, arg2)

terminate(msg, arg1)

join(topic, auth_msg, socket)

To authorize a socket in join/3, return {:ok, socket}.

To refuse authorization in join/3, return {:error, reply}.

handle_in(event, payload, socket)After a client has successfully joined a channel, incoming events from the client are routed through the channel’s handle_in/3 callbacks

Replay

In addition to pushing messages out when you receive a handle_in event, you can also reply directly to a client event for request/response style messaging

Intercept & handle_out/3

When an event is broadcasted with broadcast/3, each channel subscriber can choose to intercept the event and have their handle_out/3 callback triggered

intercept ["new_msg", "user_joined"]

So on “new_msg” and “user_joined” topics handle_out will be triggered

handle_out(event, payload, socket)

Terminate

On termination, the channel callback terminate/2 will be invoked with the error reason and the socket.

If we are terminating because the client left, the reason will be {:shutdown, :left}. Similarly, if we are terminating because the client connection was closed, the reason will be {:shutdown, :closed}.

If any of the callbacks return a :stop tuple, it will also trigger terminate with the reason given in the tuple.

Conclusion

R.I.Pweb/

models/

Channelsare cool

simple

handle_in / handle_out

broadcast

Questions?