Hi Team,
I was about to make an embedded chat app, but I am confused because of the following reasons:
Since Slash GraphQL uses HTTP and Firestore uses Sockets, in terms of speed, Firestore will be faster.
However I absolutely loathe the way I have to plan for the document structure, also adhere to document size restrictions and all other tradeoffs with document store that needs to be made to use Firestore.
So, how should I proceed? Do I:
- Use Optimistic UI & Subscriptions? (So user won’t feel the lag, but it won’t be “realtime”)
- Use Ludicrous mode? (Don’t want to loose messages though!)
- Settle for Firestore? (Chat data should be separate from app data and hence this choice is logical?)
Hey Abhijit,
Subscription is live in Slash GraphQL and it uses WebSockets. You can refer to the sample chat app created using React Apollo Client and Slash GraphQL here.
This sample app is part of a blog post we will be releasing this week. The blog will containg explaination for the why’s and how’s. I will add the link here once it is public.
EDIT: The blog has been released here.
2 Likes
Hi @akashjain971,
Firestore is a 2 way socket connection, i.e. messages are sent & received via sockets, which makes it instantaneous.
I assumed Subscription is a one way construct, i.e. Front end is notified when change occurs in server, if so chat app made using Slash GraphQL will be slower as upstream will still rely upon HTTP.
Is my assumption correct?
1 Like
Slash GraphQL subscription is queries only, and hence only flow from server to client only.
Updates happen over an immediate HTTP connection, so this would be realtime as well. While it’s a new HTTP request, we should support HTTP/2 with connection multiplexing, so there shouldn’t be a major difference in performance for updates.
The support for HTTP/2 is in progress and should rollout this week.
However, Dgraph internally implements subscriptions by polling for changes, so you might see a delay of upto 1s by default.
1 Like