Phoenix for Rubyists with notes

Introduction to Elixir and Phoenix

Transcript

1. Phoenix for Rubyists Concurrency and Scalability with Productivity by Doug Goldie Code Cauldron
2. Why New Language ? Scalability Concurrency Productivity of Rails Why New Language or Framework?
3. Moore’s Law is Dead! number of transistors in a dense integrated circuit doubles approximately every two years. We are seeing more multi-core machines with more cores. The observation is What are we getting …. more chips, more multi-core machines.
4. What do we need? Handle Multicores Distributed Systems Massive concurrency But still with Productivity
5. What do we build? Any Web Applications Distributed Systems But we still want productivity
6. The Answer Phoenix Elixir Erlang
7. What do we build? Any Web Applications Distributed Systems But we still want productivity
8. Any Web Application Classic CRUD monolith Single page app (SPA) - with any frontend Realtime app productivity and performance.
9. Distributed Systems Small distributed apps. Large-Scale distributed, fault-tolerant system Phoenix as the Web component Elixir for the other components. productivity and performance.
10. Agenda Elixir in 10 minutes Basic Phoenix app Real-time app Distributed systems Some really contrarian, disruptive ideas !! - Rails like demo - Non-rails like demo - realtime - web component for a distributed, fault tolerant system - use this platform to do things in a really contrarian way.
11. Elixir
12. Elixir in 10 minutes placeholder
13. Basic Web Application
14. Phoenix demo Classic Rails example
15. Real-time Application
16. Real-time Features Phoenix Channels Topics Elixir & Erlang Massive concurrency Actor model Processes
17. Processes • lightweight, small memory, fast to create and terminate • message passing • no shared data • links and monitors • error handling Erlang is designed for massive concurrency Erlang is designed for massive concurrency. Erlang processes are lightweight (grow and shrink dynamically) with small memory footprint, fast to create and terminate, and the scheduling overhead is low.
19. Chat demo Classic real-time example Phoenix channels / topics
20. Server A HTTP Server Nginx and Phusion Passenger Request processing Ruby on Rails Long-running requests Go Server-wide state Redis Persistable data Redis / MongoDB Background jobs Cron, Bash scripts, and Ruby Service crash recovery Upstart Server B Erlang Erlang Erlang Erlang Erlang Erlang Erlang A real world Rails app needs other software. other things: sidekiq, docker, ???
21. Server A Server B Erlang Erlang Erlang Erlang Erlang Erlang Erlang A real world Rails app needs other software. other things: sidekiq, docker, ???
22. Distributed Systems
23. HTTP Server Nginx and Phusion Passenger Request processing Ruby on Rails Long-running requests Go Server-wide state Redis Persistable data Redis / MongoDB Background jobs Cron, Bash scripts, and Ruby Service crash recovery Upstart Erlang Erlang Erlang Erlang Erlang Erlang Erlang Server A Server B This isn’t just large-scale problems. We build distributed systems all the time. A real world Rails app needs other software. other things: sidekiq, docker, ???
24. Of course there are large-scale problems to solve.
25. Hard Problem to Solve
26. with only 10 engineers! In 2014, sold for $19 Billion. 465 million users 550 servers
27. Erlang History Developed over 25 years ago by Ericsson for building Telcom products Released as open source in 1998.
28. Requirements • high concurrency • distribution • fault tolerant • soft realtime • high availability • external interfaces • hot code upgrade
29. –Robert Virding “Erlang is for building systems.”
30. Processes • basic unit of work • message passing • no shared state • high concurrency Erlang is designed for massive concurrency. Erlang processes are — lightweight (grow and shrink dynamically) — with small memory footprint, — fast to create and terminate, and — the scheduling overhead is low.
31. Processes • lightweight, small memory, fast to create and terminate • message passing • no shared data • links and monitors • error handling Erlang is designed for massive concurrency Erlang is designed for massive concurrency. Erlang processes are lightweight (grow and shrink dynamically) with small memory footprint, fast to create and terminate, and the scheduling overhead is low.
32. Scheduler uses multiple cores out of the box
33. Actor Model
34. OTP • supervision trees • behaviors • applications • releases • release handling Erlang is designed for massive concurrency. Erlang processes are — lightweight (grow and shrink dynamically) — with small memory footprint, — fast to create and terminate, and — the scheduling overhead is low.
35. OTP Library of Design Patterns Behaviors Client Server Supervisors and Workers
36. Gen Server
37. Lifecycle of GenServer
38. Fault-tolerance
40. Quotes “Best kept secret in software” 
 - Evan Miller, author of Chicago Boss “Erlang is about building Systems”
 - Robert Virding “Erlang makes the easy things hard 
 and the hard things easy” separate?
41. Umbrella demo Phoenix and Elixir have Umbrella apps. Separate Applications in one repo.
42. Server A Server B HTTP Server Nginx and Phusion Passenger Erlang Request processing Ruby on Rails Erlang Long-running requests Go Erlang Server-wide state Redis Erlang Persistable data Redis / MongoDB Erlang Background jobs Cron, Bash scripts, and Ruby Erlang Service crash recovery Upstart Erlang
43. Review
44. Erlang review • massive concurrency • Processes • OTP • Virtual Machine (BEAM)
45. Elixir review • BEAM (Erlang VM) • modern syntax • macros • tooling • community • documentation
46. Phoenix review • pipelines • changesets • contexts • channels/topics • umbrella apps