It was simpler when it was Mongo/Meteor/Blaze, and it would be nice to get some vertically integrated pipeline like that again. On the other hand, things change rapidly (especially on the front end) and it’s hard to know which stack will have the staying power (this is even more true for CSS frameworks). I prefer React these days, so I’ll deal with the increase decision complexity, and there are great tools like uniforms in that ecosystem, which show how a single package can support multiple CSS frameworks and data structure packages. But it could be nice to get some kind of similar SQL/Apollo/{Vue.js or React} stack working.
The question over pub/sub or methods (or client side mini-mongo updates) were still tricky back then. I set these rules, 1. Never update/insert from client - only on server in methods. 2. Grab over pub/sub only if you want server push reactivity and have a solution to the scale issue (if you need to scale - otherwise, solve the problems you have today), otherwise grab data from methods. How much of this will be valuable in the future of Meteor? I’m not sure - from the 1.6 release notes, they made it sound like things are going to change - especially in the data tier. This isn’t bad (I love new tech!), but it leaves things uncertain.
Full stack support like live queries and subscriptions connected to your Mongo database? Like adding a Collection will also add mutations for it. Like Meteor generates methods for you. But most people advice to create your own methods, instead of trusting allow/deny.
Integration with Tracker or Blaze? There is already swydo:blaze-apollo.
Automatically load data into MiniMongo? You could do this with a custom Apollo cache implementation, but if you’re using GraphQL you won’t need MiniMongo.
It’s already very easy to get started by using the apollo or the swydo:ddp-apollo package. But it’s just GraphQL in the end.
I’m asking this because I’m interested in creating such a tighter integration, but I’m wondering what the expectations are. If the only thing is: it should work like the current Meteor, but with a schema, than use the current Meteor with simple schema.
Why do you want to use Apollo? What does it solve that current Meteor doesn’t? And what does the current Meteor solve that isn’t available in the current integrations?
@yellowspaceboots, could you also elaborate on what you expect from a tighter integration?
Have a look at ddp-apollo and let me know if this comes closer to the integration you’re expecting:
@jamiter On the Apollo Meteor integration I was more using Apollo as a way to connect both my Meteor client (built with React) and my React Native client to the same GraphQL server. To simplify the development process and be able to reuse my queries.
Actually, it’s getting closer and closer to being able to copy and paste my web client code into my native client and have it just work there as wells which is great for me since I am the only member of my dev team
The package you are mentioning is a cool tool but there would have to be some set up on non-meteor clients to access the needed information over DDP. I like DDP and I learned a lot using it over the past few years but it is very specific to Meteor. Having a tighter integration on server side of Meteor with Apollo would allow for easier integration with any client that can run an Apollo Client.
Or maybe I am missing something. How would you utilize the ddp-apollo package to get subscribed data into React Native? or even Native mobile frontends? Would you then maybe use something like react-native-meteor to set up DDP? Maybe Apollo Link would deal with the client for me. I just have not played with it yet. Thanks!
@jamiter Can you link us to the new thread here? Also in response to the “it already works” comment I completely agree for the most part. I am already using Apollo in my Meteor app to allow access from both my Meteor client and React Native client. The only thing it is missing at this point is any instruction on how to use Subscriptions and @live queries. Meteor pub/sub is great and it would be nice to utilize from my React Native application through Apollo @live query.
For non-Meteor front-ends (without DDP), ddp-apollo won’t help you much. In that case it might be better to startup a HTTP version of Apollo and use pure websockets for subscriptions. Which is a bit more work, but documented in a couple of packages, like https://github.com/apollographql/subscriptions-transport-ws
For pure Meteor developers that’s a lot of waisted time though, because we already have a stable websocket implementation.
A note, you could use DDP besides an HTTP server. They do not interfere.
So this is what I’m interested in. You mean like automatically generate queries and mutations with live query support by defining a Mongo.Collection like you do now? That’s I think something @diaconutheodor tried and he ended up building Grapher instead. I would still like to discuss possibilities in another thread, which I still haven’t created. Bit busy and all. I wouldn’t want to start a discussion without the time to respond. Soon™.
Perfect! I would love to be a part of that discussion!
My thought is that Meteor pub/sub could be utilized using Apollo Live query since Meteor pub/sub with Mongo is already reactive. I think from what I saw in the GraphQL Summit 2017 videos that Apollo uploaded to YouTube the main difference between live queries and subscriptions was whether the backend was reactive or not. To me, since Meteor’s server side Mongo is reactive, it would be nice to be able to utilize that from any front end using Apollo Client. Just @live whenever reactivity is needed and let the Meteor magic work on the server and push updates to any client running Apollo Client.
What’s the current status on having change streams (implemented in MongoDB 3.6) in Meteor?
When is Meteor going to move to MongoDB 3.6? Any MDG statement on this?
@km29 Using change streams with Meteor is being tracked in:
Change streams have limitations that make them difficult to use with Meteor for certain tasks (see the issue thread for more details). It’s early days for the change stream spec though, and Mongo devs are watching that issue thread.
That being said, updating the Meteor Tool to use Mongo 3.6 (without integrating change streams) can happen sooner than later. I’ve marked https://github.com/meteor/meteor-feature-requests/issues/233 as pull-requests-encouraged in-case anyone is interested in helping out.
It should be possible to implement service workers already - and even better in 1.6.2, because you can add additional build targets (I think - I’m not sure how to do that, but it’s on my short list to figure it out).
Do you mean source maps in production? These are already available during development.
One place source maps fall apart is in async/await code - that should be better in 1.6.2 because of legacy bundle splitting (what is that feature going to be called?).
I see… I would like to have my sentry errors mapped to source maps. As of now I get errors, but I’m not sure exactly where in the human readable code they are. In expo, they have a hook that shoots up a source map to sentry every time you deploy… would be nice to be able to do something like that with a npm script flag and maybe your settings.json
