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 ?
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!
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.
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âŚ
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.