@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.
1 Like
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. 
1 Like
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.
Why wouldn’t you just do a build and bring the tarball across.
No need for meteor-tool, no .meteor directories, no packages. Just one compiled node app. Just need to npm install in the server dir on the same architecture to ensure correct binary is compiled.
Where I’m working now we do this to deploy meteor apps on kiosk devices with limited connectivity (ie. Chrome kiosk with app connecting to localhost)
1 Like
Hi @coagmano, the reason why I didn’t build it is the client server has some parts which are different from my current developing environment such ldap, mssql, browser, etc. Everytime when I update something, I need to do some modifications to adjust to the client server.
During the developing period, I think I will still use this method because I can do some minor onsite updates or bug fixing. If the development finishes, I will definitely appreciate the method mentioned by you. Thank you.
Honesty I think the complexity in your case is the dev/test environemmt and not the framework.
maybe yes, but it is a real scenario which proved that meteor is kind of offline unfriendly.
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.
1 Like
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.
1 Like
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.
2 Likes