Thoughts on Horizon?
abastardi opened this issue · comments
RethinkDB recently released Horizon. Their roadmap (at the end of this blog post) includes GraphQL support, optimistic updates, query composition, and custom commands. There's also a Horizon react-redux boilerplate and a horizon-redux-sync package.
I know it's early stage, but anything worth using or learning from in there?
i like the rethinkdb team, they put out awesome stuff. it's too early to comment on horizon, though. i'll wait until they release graphQL support & decouple it from the database. full disclosure, i have a vested interest in https://baasil.io/, which is also a pubsub-as-as-service. feeding an app with realtime data is difficult, doing it in a way that doesn't lock you in even moreso. there's also deepstream, meteor/apollo, firebase, etc. none of us have it figured out yet, but sticking graphql in the data transport layer is a good start.
Thanks for the response. Any details on the Baasil.io data sync functionality? Will it work with any database, and/or will it take advantage of databases with built-in realtime functionality such as RethinkDB? Will it be open sourced like SocketCluster? What will distinguish it from Deepstream/DeepstreamHub?
as a pubsub, you pay per message & then you don't have to manage any hardware. under the covers, it's socketcluster, but you don't have to worry about the hosting & scaling. the goal is to work with every db, but it depends on how you use it, ie if you expose mutations through REST endpoints, you'll probably want to feed that through the pubsub so others can see it, otherwise you are basically sneaking changes into the db. deepstream hub is really cool tech too with how they're trying to integrate with a bunch of 3rd party vendors, i don't know enough about it to give a fair comparison, though.
@jondubois can answer better than i can.
@abastardi @mattkrick Yes Horizon looks awesome. It's pretty much exactly the direction were were heading in with Baasil.io initially but they came out faster. They have an excellent team.
It's prompted me to rethink the strategy for Baasil.io a bit. Horizon looks like a huge step forward in terms of striking the right balance between flexibillity and convenience. It's starting to look like a platform which even enterprises could use (which is still not really the case with Firebase). I want to take things one step further with Baasil.io.
Since Horizon came out, we (Baasil.io) shifted our focus more towards containerized deployment with tooling like Docker and Kubernetes.
The plan now is to focus on open source stacks/frameworks which we specialize in (SocketCluster, Meatier, React) and provide tooling to allow developers to deploy custom apps/services built on top of these stacks to Baasil.io using a single command. The idea is that those apps/services will be instantly scalable. (Apps will be containerized automatically so developers won't have to know anything about Docker unless they want to).
Also because we will specialize in apps built on top of our own frameworks, we will be able to offer the best possible support if anything goes wrong.
So basically, Baasil.io will be a container hosting and deployment platform with a focus on specific realtime stacks - Our key strength will be technical support for those stacks.
The plan is to offer full flexibility - You will be able to manage your entire infrastructure and even SSH into individual machines - We will provide boilerplates, but ultimately, you will be able to deploy any container to our platform. The single-command deploy will will be the main convenience feature. It will be one command to pull the boilerplate to your local machine, add your custom code on top of it and then one command to deploy.
The goal is to become not just a container hosting provider but also a community of developers who build apps on top of similar technologies (so we can also help each other out). And yes we will try to open source as much as possible - We will use support/community as the lock-in factor instead of trying to lock-in through proprietary APIs.
Also yes, we will trying to keep our stacks database-agnostic where possible.
@jondubois Sounds great. Thanks for sharing this. Looking forward to seeing how it develops.