Real-time Services with Silex and Symfony – deSymfony 2016

38f85d28d9dd5c53323a6d92b63b16e0?s=47 Ronny López
September 16, 2016

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.


Ronny López

September 16, 2016


  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

  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

  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

  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

  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 ✔ ✔ ✔ ✔ ✔ ✔ ZMQ ✔ ✔ XMPP ✔ ✔ ✔ ✔
  44. Implementations • Client libraries for most popular languages • Full

    featured router implementations in several languages
  45. WAMP Routers • – 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

  65. None
  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 • used as the router (dealer+broker) •

    PHP client gathers and publish events • Silex/Symfony backend serve the data and contains the biz logic
  72. • 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
  73. None
  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
 • IoT, WoT, etc… – real world objects connected to the wider internet
  77. References • WAMP Proto – • •

  78. Questions • What about React PHP? • Multi-Threading in PHP

    with pthreads? • Micro-services what?
  79. Gracias! @ronnylt Work with us!