Frankly it proved that your environment and process are niche and web develeopement unfriendly, that’s why I was confused because I develop offline daily.
You are trying hot patch an offline test/deployment severs by manually installing Meteor and modify the code on those machines, and you wanted to do frequent modifications and testing. Im my opinion you need a proper test environment with internet connection that you can install meteor on.
I think this is a good use case for Docker. Or using VM’s with Vagrant. They were meant to have a reproducible dev/test environment.
I 100% agree the development environment or the test environment you called is completely user-friendly, because it can connect to internet. However, the client server which can’t connect to internet where I think the enviornment is OFFLINE is offline-unfriendly. Not all the computer we are using can connect to internet now, and so I think meteor can provide a offline installation at least. Also, an hot plug of atmosphere package should be provided.
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.
Not my personal thing, but something to consider could be official TypeScript support. It is becoming quite popular in corporations.
Meteor 1.7 should be probably the lates latest point to get on Babel 7 (unless it takes them forever to get it released).
I agree and hope to see a tighter Apollo integration.
What do you expect from such an integration?
swydo:blaze-apollo.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:
Thanks!
About the Apollo integration: some discussion was happening in this thread:
Most responses were something like “it already works”.
I’ll start a new thread discussing the current state and what people expect from a tight Meteor + Apollo setup.
@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. 
Apollo + React/React-Native is AMAZING
Thanks for coming back to me on this.
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.
I’d like to see the removal of the imports directory and if Meteor projects still need the folder (use an imports or globals atmosphere package)
service workers for offline support in 1.7 please
source maps god please
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).