Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Building real time applications with Symfony2

Building real time applications with Symfony2

Real time applications are here and users expecting that Real time data is part of UX. What are your options for building RTA with Symfony2/PHP? Slides from Symfony Camp Ukraine.

Antonio Peric-Mazar

October 29, 2015
Tweet

More Decks by Antonio Peric-Mazar

Other Decks in Programming

Transcript

  1. @antonioperic About me • Antonio Perić-Mažar, 
 mag. ing. comp.

    • CEO @ Locastic • Software developer, Symfony2 • Sylius Contributor :)
 • www.locastic.com • [email protected] • twitter: @antonioperic
  2. @antonioperic Who we are? • Locastic (www.locastic.com) • Web and

    mobile development • UI/UX design • Located in Split, Croatia
  3. @antonioperic What is RTA? A real-time application (RTA) is an

    application program that functions within a time frame that the user senses as immediate or current. The latency must be less than a defined value, usually measured in seconds. Whether or not a given application qualifies as an RTA depends on the worst-case execution time (WCET), the maximum length of time a defined task or set of tasks requires on a given hardware platform. The use of RTAs is called real-time computing (RTC).
  4. @antonioperic Use Cases • Videoconference applications, VoIP • Data Visualisations,

    Location tracking • Online gaming, multi-user collaboration • Community storage solutions • Some e-commerce transactions • Chatting, IM (instant messaging) • Notifications & Signalling • Activity Streams • …
  5. @antonioperic HTTP • A client requests a webpage from a

    server. • The server calculates the response • The server sends the response to the client.
  6. @antonioperic Webhooks •server only •low update rates •uni-directional - from

    publisher to consumer (server to server) •avg. latency •high. efficiency (for servers)
  7. @antonioperic Polling • A client requests a webpage from a

    server using regular HTTP (see HTTP above). • The requested webpage executes JavaScript which requests a file from the server at regular intervals (e.g. 0.5 seconds). • The server calculates each response and sends it back, just like normal HTTP traffic.
  8. @antonioperic Polling • server or client • low update rates

    • batched bi-directional • high latency • low efficiency
  9. @antonioperic Long Polling • A client requests a webpage from

    a server using regular HTTP (see HTTP above). • The requested webpage executes JavaScript which requests a file from the server. • The server does not immediately respond with the requested information but waits until there's new information available. • When there's new information available, the server responds with the new information. • The client receives the new information and immediately sends another request to the server, re-starting the process.
  10. @antonioperic Long Polling • server or client • avg. update

    rates • batched bi-directional • avg. latency • avg. efficiency
  11. @antonioperic HTML5 Server Sent Events (SSE) / EventSource • A

    client requests a webpage from a server using regular HTTP • The requested webpage executes javascript which opens a connection to the server. • The server sends an event to the client when there's new information available. • Real-time traffic from server to client, mostly that's what you'll need • You'll want to use a server that has an event loop • Not possible to connect with a server from another domain
  12. @antonioperic HTML5 Server Sent Events (SSE) / EventSource • client

    (pushing) • good update rates • unidirectional • good latency • good efficiency
  13. @antonioperic WebSockets • A client requests a webpage from a

    server using regular http (see HTTP above). • The requested webpage executes JavaScript which opens a connection with the server. • The server and the client can now send each other messages when new data (on either side) is available. • Real-time traffic from the server to the client and from the client to the server • You'll want to use a server that has an event • With WebSockets it is possible to connect with a server from another domain. • It is also possible to use a third party hosted websocket server, for example Pusher or others. This way you'll only have to implement the client side, which is very easy!
  14. @antonioperic WebSockets • TCP, fully duplex single connection • server

    or client (client mostly) • bi-directional • high update rates • low latency • high efficiency
  15. @antonioperic Streaming • make connection, keep it open, as soon

    as we have updates push it to client • server or client • high updated rates • uni-directional • low latency • high efficiency • business decisions, trading, unidirectional you can only push it from server to client, single persisting connection • look as servers and event as standard
  16. @antonioperic WebRTC • server or client (normally client2client) • high

    update rates • bi-directional • low latency • high efficiency • audio or video generally peer2peer
  17. @antonioperic Simple Messaging • No abstraction. Just messages • Fits

    well with HTTP and REST • Many persist connections
  18. @antonioperic Pub/Sub • Subscribe and publish on channels • Multiplexed.

    Single connection. • Clearity partitions complex data • Dedicated Endpoint • Required SDK
  19. @antonioperic Data Sync • Interact with, and synchronise, data structures

    • Dedicated endpoint + Protocol • New Paradigm • SDK Required • Hides network activity from developer
  20. @antonioperic How to pick technology? • First: Are the only

    real time solutions in NodeJS?
 
 
 NO!
  21. @antonioperic Solutions by language • PHP: ReactPHP, Ratchet, dNode-php, phpDaemon

    • Java: Netty, Jetty • JavaScript (Node.JS): Faye, Socket.IO (Engine.IO), Primus.io • .NET (C#): SignalR, XSockets • Python: Lots of options built on Tornado • Ruby: em-websocket, Faye • Language agnostic: most hosted services
  22. @antonioperic PHP? • Apache is not built for Real-Time •

    PHP is not build for Real-Time • Real-Time is not impossible with PHP
  23. @antonioperic PHP RTA • Self hosted PHP solution • Self

    hosted Side-by-Side solution • Hosted solution
  24. @antonioperic PHP Self Hosted solutions • React (PHP) • Event-driven,

    non-blocking I/O with PHP. • Ratchet (Built on React PHP) • WebSockets, WAMP, PubSub samples. No HTTP Fallback • dnode-php (RPC/RMI) • phpDaemon • Lots of examples. Most docs in Russian.
  25. @antonioperic PHP Self Hosted solutions Pros: • PHP • Simple

    integration • Standards-based • WAMP/Autobahn • JS, Android, iOS & more Cons: • No HTTP fallback • Low-level abstractions • Different programming style • You need to scale
  26. @antonioperic PHP + Faye Self Hosted solutions Pros: • PubSub

    • Connection fallback • Redis support is build in • Simple integration Cons: • Not PHP? • You need to scale
  27. @antonioperic Other side by side solutions • Socket.IO • SockJS

    • SignalR • see real time tech guide for more
  28. @antonioperic PHP + Hosted solutions Pros: • Simple and powerful

    • Instantly scalable • Managed & Dedicated • Direct integration into Symfony Cons: • 3rd party reliance
  29. @antonioperic What we build? • Real time dashboards ford Google

    Adwords analytics • Symfony2, AngularJS, RabbitMQ • First version was with Polling • Second version moving to hosted solution - Pusher
  30. @antonioperic Other hosted solutions • PubNub • Realtime.co • Firebase

    • Simperium • see real time tech guide for more
  31. @antonioperic References • Phil @Leggetter 
 - Head of Developer

    Relations at @pusher. Realtime Web Technology Evangelist. 
 • Real-time Tech Guide • React (PHP) • Ratchet (PHP) • Faye (Node/Ruby) • Pusher • LopiPusherBundle • github.com/leggetter/realtime-symfonyexamples