Reactive GraphQL
info.meteor.com
info.meteor.com
The ease of getting up and running, the ease of tools, and the ease of deployment. On no React stack can you (and in the future this will be more simple) run
meteor create my-react-project
npm init && npm install react
Then hypothetically after some time of development, do
meteor add-platform ios
meteor add-platform android
meteor add-platform desktop (this is theoretical currently, but there exist packages which do exactly this)
meteor deploy
This announcement touches on one of their most thorny issues of being tightly coupled to Mongo. Adding this abstraction layer allowing any UI and any data source is Meteor's ticket to the masses.
That said, on the build side of things Webpack and Babel have been giving Meteor a run for its money. It takes more work to build your app with those tools, but it's a lot less work than it used to be using plain NPM, and you now have a lot more customization than in Meteor.
That's why doubling down and continuing the thought of full stack reactivity is so important to Meteor. I'm so glad to hear that they have suited up to upgrade their reactive server-side parts. I hope they put a lot of resources behind it.
If interested, here's my take my take on what "Reactive GraphQL" means to Meteor developers:
https://medium.com/@faceyspacey/what-reactive-graphql-means-...
npm install [-g] jspm
jspm init
jspm install react
I've nothing to add in regards to ios / android / desktop, but for getting up-and-running, jspm seems to do the job quite well.
(I have nothing to do with jspm, I've just been using it recently)
This announcement is exciting on many levels and I think some of the unspoken bits will be interesting later too. I hear they are working directly with people at Facebook on this project.
git clone git@a-react-template.github.com my-react-project
cd my-react-project
npm installIt's better to understand it as the cathedral to npm's bazaar. Everything down to the third-party packages is cohesive and never needs any wiring up or glue-code.
That's where the productivity gains come from.
It has a JavaScript framework (Blaze), but also works with Angular or React.
It's tied to Mongo, but this release announcement is about loosening that bond.
This is great because the promise of a stack like this is very exciting, but I am left wondering what is meteor promising to bring that isn't just bundling some modules, and re-implementing Relay?
I can't see anything in the list of what we are planning to build that isn't already offered by Relay, or on Relay's roadmap.
Not that a different implementation isn't a great thing, competition is always advantageous, but my understanding is that Meteor is a for-profit company whose product is their framework - it seems quite odd therefore that their plan for that framework appears to be to just piece together and/or re-implement an already-existing, well-used and well-known stack of completely open-source libraries, that aren't at all difficult to piece together as it is. What's their strategy here?
It frankly seems they at least believe it has, as it appears their plan is to take it, bundle it together under one name and re-implement some parts.
The question is then, why would anyone on the React stack, which has become so popular, switch to Meteor? The stack of libraries Facebook has already put out there (not to mention third party libraries such as Redux) are designed to work together, and do so easily and very well - people are familiar with them and already using them.
I suppose the only dimension on which they could coax people over from the existing React stack, Relay in particular, is by developing its feature set faster and better than Facebook can. For what it's worth I think it's a good thing, I just find it pretty intriguing if that's their play - going up against the popular tide and basically directly competing with Facebook on bundling together their own libraries. Will be great to watch their progress!
The "React" stack has certainly been an up and coming potential competitor for Meteor, but until Facebook or someone else actually shows signs of preparing the kind of integrated development experience that Meteor ships with out of the box, I don't think it's really similar. So that's what they're doing: tying together the best of the Javascript ecosystem, which happens to currently include a couple of projects by Facebook, into one cohesive whole that "just works".
I'm sold on the latter, since often enough I'll customize and publish my own tweaked templates as I become enamoured with different tech.
In addition, what Meteor is about to build here is a long time coming. It's something they have been thinking about in one form or another for years. What I'm referring too is a purely webserver-based interface for subscriptions that doesn't take advantage of any special database features, and is therefore database-agnostic. GraphQL happens to come at the perfect time as the solution to supporting multiple databases. And as the only open source full stack reactive solution worth its salt, they know the challenges of building this solution better than anyone.
Their current solution, Oplog Tailing for Mongo, has been on the chopping block for a while since it doesn't scale far enough. They've experimented with PostgreSQL triggers. And now they're drawing from all this experience to harness GraphQL types to build the best-in-class interface for anyone to take on full stack reactivity. My guess is it will likely not be as performant as direct Mongo oplog tailing, but will allow developers to customize it to make it faster where you need it, which is something we've never been able to do. In addition, if the low level interface is good enough, it will likely result in many packages that provide for specific optimized reactive/subscription scenarios.
So no, the "React stack" has not "already won" on this front. Subscriptions is a big problem with many different solutions. Likely what Facebook has can't be used by anyone but the largest of companies. If Meteor both provides a decent database-agnostic subscriptions interface + an API to customize it for performance, Meteor will likely have done what nobody else has or is willing to do.
Without having an open specification Meteors implementation might end up completly different or incompatible to other (Reactive) GraphQL implementations.
Despite that, I think that implementing a reactive GraphQL backend will be very hard, and it would only work good if all of the sub-data-sources that you use in your backend support reactivity (subscriptions) as well. If they do, then you have to subscribe to all possible data sources that are mentioned in the query, and update the current state when one of these changes. If the update requires you to fetch an additional data source (e.g. you must fetch other indexes of data which are provided by another source), you must even dynamically subscribe/unsubscribe on updates of other sources.
And how can you provide traditional REST APIs (or even query-based GraphQL endpoints) as reactive endpoints? The best you can do is probably implement polling (rerunning) the query on the backend over and over.
RethinkDB for example has changefeeds built in and is tackling this problem as well. See: https://github.com/rethinkdb/rethinkdb/issues/3711
Data as a stream is pretty interesting too: https://www.youtube.com/watch?v=fU9hR3kiOK0
I am sure they could now update their query language to GraphQL instead of MongoDB queries by adapting and extending the existing system, but I don't know if thats currently the biggest problem for meteor adoption or only something that is nice to have for some GraphQl/Relay fans (which still might be using these directly anyway).