(deepstreamer here) Thanks for the article, really appreciate it as it confirms some of our own thinking: It has to be set, despite its flaws, Firebase has some great ideas, e.g. its permission language that strongly inspired us when building https://deepstreamhub.com/. But there are some aspects that send us down a different route:
- Serverless is a great goal, but only works for low complexity apps. We’ve designed deepstream explicitly not to take the server away, but as a layer that sits in between backend and frontend and allows servers and clients to connect and exchange data.
- The same is true for auth. DeepstreamHub comes with similar built in auth and usermanagement functions as Firebase, but more importantly comes with a Webhook auth strategy that forwards any login data and associated connection info (IP, Cookies etc) to a HTTPS endpoint of the users choosing. Depending on the returned status code the connection is either granted or denied. In addition the auth server can also return client specific metadata that’s either forwarded to the client upon login or used within permission rules to determine access rights
- Querying. This has so far not been a strongpoint of deepstream either, but we’ll soon be releasing a blazingly fast realtime graphql implementation to address this. More details here: https://deepstreamhub.com/blog/deepstream-3.0-release/