As 1.6 release is quickly approaching delivery, I am interested if there are any vision about what’s next for Meteor for the next major version? What will be the main theme for it? NPM only packages? Mongo 3.6 support? Performance improvements? Apollo integration? Anything else?
BTW about Apollo, I don’t really follow it but how is it going? Any chance some devs comes back to develop Meteor so it’s not only mainly Benjamin with beast mode activated? I checked Apollo it once for my java project but graphql just doesn’t really solve any important problem for me just introduces more complexity and I never choose complexity over simplicity (REST in this case). Maybe Java is not the best stack for graphql I don’t know. Anyway what’s going on with Apollo?
I’d like to see a MongoDB-centered release. It has come a long way since the early days, and with change notifications, maybe Meteor’s “biggest” problem can finally be addressed.
Not sure if it makes sense, as I haven’t worked yet with Apollo, maybe we could start integrating Meteor and Apollo further and further.
+1 on MongoDB and Apollo focus. Also, anything that would make running Meteor apps on Galaxy cheaper (which I guess means more sped improvements for the server and official packages).
i would also vote for mongo and deeper apollo integrations. doing live updates and optimistic ui is still not such a no-brainer like it was with ddp.
React-native integration would also be nice
I second that. There should be a release focused on the data tier. Things like the write concern feature is something that’s rather interesting for installations were you do business critical things in the production environment like for example with the semiconductor industry.
What about Service workers and groundDB for Progressive Web App and full offline support official package in Meteor ?
What about making blaze good again with SSR ?
What about lowering the entry curve again ?
I miss the good old day where the meteor was so simple to learn, without imports and stuff, I think there should be 2 flavors as of now: proto and prod. The learning curve should be clearly easy on the proto guides and tutorials. The prod guides and tutorials should put accent on optimization and security, while the other should put focus on getting stuff done and give more examples.
There are so many good things in Meteor but a beginner user today can be lost very easily in this mass. This was not the case 2 years ago.
Why not cherry pick the best practices as of now (Meteor Guide seems a little bit outdated already, and it is not clear where the cursor is between proto and prod).
We need more tutorials for the proto flavor, and more tuto for the prod flavor, showcasing more use cases: how would you start a chat today? a dynamic map application today? a faceted search with a list ? these are the kind of things a beginner might be interested in…
We lost the quality in Meteor tutorial: see React or Blaze tuto, it starts by introducing so many concepts like ES2015, I remember when it actually removed some concepts, making understanding of HTML actually simpler.
Blaze templating was a really good thing but now the baby is behind React for example, if I had the same features on Blaze I would go back to Blaze (SSR, performance, easy componentization and nesting of components)
I wish Meteor folks would just break the entry barrier once again. Expanding on NPM was a very healthy thing, but after expanding we need to consolidate.
Re Apollo:
I think the Apollo and Meteor-Mongo have totally different use cases, and that MDG needs to “close the loop” on Meteor. After all, everyone was sort of figured that oplog tailing was a temporary solution, and its probably the top reason many have left or avoided the framework.
Example: apps such as Trello do fine with just MongoDB. Some of them use Redis for the real-time features but that may not always be necessary once Change Streams come out. For such apps, Apollo would add unnecessary complexity and latency.
React or Blaze ?
Angular or Vue
Mongo ou Apollo ?
Publish or Method ?
…
I just want a no-brainer solution that works in all cases
agreed -updated tutorials, and meteor flavors
Apollo/GraphQL can still work with MongoDb, I don’t know how much latency is added, esp when you get benefits like caching/pagination etc.
It can but its a lot more work than working directly with MongoDB, so there’s a lot less logic to write and process, and you miss out on the real time features that Meteor brings in.
As for latency, take a look at Grapher - they are claiming 40x less latency compared to Apollo.
Apollo was intended to consolidate many data sources into one - but for many just having one or two data sources is fine, especially now that Change Streams are coming.
+1 on the offline functionality. Meteor has a great support already so expanding on that to make it fully progressive, or even better, offline first app would be really interesting. Maybe something along the lines of Hoodie?
Yeah I forgot about react-native, that could be a great feature.
But for community in large it still seems that performance, scalability and deployment is something that could have some more improvement. Benjamin was working on the issues raised by community on the last few releases. It seems to me that Mongo 3.6 and its notifications API is a logical next step for Meteor, maybe together with some additional performance improvements in the framework itself. That would be great!
MongoDB with change notifications and a deeper integration of apollo is what I wish for christmas. All method/subscription extending core packages like accounts should get their respective official graphql resolvers/schema. @nicolaslopezj s https://github.com/orionsoft/meteor-apollo-accounts should be part of the platform.
Apollo/GraphQL is also about consolidating requests and reducing roundtrips, even if using a single data source. I haven’t looked at Grapher in detail but I hope MDG is going to bring Apollo to Meteor.
Live queries/reactivity are missing in GraphQL but I hope they can be added to Apollo using a MongoDB 3.6 data adapter.
+1 for React Native and MongoDB.
I’d rather see Electron than React Native. It fits well with Meteor’s theme of a cross platform web stack, and can sit right next to Cordova.
+1 for MongoDB change notifications instead of oplog with MongoDB 3.6
Nobody’s making you use imports, and there’s no need for two flavors. The old meteor code from 2 years ago still works today, there are just more options if you want to be more aligned with industry standards (which is a good thing).