When building something with docker deployed Prisma and graphql-yoga do you generally use subscriptions conservatively? Is performance a big part of that decision to make something available as a subscription or is it more about what would be nice to have on the front end?

in my opinion subscriptions are on the contrary something that can save your resources compared to back and forth communication

That is a good way of thinking about it.

unfortunately, subscriptions in Prisma are more like a infant in the crib, still dragging issues from Graphcool and even adding extra issues on top of that 😕

I am aware of this issue: https://github.com/graphcool/prisma/issues/1734. This is high on our list, and there is a workaround. What other problems do you see with subscriptions in Prisma, @Daniel K.?

well, nested subscriptions ? 🙂

What is a nested subscription?

sorry, I mean relation subscriptions ... I do remember this was a pain in graphcool with dummy fields updates and it's bit sad to see it's still present in Prisma

Thanks for the reminder 🙂 It's on my list to respond there.

I suppose that with those two working it might be a really good experience 🙂 perhaps some more documentation and examples on dealing with those more robustly (not just return ctx.db.subscription) ... it's bit confusing there with AsyncIterator 🙂

It's also worth noting that, depending on the query and the need for instant data, polling can be more efficient.

hm, I cannot see how can that be true ... unless your poll intervals are in minutes and more ... in that case it's not really a realtime experience 😉

Also, sorry for hijacking this thread, @Bro. I think a lot of factors go into the decision whether to use subscriptions or something else for a specific use case. I have found GraphQL subscriptions to be great for use cases like chat or notifications, but polling or using other forms of real-time also has its place.

I am working on a game that's very time sensitive so having reliable source of realtime data is essential

Then you'll want to do more research

yea, basically every other second something is happening, cannot imagine doing that over polling, especially on mobile platform where you don't have such a good connection

Absolutely. Your use case is pretty unique and polling would not work too well

btw do you have some good read on why polling is generally efficient? I cannot imagine that establishing full request every time is less resource intensive then waiting for an event

or video ... thanks 🙂

I don't have it on hand. There were a few articles on this last year. But there's overhead in maintaining a persistent connection. I'd also recommend looking at Elixir if you need concurrency with all of the sockets

I do have other web projects that will be realtime as well, but not that much, so I am thinking if polling might be a better option there ... maintaining a persistent WS connection is mainly about sending small heartbeat messages, hard to imagine it would be that big overhead instead of responding to a full request (parsing query, authentication, etc..)

You'll find out quickly what an idle WS connection cost if you have a lot of users, particularly with Node. When a client is in a game, you can reasonably assume that most connections will be active. But most websites will have 80% of their clients hanging.

I see, that's probably true, thanks for the insight

It comes down to users vs cost. That's why I recommend at least taking a peek at Elixir. It's built (well, Erlang is built) to handle this problem and it makes the connections negligible. Node with its GC can get very bogged down.

yea I heard about Elixir, but I don't particularly like Ruby like syntax 😕