Question: Apollos @cacheControl directive on code-first approaches

[Mika83AC]

Hello Apollo-Team,

first a huge thx for your awesome work with Apollo server and client.

As cache is most important in APIs, for sure we also need this and want to take advantage of Apollos built in @cacheControl directive to set type and/or field specific max-age values. BUT we don't want to go the SDL-first approach, we want to ride the code-first approach as it was originally intended by GQL and where the pendulum is swinging to in the community currently.

But aiming for this approach it turns out that Apollos @cacheControl directive isn't really possible with that code-first way because it is a SDL extension, but is not supported by graphql-js on which most code-first libraries (which graphql-js itself is too) rely on.

So what's your idea or plan of giving the full power of Apollo servers cache control to those people who want to use Apollo/GQL in a code-first way? Is Apollo participating in the graphql-js efforts to bring directives to the code-first world?

graphql/graphql-js#41
graphql/graphql-js#1789
prisma-labs/graphql-framework-experiment#53

Sure Apollo server also offers the way of adding cache control information via info.cacheControl.setCacheHint, but this is way more verbose and also will not be communicated via Introspection or SDL generation to the clients or people consuming the GQL service. So they can't know about the cache times for each type/field as it would be when using the SDL-first approach.

So I think it would be a huge benefit and win-win for the whole community if directives could be brought to the code-first approach sooner than later.

So I'm kindly asking you for throwing in Apollos power as a GQL platform leader to make this possible in the near future :) And I'd highly appreciate some information about your thoughts and plans on this topic to get a better idea of the road we'll have to go with the code-first approaches.

Best regards,
Michael

[timsuchanek]

I have the same situation with using nexus.
As it doesn't seem Apollo will look into this, I started my own dedicated GraphQL CDN - https://graphcdn.io/
It supports any GraphQL backend and makes caching much easier and faster.

[glasser]

I'd be excited to see something like graphql/graphql-spec#300 become part of the GraphQL spec, so that libraries would have an easier way to generate the equivalent of our directives from something other than SDL.

In the meantime, I don't really understand why code-first libraries don't just let you hackily generate some AST nodes in order to provide directives.

I don't think we're likely to make any changes in Apollo Server around this until there's a GraphQL feature to take advantage of (eg, changing the recommended @cacheControl directive to a metadata directive). In the meantime, as you said, you can use dynamic cache control as a workaround.

I don't think this issue is actionable within this project so I'm going to close it.