Adding extensions to query fields

[mmahalwy]

builder.queryField('session', (t) =>
  t.field({
    type: SessionObject,
    authScopes: { authenticated: true },
    extensions: {
      foo: 1,
    },
})
);

This doesn't seem to work with apollo server.

[mmahalwy]

I think this is also preventing this from working for these scalars: https://github.com/Urigo/graphql-scalars/blob/master/src/scalars/json/JSONObject.ts#L17

[hayes]

How are you running codegen? I don't think giraphql would impact how this works

[hayes]

What is the behavior you are expecting from adding extensions? Not clear what you are trying to do, and what is not working. A more complete example with the expected behavior would be helpful

[hayes]

Implemented a field similar to the above example, logging (builder.toSchema({}).getType('Query') as GraphQLObjectType).getFields()['session'].extensions does have foo: 1 included in the fields extensions

[mmahalwy]

Trying to figure out if it's apollo or giraphql, but expectation is extensions would be included alongside data in a response. Similar to have extensions is added here with apollo tracing, my expectation is foo: 1 would be included in that object.

[mmahalwy]

I guess, the punch line is how to use the extensions object in the response with apollo server

[mmahalwy]

I noticed this is how typegraphql does it: https://typegraphql.com/docs/extensions.html

They have a concept of 'middleware'.

[hayes]

the typegraphql extensions api would be very similar to the extensions api in giraphql currently. giraphql does not have a concept of middleware, but plugins can wrap resolvers in a very similar way. Needing to implement an entire plugin just for some simple middleware is a little too complex for simple use cases, but writing a plugin that lets you attach middleware to fields or globally like type-graphql would be pretty trivial

[hayes]

I think you are conflating 2 separate concepts:

1. the graphql library has a concept of extensions that are basically just objects that exists on most objects that make up a graphql schema (types, fields, etc). This is used in a lot of different ways, but mostly commonly this is the mechanism decorators attach data to a schema in a way that can be accessed at runtime. These extensions are frequently accessed through the info object when a resolver is wrapped by a plugin or decorator.
2. Apollo-server has attaches an "extensions" object to responses, this is completely unrelated to the extensions properties added in your schema. This property is attached by apollo plugins, and is a non-standard part of graphql.

Generally speaking, giraphql is focused on building graphql schemas, and resolving fields and data as part of that schema. From this perspective the "extensions" property added by graphql exists entirely outside the execution of a query (it is attached once the query has already been resolved).

The way to extend the extensions property in an apollo response, you probably want to use a custom apollo plugin. Plugins for apollo are actually pretty easy and straight forward to write. You can see how the extensions are added by the tracing plugin here: https://github.com/apollographql/apollo-server/blob/main/packages/apollo-server-core/src/plugin/inlineTrace/index.ts#L85-L98

If you are trying define data for specific fields and then return that data for fields queried in the extensions property of a response you have a couple of options:

apollo plugin + extensions

• Data for each field can be added using the extensions property of any relevant options objects
• An apollo plugin can then collect the data from extensions and attach them to the response in the willSendResponse hook. extensions data can either be collected using the info object to determine what fields where queried, or by collecting during execution with willResolveField.

apollo plugin + giraphql plugin

You can write a very simple giraphql plugin that defines custom options so your custom data is typed correctly, the plugin would then just stick that data in the extensions object.

The apollo plugin would work as described above. You could also handle the data aggregation during a query in the giraphql plugin, but would be more complex without much benefit.

There are some other options as well, but I think the first option described above is probably the easiest and cleanest way to implement something like this

[mmahalwy]

@hayes super random - what ORM do you typically use? We are using prisma atm and running into some challenges with migration rollbacks, etc 😓

[hayes]

I use prisma. It's the only decent type-safe option in my opinion. If migrations and rollbacks are what you are looking for, you could look into separate tooling for just migrations. I don't have any good recommendation, but prisma doesn't force you to use their migrations, it just makes it easier.

I would not use typeorm, mikroorm seems a little better, but haven't used it much.

The prisma plugin for giraphql (https://giraphql.com/plugins/prisma) makes using anything else not seem worth it for me.

[mmahalwy]

Why not use typeorm?

And what about sequelize? :)

[hayes]

I have a strong aversion to decorators, but also have heard from several people I trust that their experience with it has not been great when getting into more complex use cases.

I used to use sequelize, but it doesn't really have a good solution for type-safety

[mmahalwy]

Agreed - decorators can fire back.

Sequelize typing is getting better