Styjun

I know this question is as old as time -- and their is no silver bullet. But I think there might be a solid pattern out there, and I would like not to invent the wheel.

Consider the following two schema options:

Approach 1) My original implementation

type Query 
 note(id: ID!): Note
 notes(input: NotesQueryInput): [Note!]!

Approach 2) My current experimental approach

type DatedId 
 date: DateTime!
 id: ID!


type Query 
 note(id: ID!): Note
 notes(input: NotesQueryInput): [DatedId!]!

The differences are:

with approach 1) the notes query will either return a list of potentially large Note objects

with approach 2) the notes query will return a much lighter payload BUT then will need to execute n additional queries

So my question is with the Apollo Client / Server stack with in-memory-cache which is the best approach. to achieve a responsive client with a scalable server.

• With approach 1 -- my 500mb dyno (heroku server) ran out of memory.




• I expect with either approach I will implement pagination with the connection / edge pattern




• the graphql server is primarly to serve my own frontend.

If you're running out memory on the server, it may be time to upgrade. If you're running out of memory now, imagine what will happen when you have multiple users hitting your endpoint.

The only other way to get around that specific problem is to break up your query into several smaller queries. However, your proposed approach suffers from a couple of problems:

• You will end up hammering your server and your database with significantly more requests


• Your UI may take longer to load, depending on whether the requested data needs to be rendered immediately


• Handling the scenario when one of your requests fails, or attempting to retry a failed request, may be challenging

You already suggested added pagination, and I think it would be a much better way to break up your single large query into smaller ones. Not only does pagination lend itself to a better user experience, but by enforcing a limit on the size of the page, you can effectively enforce a limit on the size of a given query.

One other option you may consider exploring is using deferred queries. This experimental feature was added specifically with expensive queries in mind. By making one or more fields on your Note type deferred, you would effectively return null for them initially, and their values would be sent down in a second "patch" response after they finally resolve. This works great for fields that are expensive to resolve, but may also help with fields that return a large amount of data.