What's coming in Meteor 1.9?


#61

Does that preclude them from the server bundle?


#62

Yes it will preclude them, they won’t be accessible from the server files.

I only use the client folder for the UI pages/components to speed things up, I think the only case you need to access the UI pages from the server is for SSR, but for me I only needed that for few pages (home/login etc) and the rest are all dynamically imported pages from client folders.

Here is an example of a folder structure that uses this technique:

08%20PM

During dev, when I change anything in the client folder, only the client will refresh. Anything in the API will cause server to refresh.


#63

Me too. I’m slightly worried about the eerie silence in the Release 1.8.1 pull request :fearful:


#64

I have to test this!!! :wink:
Result Capture


#65

There’s a nice PR to make this obsolete https://github.com/meteor/meteor/pull/10455


#66

Yeah, I am a bit bummed about this as well. It seems we lost @abernix and @benjamn to the new shiny object :confused: And for me I don’t really see the benefit of Apollo since my whole app lives in the Meteor ecosystem (Mongo, DDP, and the likes). Are you feeling the same way or am I missing something about Apollo?


#67

Yeah, if Mongo fits your needs and you rely a lot on reactivity, then Meteor’s livedata mechanism is hard to beat in terms of speed of development. The only complaint I have is that it’s not stateless and doesn’t support joins. Because it’s not stateless it’s hard to scale and it’s not resilient to container/vm crashes/disconnections. Because it doesn’t support joins the data structure is usually heavily determined by the presentation layer, which makes it hard to change your presentation layer without touching your data layer.

GraphQL might prove to solve these 2 complaints. https://github.com/hasura/graphql-engine seems interesting in this regard. But it’s all still very young and fast-changing.


#68

It’s my understanding Apollo is best for very large apps, otherwise, it’s not really worth migrating to. Most things can be done with Meteor Methods. Just my opinion of course.


#69

I’ve the same feeling as @methodx I think Meteor’s pub/sub and RPC methods are great for small to medium size apps and GraphQL/Apollo shine when you want to have flexible API coming from multiple data sources.

With that said, a lot of the ideas from Meteor data layer are being applied to Apollo. The Apollo Client 2.5 that was announced yesterday aims to make GraphQL the one source of truth (used in both client/server) which is kind similar to mini-mongo.


#70

This is assuming you’re not using sockets with real-time subscriptions in graphql? I mean being stateless is no different than REST.


#71

That’s the assumption indeed. Although websockets on their own aren’t necessarily the problem. But Meteor’s mergebox system makes that the server has to keep track of a lot of the client state, which makes the problem harder.


#72

The section about code splitting would have been a great opportunity to promote Meteor’s great code splitting system. The fact that they don’t try to piggyback Meteor on the Apollo hype (if anything it looks like they try to distantiate Apollo from Meteor) makes me worried for the future of Meteor.


#73

Now, seriously, what’s the worst that can happen? MDG abandons it. Then we all pick it up. You know how to code, so I’m sure the more you think about how you’d do it, the less worried you get.

To be honest, I wouldn’t like Meteor becoming some bundling tool for Apollo, a sideshow. It might actually be better.


#74

Totally agree. Checked on LinkedIn what staff is remaining and it seems most of them changed actually to Apollo (not sure if that is just a renaming exercise)


#75

What is the criteria for large or very large apps? We don’t see the need for Apollo and from the LOC’s our apps (separate apps for frontend and backend) we’re not small anymore.

Neither from an infrastructure PoV, unless you mean running your apps with millions of users (but that has nothing to do with Apollo then)


#76

I highly doubt that. As you seem to have spare time (to pick things up), could you do me a favour and build MongoDb multi-document transactions into Meteor?

Thanks for your time

PS: Sorry for the sarcasm but I’m pretty sure that everyone here is pretty busy with their own company or project!


#77

I’m not using GraphQL as I’m happy with Meteor RPC, pub/sub. I used gRPC in my past life and I know from experience it’s really hard to beat RPC calls in terms of simplicity.

But I also worked in a large team before where our APIs were consumed by many other internal teams. We had a lot of issues with managing the expectations around the changes of the REST APIs since any change in the API signature ripples to others. Furthermore, to create those APIs we had to glue many different sources together. So when I saw GraphQL the value proposition was very clear to me, it’ll enable us to change those endpoints without being crippled by rigid upstream requirements. But if don’t have that need, then why add the extra boilerplate code and complexity when you can get away with simple RPC?

That’s why I think for large enterprises with many internal teams sharing fast changing endpoints, GraphQL and Apollo make a lot of sense. It explains why MDG is focusing on that, large enterprises pay money meanwhile bootstrapped entrepreneurs and SMB will do every trick in the book to avoid the additional costs.

Some will do because they’ve the extra time/skill and there will be financial incentives for it, in facts it already happened with Kadira.


#78

/Thread right here folks.


#79

it’s a bit of a missed opportunity of mdg of not pushing meteor as a platform to run apolloserver or client, because it works pretty well for both. I just created an online shop in 5 days with 2 meteor apps, one for a ssr-frontend (used similarly to next.js, actually i could eaily replace it with next, but my setup is currently more adapted to meteor), and one meteor app as backend (using a new os-headless graphql-shopsystem called unchained: https://github.com/unchainedshop/unchained)

i mean, if you know how all these tools work, such a setup is not hard, but it needs some work and thought to have everything properly setup.

meteor could here provide some addional convenience, e.g. provide out-of-the-box SSR with react and apollo support. Would also help mdg to bring one or the other developer to galaxy and apollo-platform.

I would als not mind, if they would come up to a similar platform/bundler as meteor just for apollo-backends.


#80

The sarcasm was unnecessary, the ‘sorry but’ notwithstanding.

Welcome to open source.