2

I have an existing codebase that uses Meteor methods to take requests from the client and perform database operations on the server. I'd like to attempt to move this project to GraphQL but I'm having trouble understanding the scope of that work, particularly what that would mean for these Meteor methods.

A) Does GraphQL replace Meteor methods? So I would re-implement this logic within GraphQL queries, resolvers, and mutations?

B) Does GraphQL work in series with Meteor methods? I.e., the client calls a Meteor method, which inside calls one or more mutations on the server?

C) Does GraphQL work in parallel with Meteor methods with a distinct separation of concerns? I.e., all database operations are offloaded to client-side mutation calls, but all other processes (such as firing off emails and other jobs) still happen within Meteor methods.

Hoping to find some clarification on this topic. Thanks!

Jon Cursi
  • 3,301
  • 4
  • 27
  • 53

1 Answers1

5

The answer is: you can do all three, but you should make a decision and stick with it.

I personally used Meteor methods for hiding code from the client/validating inputs to methods. In this sense when I switched to graphQL I "replaced" meteor methods and meteor's DPP model entirely.

However, there's really nothing stopping you from calling meteor methods inside of GraphQL resolvers. There's just no real reason to do that, as resolvers are server side.

However, it can be tempting to save Meteor methods for handling data of a highly variable structure (say for example XML files) that need to be validated, but can't be given an "exact" structure that the GraphQL queries and mutators demand. So in that sense the two can "work together" as Meteor methods aren't as rigid.

That said, using GraphQL methods opens up a whole bunch of benefits you don't get solely using meteor methods, like cache normalization, the ability to filter data and only retrieve what you want to retrieve, and subscriptions.

mstorkson
  • 1,130
  • 1
  • 10
  • 26