Atmosphere still provides huge advantages for rapid development in Meteor over npm.
Sometimes you want to have meteor-opinionated packages which enhance your app easily with a special collection (could you guys live without ostrio:files for example?). While such a package would still be technically feasible even after going 100% npm, it’s a big hassle to develop it because of all the dependency and packaging stuff.
It’s so simple and easy to develop ES6 native packages with atmosphere, using the same build system as the app. I certainly don’t want to use Lerna and tools like Rollup just to structure my apps, and I don’t want to maintain 50 .babelrc files as well. Therefore I’d like to see Meteor move the platform to npm, but only if we don’t lose the simplicity of what atmosphere packages are providing to us today.
Maybe it’s time for some atmosphere 2.0, like a package.json+ file where you can embed all the meteor config from package.js inside. These kind of packages could be completely opinionated to a meteor platform version defining the way the package gets compiled.
To give a counter-example though, using Meteor packages makes it impossible to use tools like Storybook because it doesn’t know what import foo from 'meteor/foo' means.
Agree, that‘s why I would go more ‚npm-ish‘. In the storybook case storybook is handling compilation so if the module is all raw source it would eventually work, right?
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:
mongodb change streams
official docker support
Apollo Meteor Accounts
Service workers
Electron
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.
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.
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!!
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…
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.
) solution like the current pub/sub would be just great.