As I said in Socket science isn’t rocket science, WebSockets are quite easy to use with Python + Flask + Socket.IO on the backend and Angular + Socket.IO + RxJS on the frontend. But why bother? Dealing with asynchronous requests is more of a hassle than not. And for a “boring” app like poketto.me, aren’t synchronous HTTP requests/responses good enough?
Here are two use cases where, despite the app’s apparent simplicity, asynchronous backend/frontend communication adds real value:
➡️ Notifications: Many operations poketto.me performs actually run in the background—smoothing content, translating it, optimizing it for listening, etc. I can’t have an HTTP request stall for several minutes while these things happen (and show an endless progress spinner to the user.) And regular polling for status updates isn’t ideal either. With WebSockets, I can simply notify the client when tasks are complete. Notice, for example, how the status indicator in the top right corner of a Save changes and disappears over time, all on its own.
➡️ Consistent state across browser tabs: Most users won’t have multiple poketto.me tabs open—but some will. And many will have the app open in one tab while using the Chrome Extension in another to save a web page. When they return to the app, they expect the saved page to already be there. Same on mobile.
Of course, these features aren’t directly “monetizable.” No one pays just for seamless tab syncing. But users’ expectations of good UX keep evolving—and how the app feels plays a huge role in whether people keep using it, or even upgrade to a paid version.