I’ll see if I can do one on the weekend.
1 Like
Why not use this ?
Subscriptions syntax looks different from official package Subscriptions syntax.
2 Likes
While I appriciate your work on this and other Meteor libs, I myself want to stay as close to “bone” Apollo as possible. To me this means, if I can avoid 3rd party libs and still have a feature-set that’s acceptable, I’ll do it.
Sure thing I completely understand.
What do you mean ?
1 Like
You made apollo-live-server and apollo-live-client for implementing subscriptions. This would require extra learning by users, and additional time and effort to refactor to use only MDG’s official packages if we decide in future that we don’t want to (or can’t) use it.
On first looks apollo-live-client looks simpler to use, but more examination would be required to determine what it can and can’t do compared with MDG’s official packages.
It is using official api and implementations of Apollo. The only thing it does is that it makes you write much less code. A little bit of magic for people who do not care about implementation details.
I forked lorensr/test-meteor-apollo and added SQLite Data Source, React UI, Book add functionality, Login functionality, Subscriptions: test-meteor-apollo
I’d like to stop using the additional SubscriptionServer and instead use the built-in one by setting subscriptions option of ApolloServer.
1 Like
I don’t see MeteorAccountsLink() and getUser() that’s part of the official meteor-integration API as it looks like you rolled-your-own instead. Is there a reason?
Though I see that you managed to get the inbuilt subscription server working, which is great: apollo/server/initialize.js. Did you come across the error “Cannot read property ‘headers’ of undefined” on the client?
I think your package is the best out there for those currently looking for a multi-featured Meteor-Apollo integration package. Though I wonder if there could be more DB independence, with more support for using other DBs via the new Data Sources in Apollo Server 2.
1 Like
It states to remove the code below this line if enabling using the built in subscriptions in ApolloServer above…
This line and the commented out code below it should be enabled. Did you try this?
Yes, I tried many things.
To try the built-in subscription server:
- enable
subscriptions:option inApolloServer - enable
apolloServer.installSubscriptionHandlers(WebApp.httpServer) - disable anything to do with creating a new
SubscriptionServer
Since that message was posted, the community supported Meteor apollo package has been updated to work with modern day Apollo (thanks to @loren 
). It’s now a viable option again, and the Apollo + Meteor docs have been updated accordingly. If there’s anything missing in those docs you would like to see added, please consider opening a feature request with your details (or better yet, submit a PR!).
Just to re-cap things a bit, there are currently three leading Meteor + Apollo integration packages:
Each of these have their own pros/cons, and fit different needs. They’re all great though, and can definitely save you time, depending on your requirements.
A fourth option however, is to leverage the Apollo ecosystem as is, without using an integration package. This is honestly not as hard (or as cumbersome) as you might initially think, and again depending on your requirements, might be the best choice. Let’s say you’re building an application that:
- You want to use Meteor’s awesome zero-config development environment for;
- Will be tying into a wide variety of different backend data sources, like multiple databases, multiple legacy REST API’s, caches, etc.
- Will not have any realtime capabilities; so you don’t need Meteor’s livedata (DDP) system
Unifying multiple backend datasources under a common API is a perfect job for GraphQL. Apollo Server is a great way to build a GraphQL endpoint. Apollo Client is a great way to interact with a GraphQL endpoint. Each of these can just be dropped into a Meteor app, and used out of the box as is. So to answer the original question in this post:
Yes - just use the default Apollo Client and Apollo Server docs, and plug both of them into your Meteor app. You don’t have to do anything special to get them working in a Meteor app, especially if you’re just planning on using them alongside each other. Then if you want to start tying the two worlds a little more closely together, look at the above linked to integrations to see which one will give you what you need. For example, if you just want to make sure your GraphQL API is aware of a logged in Meteor user, then the apollo package is the answer (since that is essentially all it does). Then if you want to take the integration further, look at the other packages.
8 Likes
Thank you @hwillson for the detailed explaination and the new integration docs! Your efforts on the Meteor project are greatly appriciated! 
Did you manage to get subscriptions working without needing to create your own SubscriptionServer?