Apollo suppose to make things easier - What am I doing wrong?

I am working on a quite new project for a client which has the opportunity to grow quite big over time. After settings up my basics I thought it would be ideal to use Apollo on this project in addition to Meteor / React. I learnt the basics, set up everything and it is working (yeah !). So pretty boring story.

I am still new to Apollo and my problem is that using Apollo I changed some lines of Meteor/Mongo code to hundreds of line of type, input, queries and so on and I start to very much doubt about how usefull it will be for me.

To be a bit more precise in my case I have quite a lot of input data that have to be typed in by the client and those data are used for some specific calculation using an external solution on server side and then you get some results. The input data can be saved

It’s an object with booleans, strings, arrays of objects, objetcs… so quite a complex fellow. While in ‘classic’ Meteor/Mongo I was just saving my data object as a whole with some type checks, using Apollo I had to define the whole thing manually with all the “type” and all the “input” which is a 200 lines .graphql file. I then have my mutations separately and the resolver (which at the end is just doing Collection.insert({}).

Then when I want to call my objects, as there is no “*” wildcard I again had to define a 100 line long query…

Here is the question, or more the discussion opener : Am I missing something, doing something wrong, or will it be usefull over time ??

Before when I wanted data from Mongo I was just Meteor.call(‘getCalculationData’, calculationId) and then storing them in my react state and now I need a 100 line query ? Is my project not right for Apollo, or will I see the light later when it becomes bigger and more complex ?

Thanks in advance for your opinion.

Hey! Sorry to hear you’re having some issues with the Graphql type system. There IS a way around the issue that you are describing by using a custom scalar type for JSON. Here is an npm package that implements this. https://www.npmjs.com/package/graphql-type-json . I have not used this package myself but I have seen people use a JSON type in graphql’s type system to avoid having to define every part of a complex object like you are describing or if they are not 100% sure of the shape of the data they are getting back from their API call they can just say “I am getting JSON” and handle it in their application logic.

There are obviously upsides and downsides to this because it is definitely a lot easier but you also give up the type safety you get from graphql. You could also use this initially for development and then maybe you could migrate to a more defined graphql type at a later date. Hope that helps!

1 Like

I personally think RPC approach is preferable when you don’t have a need for flexible API serving multiple end points. At the end of the day, it’s really hard to beat the simplicity of RPC methods they’re just async javascript calls.

1 Like

That (having a need for flexible API serving multiple end points) is in my view one of the main benefits of GraphQL. That, and the friendliness to development/testing tooling.
IMO, in a Meteor world (generalising):

  • if you don’t have the need to fully insulate your API consumer from your API provider - like when you want/need to have full control on the functionality of the API consumers and what data each will be able to get and at what end-point - you will be better served by Meteor methods + pub-sub where appropriate than going the GraphQL way.
  • If you don’t really care or have tight control on what multiple API consumers use from your backend and want to provide easy access to your data, sure build an GraphQL server.
  • If you are primarily a API Consumer and are consuming third party APIs, then you may wish that the API Provider would have nice GraphQL end points, so that you would not be “hard-coupled” to any RPC interfaces…
1 Like

Sorry if I am missing anything. What is RPC approach?

I am using GraphlQL scalar JSON type to download and store complex Mobx-State-tree Snapshot. It is working fine. I ensure type safety using Mobx so there is atleast one level of safety there.