Real-time Services with Silex and Symfony – deSymfony 2016

En los micro-servicios modernos, los cuales se basan en eventos, comunicación bidireccional, stream multiplexing y otras formas de sincronización de los datos, la arquitectura clásica basada en HTTP/REST no siempre es la mejor opción.

Algunas veces las aplicaciones requieren servicios donde es necesario mantener una comunicación asíncrona de eventos fluyendo en ambas direcciones, por ejemplo, un cliente conectado por Websocket.

¿Qué hacer en estos casos si tenemos la gran mayoría de nuestros servicios implementados con Symfony o Silex y queremos tener comunicación en real time con un cliente? ¿Qué opciones tenemos, qué soluciones podemos aplicar y con qué trade-offs?

El objetivo de la charla es dar respuestas a estas preguntas, basándonos en casos de usos reales en producción, comparar las distintas alternativas existentes y ver ejemplos prácticos de integración Silex/Symfony.

Transcript

1. deSymfony 16-17 septiembre 2016 Madrid MICROSERVICIOS EN TIEMPO REAL CON SYMFONY Y SILEX Ronny López
2. deSymfony ¡Muchas gracias a nuestros patrocinadores!
3. About me @ronnylt Ronny López Technical Lead Opinions are my own
4. Agenda • Concepts and foundations • Real-time communication patterns • Implementations • Examples
5. Real-time A system is said to be real-time if the total correctness of an operation depends not only upon its logical correctness, but also upon the time in which it is performed
6. Real-time Applications must guarantee response within specified time constraints, often referred to as “deadlines”
7. Real-time Applications in which the computer must respond as rapidly as required by the user
8. Criteria for real-time • Hard – missing a deadline is a total system failure
 • Firm – infrequent deadline misses are tolerable, but may degrade the system's QoS. Results are NOT usefulness after its deadline
 • Soft – the usefulness of a result degrades after its deadline, thereby degrading the system’s QoS
9. Real-time Soft real-time
10. Soft real-time Typically used to solve issues of concurrent access and the need to keep a number of connected systems up-to-date through changing situations
11. Soft real-time use cases • Live audio-video systems • Users collaboration • Messaging applications, etc… • Real-time analytics • Gaming • Etc…
12. The road to 500 million Symfony downloads https://symfony.com/500million
13. Why adding a soft
 real-time feature? • To improve end-user experience • Due to insufficient scaling capacity
14. Real-time Communication on the Web
15. A Bit of History • Flash • Ajax (XMLHttpRequest) • Comet (reverse Ajax) • WebSocket • Polyfills
16. The Modern Web • WebSockets • HTTP/2
17. WebSockets • Full-duplex communication channels over a single TCP connection • Currently supported in most major browsers • Can be used by any client or server application
18. HTTP/2 • Major revision of the HTTP • Replacement for how HTTP is expressed “on the wire” • Focus on performance, end-user perceived latency, network and server resource usage
19. The Mobile Internet • Inestable connections • HTTP & TCP slow-start are usually not a good match for constantly dropped connections • Network interface kills battery • Large responses + periodic polling = bad
20. What Every Web Developer Should Know About Networking and Browser Performance
21. Real-time Communication Patterns
22. The “actors” Client Server Peer Peer
23. Basic Patterns • Remote Procedure Call (RPC) • PUB/SUB
24. RPC • Allows to call a procedure (function) remotely • Involves peers of these three roles Caller Callee Dealer
25. RPC – Example 1 Something you usually do with Ajax Browser Server GetConference(123) {name:deSymfony,where: Madrid}
26. RPC – Example 2 Push data to the browser Browser Server DisplayOffer(offer)
27. RPC – Example 3 Communication between micro-services Auth Server login(user) Analytics Payments track(user) process(order)
28. Publisher/Subscriber • A peer subscribe to a topic • Another peer publish a message about this topic • All publishers interested in the topic receives the message
29. PUB/SUB – Example 1 Notifications Browser Server updateStats(stats) Browser Browser Subscribed To: StatsUpdate
30. PUB/SUB – Example 2 Micro-services Synchronization Auth Admin Service updateSettings(freshSettings) Encoding Payments Subscribed To: SettingsChanges Analytics
31. Web Application Messaging Protocol
 http://wamp-proto.org/
