This looks pretty cool
Oh it’s built by the RethinkDB team! It does look pretty cool
Yeah, it basically provides an alternative to DDP/minimongo. While quite a few are comparing it to Meteor, I can see it might be interesting incorporating it into your Meteor stack if you want RethinkDB support.
Thanks, they have plan to support GraphQL support, then kind of like Apollo.
I like it. It could be quite serious competitor for Meteor. It seems that they has all what Meteor has and they are elastic, you can just use webpack and react. RethinkDB is also very good. They will have something like Galaxy and probably GraphQL integration too. Nice!
The video is quite informative. There is also something about Meteor:
Roadmap is awesome:
- A built-in admin dashboard with an interactive data browser
- Better connection lifecycle management and disconnect recovery
- Support for building your own Horizon commands with ReQL and JavaScript
- Support for handling file uploads from the client
- Conventional password authentication in addition to OAuth providers
- A built-in pagination API that works with realtime queries
- Native support for performing optimistic updates
- Support for relations via query aggregation
- Built-in support for fetching data with GraphQL
[source: http://horizon.io/blog/horizon-launch/]
edit: another cool vid:
Since Apollo doesn’t use live queries, this could be a great next-generation option for people who need real time data streaming. And you could even use them together, Apollo + GraphQL to get data from your SQL/Mongo/API backends, and Horizon for realtime data from RethinkDB.
Will we loose Meteor’s reactivity features with Apollo? I’ve just thought that with GraphQL we are able to use every database we want, so Meteor + Apollo/GraphQL + RethinkDB isn’t possible out of the box?
Yes, that’s correct!
“Reactivity” is quite a loaded word, and one I’ve been trying to avoid and deconstruct when it comes up. There are a few levels here:
- Seeing your own writes (definitely yes)
- The ability to eventually see new data, via a polling mechanism (definitely yes)
- The ability to quickly see writes made from within the system (eventually yes)
- The ability to immediately see writes made to the database from outside the system (probably only for systems that provide change notifications, like Mongo+Livequery, RethinkDB, custom streaming data services)
The point is that “every database” means it’s not possible to rely on the database providing a steaming API, since most databases don’t have that. And that’s the case we’re focusing with Apollo rather than the realtime data streaming case.
Yeah, I understand, I’m just hoping that we don’t loose features of Meteor that it already has today (as you said Mongo + Livequery/Oplog).
At the moment I’m trying to understand GraphQL and the reason why it is so pushed. Maybe you can tell me if I understand the whole thing right:
For example, today we have the Account package for Meteor. If we use Apollo/GraphQL, the whole Account package needs to be rewritten to GraphQL. After it’s done, we are able to use it which different database systems like MySQL/Mongo or for example RethinkDB, because the queries are written in GraphQL and GraphQL is responsible to “translate” this queries for the specific database systems.
Is that correct?
That’s exactly right. If you haven’t yet, check out my talk from Meteor Night a few months ago:
To understand more why we are so excited about GraphQL, you can read some of our blog posts:
- How NewSpring church uses GraphQL and Apollo to build apps on top of many data sources: https://medium.com/apollo-stack/the-business-case-for-graphql-cc7a2b93148d#.kfdef9thd
- How GraphQL enables next-generation developer tools that simply aren’t possible with REST or DDP: https://medium.com/apollo-stack/power-tools-for-your-api-42529706ae78
- How GraphQL is the first really usable self-documenting API system: https://medium.com/apollo-stack/will-graphql-replace-rest-documentation-f1a55092ef9d#.ecto2g8j0
In short, it’s the perfect API language for today’s world, where apps are collecting data from many backends and APIs and your frontend requirements are changing all the time. Better yet, I think it will actually make developing an app much faster, since the single abstraction of a GraphQL schema means that once you have defined a schema you can write all parts of your app in parallel.
One of these days you will have to do a post on this to clear this matter.
RethinkDB’s Horizon is a brilliant move–maybe I sort of predicted this
This along with Parse Server w/ Live Query, push notifications, etc. and a push-to-deploy button for AWS Elastic Beanstock, Heroku, etc. pretty much as easy as “meteor deploy”. The biggest advantage was Optimistic UI and Redux fills in this void even better and it works with other front-end frameworks like RiotJS (which is brilliant for browser apps which will not become native).
I recently play around with jspm w/ hot code reloads and its pretty easy to use. Way faster updates than Meteor’s build tool.
I really respect MDG. One of the most important “features” of Meteor is its dedication to the community, featuring apps, etc. (Sad to see some shift away from this, MeteorPad going away, no free hosting, etc. this community support is specifically the area they were a leader in).
Anyway, its a very exciting time in development right now and I foresee much more. Even in terms of tools, there are still many missing gaps that we will see made easy.