I’m going to be slowly migrating a prod app over to Apollo server and client and I need to spike out a test first.
Since I have the react-ive meteor app I was thinking of screen casting myself migrating the app over to apollo server/client to replace the pub/sub, meteor methods, and maybe login/signup.
It’s a fair amount of work to record these so I would appreciate if everyone who’s interested could heart this post or add a comment so I can get a feel of how valuable this would be for the community (if it’s only a few interested i’ll just throw the code up on github afterward).
One thing I’d really like to learn about is if it is feasible to migrate just one part of the app, rather than the whole thing at once. This is something we would really want to be good, so that people don’t feel like they need to spend a whole ton of time rewriting everything to get some of the benefits.
Yes, I totally agree. In fact that will be the only way I will be able to migrate my prod app… I can’t really stop development or create a long running branch.
My plan is to migrate pieces at a time, keeping each commit deployable and tests passing (err if there were tests). However, the app is so small that I wont be able to have one view use the old subscription and another use the GraphQL data.
The migrating the user will be the last step since it’s so heavily tied to accounts and a lot of logic uses Meteor.userId() and expects it to re-render on change.
I think I would do it one view/page at a time, and implement whatever methods/data loading stuff is necessary just for that one view. At least, that’s how we did it for Galaxy.
Doing it for one collection, you wouldn’t get any of the data joining benefits of GraphQL.
I partially agree with @sashko. However, I think, the majority of Meteor developers will do this migration for the first time, so the main target will be not to make use of joins et al, but just to migrate without breaking the code I mean, that for the first step the app should just work as before, so @awatson1978 could be right as well.
As for myself, I would try to make the temporary replacements for publish/subscribe methods keeping the same API interface. After that I would switch to these methods and when everything works as planned, I can think about code optimization by using exclusive GraphQL/Apollo features.
I guess my point is that there is no reason to migrate just for the sake of migrating - you should only do it if you get some benefit. Pub/sub isn’t going to break anytime soon!
I am with you here. I just mean that it is easier to start this migration without changing the previous app logic immediately. Sure, after the Apollo is already within the app the next step will be the rearchitecting (slight or not, depends on the app/views).
@SkinnyGeek1010 I agree with Sashko but maybe more important is that I think it would be a great to see someone reason through an existing app and attempt to guage where you would get some benefit by adding Apollo
To me it seems you may not want to migrate portions of your app that:
depend on reactivity *
depend on optimistic UI updates *
scale well enough as-is
have data that is happy living in Mongo
wouldn’t benefit significantly from having a normalized data structure
don’t significantly benefit from switching to Redux from Minimongo
* not currently implemented in Apollo
Even if you skip your own conclusions from this process in order to have a more substantial migration it would still be interesting to hear.
In my limited experience the main reason to migrate away from publish/subscribe has been server cost and complexity (due to the implicit nature of the pubsub & reactivity).
I’ve been able to drop server costs from around $100 a month to $7 by swapping out publish/subscribe for Meteor methods. At the time I was using local minimongo collections to insert data returned by the method (and therefore providing Blaze reactivity on change). I imagine performance gains will be very slightly better with GraphQL (lack of websocket overhead).
Complexity is a key factor for maintainability. If you install several packages that are all using publications it’s very easy to end up with a mess that’s hard to trace data flowing in and out. Before you know it things slow down because it’s hard to determine what to is extraneous.
Ideally starting from scratch I would use pub/sub for things that need to be real-time reactive (say chats) and other things can use Apollo to long poll every X seconds/minutes. Then for server data use Apollo and try to skip Redux for local state unless you need it. Since it’s a dep. on Apollo (currently) it’s not too much extra effort to use it to track the state of a modal or something that needs to share global state with other things. I think a lot of people forget that the local React setState still works great Having data containers helps cleanup that local state as well.
For existing apps if you’re having issues with state unexpectedly changing, or not updating when you expect, migrating to something more structured could help. Response time is another one… if it takes a long time to get a subscription perhaps Apollo could help. I agree with @sashko on not migrating unless you have an issue.