32. Not to be confused with WAMP: ”Windows + Apache + MySQL + PHP"
33. WAMP • Open standard WebSocket subprotocol • Provides two application messaging patterns in one unified protocol • Remote Procedure Calls • Publish & Subscribe
34. WAMP Features • Enables different technologies, processes, machines, etc… to communicate with each other, in soft real-time
35. WAMP Features • Based on modern Web standards: WebSocket, JSON and URIs • Designed with first-class support for different languages in mind (Polyglot)
36. Unified Application Routing Routing of events (for PUB/SUB) and routing of calls (for RPC) in one unified protocol Caller Callee Dealer Publisher Subscriber Broker
37. Dealer • Routes calls from the caller to the callee and routes back results or errors • Callers and callee don’t know about each other • Applications using RPC benefit from these loose coupling Caller Callee Dealer
38. Broker • Keeps a book of subscriptions • Forward the events (messages) to all subscribers • Publisher are subscribers are loosely coupled Publisher Subscriber Broker
39. Unified Protocol • When you combine a Broker and a Dealer you get what WAMP calls a Router Router Broker Dealer = +
40. The Big Picture WAMP Router (Dealer + Broker) Browser Browser Browser Browser Mobile Clients Services
41. Do we really need another wheel? How does WAMMP compare to other technologies
42. Criteria • Pub/Sub • RPC • Routed RPC (not only point-to-point) • Web native: run natively on the Web (without tunneling or bridging) • Cross Language • Open Standard
43. Tech PubSub RPC Routed RPC Web native Cross Language Open Standard WAMP ✔ ✔ ✔ ✔ ✔ ✔ Ajax ✔ ✔ ✔ Comet ✔ ✔ JSON-RPC ✔ ✔ ✔ ✔ socket.io ✔ ✔ ZMQ ✔ ✔ XMPP ✔ ✔ ✔ ✔
44. Implementations • Client libraries for most popular languages • Full featured router implementations in several languages
45. WAMP Routers • crossbar.io – Advanced, open-source, full featured, supported by the creators of WAMP
 • Your own… It’s an open protocol
46. WAMP Ecosystem • Thruway – library built in PHP that provides both a client and a router • Turnpike – router implemented in Go
 • wamp.rt – router for NodeJS
 • Erwa – router implemented in Erlang

47. Choosing an implementation Let’s talk about trade-offs
48. Is PHP suitable for soft real-time applications?
49. Is PHP the right tool for the job?
50. No.
51. No?
52. Why not?
53. Let’s use Node.js ! It’s an opportunity to deploy Erlang or Golang, or …
54. Languages War
55. Conflicts Everywhere
56. Conflicts everywhere Trade-offs everywhere
57. Trade-off • Situation that involves losing one quality or aspect of something in return for gaining another quality or aspect
 • It often implies a decision to be made with full comprehension of both the upside and downside of a particular choice
58. Is PHP the right tool for the job? There is not simple answer
59. The simpler answer I know is: “I don’t care”
60. PHP Codebase
 (Symfony, Silex, Laravel, Drupal, etc…) Clients Web, Mobile, etc… Request/Response
61. Request/Response Real-time API
 Pub/Sub, RPC, etc.. RPC
62. • A big ecosystem of thousands of useful libraries and components easily installable thanks to Composer • Very powerful template engines, ORMs, etc…
63. • We have implemented very powerful design patters in PHP coming from Java and other languages • We have several thousands of high quality code running on production • We have invested multiple hours testing, refactoring and improving the codebase
64. It’s here to stay
66. Remember Full comprehension of both the upsides and downsides of a particular choice
67. Downsides • We have to introduce a new stack to provide real-time features
68. Upsides • Possibility to introduce real-time features without deep modifications in the current codebase • No need to learn a whole new language/ stack, with the implications it has • Loosely coupled systems
69. Upsides cont… • Opens the door to write reactive, event- based, distributed architectures • Scalability is easier to achieve by distributing messages to multiple systems
70. Examples
71. The Stack • crossbar.io used as the router (dealer+broker) • PHP client gathers and publish events • Silex/Symfony backend serve the data and contains the biz logic
72. crossbar.io • Networking platform for distributed and micro-services applications • Full implementation of the WAMP protocol • Feature rich, scalable, robust and secure • It takes care of the hard parts of messaging so you can focus on your app's features
74. Tips and Tricks • WSS • Deadlines • Timeouts • Retries with back-off, etc… • Idempotency
75. Opinionated Conclusion • Understand core concepts and patterns, technology is volatile • Question everything: Why?, why not? • Decide based on several factors: user experience, scalability, feasibility, developer experience, maintenance costs/debt, etc…
76. Don’t Stop Here • gRPC – A high performance, open-source universal RPC framework from Google
 
 http://www.grpc.io/
 • IoT, WoT, etc… – real world objects connected to the wider internet
77. References • WAMP Proto – http://wamp-proto.org/ • https://github.com/voryx/ThruwayBundle • https://www.infoq.com/articles/websocket- and-http2-coexist
78. Questions • What about React PHP? • Multi-Threading in PHP with pthreads?
 https://gist.github.com/krakjoe/6437782/ • Micro-services what?
79. Gracias! @ronnylt Work with us!