Does that preclude them from the server bundle?
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:
During dev, when I change anything in the client folder, only the client will refresh. Anything in the API will cause server to refresh.
Me too. Iâm slightly worried about the eerie silence in the Release 1.8.1 pull request 
I have to test this!!! 
Result 
2 Likes
Yeah, I am a bit bummed about this as well. It seems we lost @abernix and @benjamn to the new shiny object 
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?
5 Likes
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.
3 Likes
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.
3 Likes
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.
2 Likes
This is assuming youâre not using sockets with real-time subscriptions in graphql? I mean being stateless is no different than REST.
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.
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.
5 Likes
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.
2 Likes
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)
1 Like
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)
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!
3 Likes
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.
6 Likes
/Thread right here folks.
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.
3 Likes
The sarcasm was unnecessary, the âsorry butâ notwithstanding.
Welcome to open source.