Phoenix is productive, reliable, fast web framework. In this presentation, we will be talking about what making Phoenix unique. We will discuss using OTP features alongside with Phoenix.Endpoint. Also, we will discuss Phoenix future changes. Elixir Meetup 4 Lviv (17.12.2016)

1. Phoenix: Inflame the Web
@troush69 | github.com/Troush

2. 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

3. Ahhahhhahah…

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

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

6. Phoenix Structure
The Endpoint
The Router
Controllers
Views
Templates

7. mix phoenix.new kyiv_elixir

8. Mix file

9. 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.

10. KyivElixir Application

11. 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

13. Plug Module

14. Plug Function

15. Plug Function

16. 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
● Pipelines
o allow easy application of groups of
plugs to a set of routes

17. 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

18. Complex Action

19. Pattern Match Them ALL

20. Override Action
Dispatch
Function

21. Core Association

22. Let’s Talk Ecto

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

24. Ecto Example. Controller delete action

25. Owner.ex model file

26. Views
● render templates
● act as a presentation
layer
● define helper functions,
available in templates, to
decorate data for
presentation

27. Override render
function

29. Templates
are what they sound like :)
are precompiled and fast

30. form_for

31. Current Folder Structure

32. 1.3 Folder Structure

33. Your controller is not a Repo
interface

34. Your controller is not a Repo
interface

35. Your controller is not a Repo
interface

36. Umbrella Apps

37. Phoenix is not your App

38. New Umbrella App

41. # issue/lib/issue/ticket.ex

42. $ cd apps/
$ mix phoenix.new issue_web

44. Don’t write large apps

45. Application is your
microservice

46. Channels

47. Phoenix.Transports.*

48. 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

49. 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.

50. 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

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

55. #channels/issue_channel.ex

57. Phoenix.Channel Callbacks
handle_in(event, msg, arg2)
handle_out(term, arg1)
join(topic, auth_msg, arg2)
terminate(msg, arg1)

58. join(topic, auth_msg, socket)
To authorize a socket in join/3, return {:ok, socket}.
To refuse authorization in join/3, return {:error, reply}.

59. 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

60. 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

61. 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

62. handle_out(event, payload,
socket)

63. 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.

64. Conclusion
R.I.P
web/
models/
Channels
are cool
simple
handle_in / handle_out
broadcast

65. Questions?