Skip to content

Add GraphQLContext derive #329

@LegNeato

Description

@LegNeato
Member

Is your feature request related to a problem? Please describe.
Contexts have some boilerplate, you have to implement juniper::Context which is usually an empty marker trait. The error message when you don't isn't obvious, see #327.

Describe the solution you'd like
It might be good to have a #[derive(GraphQLContext) that does the boilerplate for you. It won't help the error message, but perhaps when people are copying and pasting or reading docs they will be less likely to miss it.

Activity

added
enhancementImprovement of existing features or bugfix
k::apiRelated to API (application interface)
on Mar 5, 2019
theduke

theduke commented on Mar 6, 2019

@theduke
Member

Actually, I think we could just deprecate the Context trait completely and remove the trait bound.

There is no real reason for it to be there.

theduke

theduke commented on Mar 6, 2019

@theduke
Member

I guess the only reason for it's existence would be that you can't use a type as context in the macros that isn't intended to be used as a context.

But that would produce compile time errors anyway once you actually construct the schema.

LegNeato

LegNeato commented on Mar 24, 2019

@LegNeato
MemberAuthor

Do we want to reserve the trait for future extensibility? If we remove the requirement and later need it for implementation specifics, it would be a breaking change.

davidpdrsn

davidpdrsn commented on Mar 31, 2019

@davidpdrsn
Contributor

@LegNeato what sort of future extensibility are you thinking of? I imagine adding methods to the trait would also be breaking change.

I'm also in favour of deprecating it.

theduke

theduke commented on May 16, 2019

@theduke
Member

I don't see a reason to ever add methods on context.
More state keeping or functionality would be added to the Executor.

There is a consideration with futures support though: we will probably need a Send + Sync + Clone bound on context!
With that in mind, we may want to add those constraints onto the Context trait instead of litterling them around the code everywhere.

davidpdrsn

davidpdrsn commented on May 18, 2019

@davidpdrsn
Contributor

I'm not that familiar with futures, but why Clone?

The app I'm working on has a context like this:

pub struct Context {
    db: DbCon,
    // more things...
}

Where DbCon is

pub struct DbCon(pub PooledConnection<ConnectionManager<PgConnection>>);

PooledConnection comes from r2d2 and is not Clone. So I can't easily make this context Clone.

I could instead store the connection pool itself in the context. The pool is Clone because it just wraps and Arc<SharedPool>. That feels like it would create a lot of churn on the pool though. If each db query would have to first get a new connection.

I also see that PgConnection from Diesel is also not Sync 🤔

theduke

theduke commented on May 18, 2019

@theduke
Member

but why Clone?

That's a necessary result from concurrency/parallelism.
We'll need to clone the Context often.

You could still use a single DB connection per query by wrapping it in Arc<Mutex<Connection>>.
(plus a convenience get_connection() method on the Context)
Note that the diesel connections are not Sync, but are Send.

But that would of course negate any benefit if most of your resolvers need the db.

davidpdrsn

davidpdrsn commented on May 18, 2019

@davidpdrsn
Contributor

Makes sense. Seems to still be early days for async in Diesel.

petoknm

petoknm commented on Jun 27, 2019

@petoknm
Contributor

I think we could use a trait alias for this in the future for async. Having an empty trait doesn't make much sense to me. I will try to make a PR to remove it.

theduke

theduke commented on Jun 27, 2019

@theduke
Member

@petoknm great that you want to help out, I would hold off on this for now though until I publish my async/await branch and we have a clearer picture of what will be needed.

petoknm

petoknm commented on Jun 27, 2019

@petoknm
Contributor

Cool, I didn't know that work on async support has already started.

added this to the 0.16.0 milestone on Jun 1, 2022
self-assigned this
on Jun 1, 2022
modified the milestones: 0.16.0, 0.17.0 on Oct 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

easyenhancementImprovement of existing features or bugfixk::apiRelated to API (application interface)

Type

No type

Projects

No projects

Relationships

None yet

    Development

    No branches or pull requests

      Participants

      @theduke@LegNeato@davidpdrsn@petoknm@tyranron

      Issue actions

        Add GraphQLContext derive · Issue #329 · graphql-rust/juniper