Kyaw Zay Moore QR Login Using WebSockets VS Server-Sent Events (SSE) https://kyawzaymoore.com

QR Login • Mobile app login • Web app display QR code to scan • Mobile scan Web’s QR and Web app automatically login.

QR Login Flow

QR Login can use following methods: • WebSockets • Server-Sent Events (SSE) • Callback or postback

Web Sockets

Web Sockets Advantage • Real-time communication: WebSockets allow for instant, two-way communication. Once the client scans the QR code, the server can immediately notify the client of the authentication result. • Low latency: Since the connection is always open, responses are instantaneous. • E ffi cient: After the initial handshake, WebSockets use less overhead compared to HTTP polling. Disadvantage • Complexity: Requires more setup and resources to manage open connections. • Not ideal for simple use cases: For scenarios where continuous bi-directional communication isn’t needed, WebSockets may be overkill.

Server-Sent Events (SSE)

Server-Sent Events (SSE) Advantage • Easier setup: SSE is easier to implement than WebSockets since it's built on top of HTTP. • E ffi cient for server-to-client updates: Only the server sends data, so it uses fewer resources compared to WebSockets for unidirectional updates. • Automatic reconnection: SSE has built-in support for reconnection if the connection is interrupted. Disadvantage • Unidirectional: The client can’t send messages to the server once the connection is established (the initial connection is an HTTP request). • Not suitable for older browsers: SSE might not be supported on very old browsers (but modern browsers support it).

Server-Sent Events (SSE) Best For: • Scenarios where you don’t need two-way communication. For example, once the QR code is scanned on the client side, the server can push an authentication result. Example : Live Score app, streaming app, etc

Why should we handle QR code expiry time • We should set an expiration for QR login to stop WebSocket or SSE connections from staying open too long, which improves security and saves resources.

Why don’t we use callback or postback While callbacks could work in theory, they are less suited for real-time login processes like QR code login. You’d have to manage the complexities of waiting for the server to complete its task and calling back to the client after authentication, which introduces latency and complexity. • Not real-time: Callbacks are asynchronous and event-driven, meaning they don't provide real-time updates like WebSockets or SSE. • Extra complexity: The client must expose an endpoint and the server has to make a separate HTTP request to that endpoint, which adds unnecessary steps.

Q/A

Thank You