+1 for this
Meteor has made it really easy to work with many web technologies - would love to see that trend continue with service workers.
UI performance is a different story. The point is, Meteor is a web stack at heart, so in certain ways, Electron suits it better than React Native. Plus, RN is like its own eco-system, so if anything, they should be providing a Meteor integration, not the other way around.
I have to ask, why is http/2 an issue? I had a meteor app delivered over http/2 on NGINX.
My +1’s are:
React Native would be nice, but then I’d much rather build a simple API with meteor instead and hook RN up with that instead. You lose reactivity, but it depends on the app as to whether that matters.
React Native is definitely its own whole thing - I’ve even looked at things like the asteroid package in the past to get it done, or some of the webpack meteor build workarounds.
This could be fixed in Storybook, I suppose. I think Jest can be configured to understand Meteor imports.
I’d like to see:
Here’s what I am hoping for this Chrismas. It would be great to get everyone’s taking on it:
I definitely vote for the whole data layer:
pub/sub with Mongo oplog is okay for prototyping cases but the more users you have on production, the more a bottleneck it becomes.
As people already said: is there a way to integrate Apollo deeper into Meteor? Of course it is already possible to integrate Apollo yourself, but having very simple (read: few lines of code 
) solution like the current pub/sub would be just great.
Frankly speaking - I think many users think like this: Anything works for me. What I want as a app dev is not worrying too much about how the data gets to the client - I just want it to be reactive when I want it to be and I want it to be as fast as possible.
I does not really matter me how all this works in the background: RedisOplog, standard Oplog tailing, Apollo - you name it.
I think that might be an oxymoron given how GraphQL works.
For me as a lot of people have already said a tighter Apollo integration would be nice. More so because I would love a straight forward way to use Meteor Pub/Sub to fuel my Apollo subscriptions giving me back some reactive variables without needing DDP. Not that I dislike DDP it just seemed like using Apollo was easier for integration with my React Native app.
As far as React Native is concerned what type of integration are you guys thinking? I set up an Apollo server on my Meteor application and then I can access it from both my Meteor client as well as my React native app using Apollo Client. The code base is almost identical (I am using React on my Meteor client). Using Apollo the Meteor and React Native integration seems pretty easy already. Just a small tweak on the React Native to save and recall the accounts token to AsyncStorage and it works just like meteorClientConfig for Apollo Client on my Meteor Client side. Btw good job on 1.6 and Apollo Client 2.0 MDG!! 
@yellowspaceboots Are you referring to something like in this gist? https://gist.github.com/elie222/2ea0e1548dc0c634342fed942f6ea207#file-meteorapolloclient-js-L67
Are your changes to Meteor.user reactive? Did you use react-native-meteor at all?
I totally agree with @storyteller . Working offline meteor is full of painful, and especially Meteor are using kinds of chocolate now. It will normally take me tons of hours to transfer latest version of meteor application to an offline environment. Although meteor is getting better and better right now, it also become more and more offline-unfriendly.
I suppose they mean disconnecting their computer from the network and keep on developing an app. Like getting on a long distance flight and hacking away on some work by the time they land.
I vaguely remember some environment variable or some flag that allowed this, though, hmm…
But you can write code and test your app locally? Why exactly do you need to be connected? I am still confused…
Do you think is windows only or it might have been resolved after 1.3? because I certainly did’t experience any of that working offline or on poor connection.
@townmulti Yes I did have to use react-native-meteor but only as a HOC in order to make Meteor.user reactive. If there was a straight forward way to use Meteor pub/sub with Apollo subscriptions or better yet, since Meteor pub/sub is reactive I could use Apollo’s @live query, that would remove the need for react-native-meteor at least in my use case.
I would be able to access the data from my Apollo server (based in Meteor) from React Native Apollo Client the same way I would access it from my Meteor Client and be able to turn reactivity on for things such as Meteor.user and serve the other data over http.
I feel the React Native/Meteor integration is accomplished in the Apollo Client/Server layer very well and has worked for me so far and since I can use my Apollo Server schema and revolvers for both clients I can copy and paste the actual queries from one client to the other and get the same result.
Yup, it’s probably something quite old.
Lmao welcome to web dev
Here is my case: I am working for a client whose server is totally offline, and so I need to develop the meteor app in my computer and transfer the developed version to the client server.
Firstly, I need to download the meteor alternate windows installation and move it to the client server. Secondly, extract the installation archive somewhere and set up the PATH environment variable. However, the version of the provided installation archive could be different from your in-service meteor, so here is the next step.
Copy in-service meteor-tool and paste them into the client’s meteor tool; Copy all in-service packages (except meteor-tool) to .meteor/package and merge them.
Usually, life could not be such easy. Because meteor packages have a lot of super long paths everywhere, you may need to zip them all and unzip them again in the client server or carry out this with some kinds of tool to fix long path problem.
The entire procedure always takes me more than 8 hours because zipping, unzipping and moving package that includes more than 400,000 long path files are not a save-worry thing.
Congratulation! You have finished the setup part of meteor offline developing.
Update or install a npm package is easy because it will come with your project folder. But if you want to update or install an atmosphere package, probably this article is helpful (http://smittey.co.uk/using-meteor-offline/). But I am sure I will not spend over 3 hours to update an atmosphere which I really don’t know what is the difference. So I would scrape them up and do them together.
Update an important update of meteor? No, I used to spend a week to update from 1.4.2 to 1.5 and I finally knew these offline skills when meteor taught me.