Wrapping Resolver w/ Graphback? about graphback HOT 9 CLOSED

There are two things here:

General practice

Generally, passing userID from the client doesn't seem to be secure and good practice. Encryption itself is guaranteed on transport level - https. Mentioned hashing can be the way to validate if the requested userID, matches the session user ID (however this might be a redundant operation)

Solution for schema modification

If there is any unknown motive to go with the encryption I think this could be done using Graphback plugins: https://graphback.dev/docs/plugins/create

Basically, in the plugin, we can alter schema as we want (and underlying resolvers as well).
In plugins, we can also wrap resolvers etc.

Alternative will be to wrap resolvers and schema in your application after they are returned from Graphback - this will work if we want this behavior for certain things that will require numerous if operations in the plugin itself (that tends to be generic)

To do that simply print out resolvers object to see structure. As for schema you can use GraphQL-Compose (plugins include graphql compose so it will be in your project anyway)

from graphback.

Sounds like XY problem. What we are trying to achieve with this hashing?

Graphback returns object containing resolvers so wrapping is trivial

from graphback.

Thanks for the reply.

Haven't heard about the XY problem... i got some readings to do.

What i want to achieve with the hashing/encryption.

• first endpoint GraphQL express : personnal data including a userID (i can query but i don't own)
• second endpoint : Additional Data on User (where the userID has to be encrypted)
• gateway where the stitching takes place.

Since i want to create as many endpoints with additional user data & encryption, my best bet is to :

• create the CRUD schema with Graphback.
• add the Cypher/Encryption plugin to the newly created schema with Resolvers/Query/Mutations.
• add the newly endoint to the gateway without the gateway knowing about encryption/hashing.

Since the queries would most likely be ;

User {
 userdatafield
  additionnalData {
    field1
    field2
  }
}

I thought that having a hash of the userID inside the graphback endpoint would decrease the request time. But i still want to have a encrypted userID inside the graphback endpoint to compute (possible but it doesn't matter if it is time consuming) the userID.

Since graphql-compose wrapResolver used a ObjectTC to do the wrapping, i was wondering if we could access the ObjectTC in the graphback component (graphbackmedata??)

from graphback.

hello,
I have knowledge of javascript ,nodejs,reactjs,expressjs, Mongodb but I haven't contributed to any open-source project before so I'm a beginner. I would like to contribute to this project.
how should I start can anyone suggest to me the way should I start contributing.

from graphback.

Hi @arnab15 - please use the discussions page to ask this question as your question is unrelated to this issue.

from graphback.

@craicoverflow thanks.

from graphback.

@wtrocki Thanks a lot for the detailled answer.

To follow the wrapping issue, there is no Resolvers attached to an ObjectType (via ObjectTypeComposer (OTC) functions) per se in the graphback GraphbackCoreMetadata object.

Fetching for the ObjectType Resolvers with
schemaComposer.getOTC(modelName),getResolvers() .
yields no attached resolvers.

Using wrapping functions of graphql-compose is therefore not possible.

Is it by design ?

from graphback.

We encourage developers to use good GraphQL application patterns. Meaning that we do not provide an executable schema that one cannot edit (black box). We split resolvers and schema so developers have the freedom to wrap things and control how they build schema using Apollo, GraphQL-Tools, GraphQL-js you name it.

If you looking into building plugin for your case then our plugins API have a dedicated place for dealing with resolvers:
https://graphback.dev/docs/plugins/create#createresolvers

There is no need to use schemaComposer apart from actual schema changes.

from graphback.

Ok Thanks a lot. The graphback plugin system seems adequate for various use cases .

from graphback.