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
Meteor 1.7 should be probably the lates latest point to get on Babel 7 (unless it takes them forever to get it released).
1 Like
I agree and hope to see a tighter Apollo integration.
What do you expect from such an integration?
- 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:
Thanks!
4 Likes
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.
1 Like
@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!
2 Likes
@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
4 Likes
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™.
2 Likes