I am migrating an existing “classic” Meteor project (a website and admin panel with Blaze & MongoDB & Meteor 1.2) over to React, Redux & Meteor 1.4.1.1.
Is it worth the effort to integrate Apollo? What are the benefits of Apollo besides DB independence?
Is it worth the effort to integrate Apollo? What are the benefits of Apollo besides DB independence?
I’ve been using GraphQL for about 6 months now so I have a little experience with it.
First, coming from a business perspective I would recommend maintaining features/pages that are working. Re-writing or re-factoring just to make the switch is expensive and delays adding user facing value to the application.
IMHO, whenever a page/feature becomes buggy, it should be replaced with Apollo (assuming you want to make the transition of course). It’s easiest to replace an entire page starting from the top shell working your way downwards (in a Russian doll fashion).
I’m also really sold on the container pattern as it’s improved my UI maintainability tenfold. I’m going to explain this a bit deeper in an upcoming video of myself transitioning a Meteor 1.1 React app to Apollo.
GraphQL (and Apollo by extension) has the benefit of giving your API a strong type system so that you have a lot of control in whats going into your database. It also has nice depreciation features to eliminate version REST endpoints with v1, v2, etc… It also has the advantage of sending down the exact amount of data your UI needs so that your responses are as fast as possible. Using fragments allows each view to request the fields it needs and the main query gathers up these fields and makes one request.
Once i’m familiar with the entire workflow, I feel like I can build apps at a much higher velocity than I could before with Blaze/PubSub. Perhaps this is because it’s very predictable. The maintenance velocity is where it really shines. With a 6mo old app with heavy iteration I can still make changes without lots of trouble. Quite different than the “Classic Meteor” with reactivity everywhere. It felt like playing ‘whack a mole’ when adding features.
Thanks for the perspective. I’m on iron router and have a lot of blaze screens. I’d like to migrate a screen at a time over to react keeping most blaze screens and layouts for now, but how without switching out my router?
What would be your approach?
Apollo doesn’t depend on routers at all - we suggest using an approach similar to template subscriptions, where you just do a query when your component is rendered.
Thanks!
I want to add React “screens or views” to my project without replacing my template layouts and blaze screens. I can’t even get to a React “screen” with Iron Router. How will Apollo help me with React Iron Router and Blaze all in one project situation?
I would recommend checking out this repo. It’s using FlowRouter router but has Blaze “pages” and it then renders a react component. I would most likely have the root page be a Blaze HTML template that renders a React component (even though that “component” is really a page with markup). If IR is sending data down via context, you can pass that into the React component and it’ll receive it as props. Ideally IR will only do routing as having it handle data has been a huge source of pain for me.
Also worth noting is that i’m recording a screencast with migrating this app to Apollo very soon so that might help clear up things. (and if it is well received perhaps an entire video course on building a Meteor app Instagram clone type of thing with Apollo).
Thanks for the advice and link. I look forward to your screencasts. Have you thought about teaching this stuff? You seem to have a natural talent for it.
Thanks! I’ve thought about writing a “learn Elixir” book as a first language but it seems like so much work. I’m also really considering making a Learn GraphQL with Meteor course similar to reactforbeginners.com where it’s very distilled, simple, and fairly jargon free.
I guess i’ll dip my toes in the water and try it out with the free migrating to apollo screen cast which will just be me migrating enough to make a spike (as a learning tool for me for using Apollo my other projects). If that screencast is well received i’ll start planning out a full course 
This would also include techniques to produce maintainable apps since that’s typically hard to do.
Great Ideas and strategy. I’ll be attending/watching and try to provide as much constructive feedback as possible. Techniques to produce and maintain apps I think would be well received too.
At this point and under these new circumstances, I feel like I need some resource to help me make the right Meteor + React + Apollo choices. It almost feels like I’m lost again, like I was before Meteor came along (when I looked outside of the .net world of course). Someone, tell me the right way to do things again, give me structure! 
At this point and under these new circumstances, I feel like I need some resource to help me make the right Meteor + React + Apollo choices. It almost feels like I’m lost again, like I was before Meteor came along (when I looked outside of the .net world of course). Someone, tell me the right way to do things again, give me structure!
Haha, I feel your pain! I’m very passionate (obsessed?) with making my workflow as fast as possible so I have a set of boilerplates and tab triggers that i’ve made that follow a strict set of rules (part of why it’s fast), as well as a file generator to spit out tedious boilerplate (React works best with many small components).
As part of my freelancing I have to be able to jump into any client app at any given time so making things consistent and maintainable is high on my list. It also help when working with a team.
As time goes on it’s always evolving but basically the same. I’m most likely going to open source these once I shake out the dust with the React Native boilerplate (routing has changed a bit for the better). In theory you can run a script and you’ll have an API, RN app, and Client side app (api + client combined with Meteor) with all the auth and basic pages ready to go so you can signup/login to a hello world page/view.
Hmm maybe a course on building a small app doing all this would be the way to go haha. 
Anyway I guess i’m drifting off topic but GraphQL is one of the things that help tie everything together… a central (Meteor) API that sends data to a web-client, React-Native app, and other Meteor micro-services. The strongly typed nature also makes things predictable, which brings speed over time (at the cost of a bit of setup).
I think people have explored this idea a bit, but I don’t think we have seen a serious attempt at reducing the setup for a GraphQL app yet. I’ve heard the Reindex guys might be open sourcing something soon, but in my ideal world the setup would be like:
This would be awesome.
Ok. But this I can also get with the SimpleSchema checks, right?
@SkinnyGeek1010: So you say using Apollo is a “no brainer” on new projects? Like “in the future probably all Meteor apps will use it”?
Jup. It is crazy how fast all the web technologies change.
MDG themselves have said that the plan is to have Apollo become the default data layer for Meteor.
I just mean that for me and my work, it’s a no brainer as a default. It has quite a few features over REST endpoints and a lot of flexibility (not true with pubsub and integrating with native, RN, other services, etc…).
Ok. But this I can also get with the SimpleSchema checks, right?
For the most part. GraphQL’s schema is more granular as you have to define all the keys in an object… having object as a type isn’t allowed. The type system also gives you an auto-complete IDE to create/test queries (GraphiQL) as well as in editor tooling to tell you your query is invalid before it even runs.
It’s really more of a SimpleSchema for your Meteor method inputs if you want a closer comparison. The GraphQL schema can be 1:1 with your data but it doesn’t have to be. You could use SimpleSchema for your data layer and the GraphQL schema could be for your API schema.
This might be the case if you have a lot of “virtual” fields that dont exist on the database model itself. For example you could add a field viewerCanEdit and that field runs a field resolver that does some kind of database check to see if the user can edit something. If you have a lot of these then having a sep schema for data (like SimpleSchema) and GraphQL can make things very explicit (albeit verbose). Personally i’ve used the GraphQL schema in place of SimpleSchema/Ecto-Schema and have relied on GraphQL rejecting bad input data.
Hopefully this makes sense, I realize it’s a bit abstract. The tldr is that you don’t have the use SimpleSchema unless you want to.
So @SkinnyGeek1010 is client-side Apollo like an ORM? I’ve worked with MS’s Entity Framework in the past, this is what I have a mental model of.
It’s not like an ORM but more like a replacement for AJAX and a clientside cache. It also has the optional react bindings to give you that nice co-location of views and data fetching.
The schema itself lives on the server side and is not Apollo specific.
I feel like GraphQL is one of those weird looking things that only makes sense once you build something with it. Much like React.
Yep, it’s actually quite cool that the original designers of GraphQL and us at MDG arrived at basically the same design for how data updates should work.