Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Phoenix: Inflame the Web - Alex Troush

275 vues

Publié le

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)

Publié dans : Logiciels
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Phoenix: Inflame the Web - Alex Troush

  1. 1. Phoenix: Inflame the Web @troush69 | github.com/Troush
  2. 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. 3. Ahhahhhahah…
  4. 4. Presentation.Supervisor.start_link(self(), {:slide, 1})
  5. 5. Все любят этот слайд 40core/128gb box. 2 million clients, limited by ulimit
  6. 6. Phoenix Structure The Endpoint The Router Controllers Views Templates
  7. 7. mix phoenix.new kyiv_elixir
  8. 8. Mix file
  9. 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. 10. KyivElixir Application
  11. 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
  12. 12. Plug Module
  13. 13. Plug Function
  14. 14. Plug Function
  15. 15. 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
  16. 16. 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
  17. 17. Complex Action
  18. 18. Pattern Match Them ALL
  19. 19. Override Action Dispatch Function
  20. 20. Core Association
  21. 21. Let’s Talk Ecto
  22. 22. Ecto is a domain specific language for writing queries and interacting with databases in Elixir
  23. 23. Ecto Example. Controller delete action
  24. 24. Owner.ex model file
  25. 25. Views ● render templates ● act as a presentation layer ● define helper functions, available in templates, to decorate data for presentation
  26. 26. Override render function
  27. 27. Templates are what they sound like :) are precompiled and fast
  28. 28. form_for
  29. 29. Current Folder Structure
  30. 30. 1.3 Folder Structure
  31. 31. Your controller is not a Repo interface
  32. 32. Your controller is not a Repo interface
  33. 33. Your controller is not a Repo interface
  34. 34. Umbrella Apps
  35. 35. Phoenix is not your App
  36. 36. New Umbrella App
  37. 37. # issue/lib/issue/ticket.ex
  38. 38. $ cd apps/ $ mix phoenix.new issue_web
  39. 39. Don’t write large apps
  40. 40. Application is your microservice
  41. 41. Channels
  42. 42. Phoenix.Transports.*
  43. 43. 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
  44. 44. 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.
  45. 45. 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
  46. 46. $ mix phoenix.gen.html Issue issues name:string description:string $ mix phoenix.gen.channel Issue
  47. 47. #channels/issue_channel.ex
  48. 48. Phoenix.Channel Callbacks handle_in(event, msg, arg2) handle_out(term, arg1) join(topic, auth_msg, arg2) terminate(msg, arg1)
  49. 49. join(topic, auth_msg, socket) To authorize a socket in join/3, return {:ok, socket}. To refuse authorization in join/3, return {:error, reply}.
  50. 50. 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
  51. 51. 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
  52. 52. 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
  53. 53. handle_out(event, payload, socket)
  54. 54. 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.
  55. 55. Conclusion R.I.P web/ models/ Channels are cool simple handle_in / handle_out broadcast
  56. 56. Questions?