Login

I’m trying to decide between using a RESTful design or switching to GraphQL for our new service API, but I’m stuck on how to handle real-time updates for a few specific client dashboards. The subscription model in GraphQL seems elegant, but I’m unsure if it’s worth the added complexity over just setting up a WebSocket layer alongside our current REST endpoints.

We tried layering a WebSocket feed on top of our REST endpoints for a couple dashboards and it was messier than we expected. You end up juggling connection liveness, auth token refreshes, scaling across regions, and keeping the REST cache in sync with live messages. Latency felt okay for a handful of users, but once the surface area grows it becomes a maintenance headache.

GraphQL subscriptions look neat on diagrams, but in practice the tooling isn't as mature as the rest of the stack. We ran into schema drift, tricky testing of live updates, and the burden of wiring authorization, backpressure, and reconnections. It felt like more moving parts than the dashboards actually needed.

We started with REST for everything and added a targeted gateway for a few dashboards that need real-time. Kept the payloads small, used a pub/sub broker under the hood, and just pushed updates to subscribed clients. It worked okay, but keeping two models in sync was a bit of a chore.

I'd consider a hybrid approach: keep REST for CRUD, add a lightweight pub/sub channel (not GraphQL) to push updates, and see if that covers the dashboards. If you actually want declarative queries across updates, GraphQL might be overkill at first.

I keep wondering if the real problem is just data freshness. If the dashboards tolerate a few seconds of lag, a simple polling or a heartbeat stream may be enough and save all the flavor of subscriptions.

Question: roughly how many concurrent connections do you expect on the live dashboards?

Login
Username:
Password:	Lost Password?
	Remember me