Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Doctrine and GraphQLite #687

Closed
tasselchof opened this issue May 15, 2024 · 1 comment
Closed

Doctrine and GraphQLite #687

tasselchof opened this issue May 15, 2024 · 1 comment

Comments

@tasselchof
Copy link

Guys, what is the best approach for using GraphQLite with Doctrine? I am encountering some issues. One issue I mentioned in #686, but I have others. For example, when I try to do an update mutation, the GraphQL resolver creates the Doctrine entity, and one of my methods should not be null by design:

public function getSomething(): AbstractSomething; 

Yet GraphQLite trying to resolve it which is causing this exception at this point (I am not copying an exception itself as it's obvious why it is happening):

#0 /home/dev/domains/api/vendor/thecodingmachine/graphqlite/src/Middlewares/SourceMethodResolver.php(45): Api\Entity\AbstractOtherThing-> getSometIng()

Generally, I'd appreciate what is the best way here to manage this: when you work with REST service you just hydrating an array to object, here in handler you have two objects that need to be merged in order to make an update (ofc GraphQLite creates not managed object).

Maybe it's a bad approach to map directly Doctrine entities? How do you are approaching this?

@oojacoboo
Copy link
Collaborator

Hey, firstly, I think you need to better present the issue you're facing here, as it's not entirely clear.

That said, it's my opinion that it's best to separate your input types from your domain/output types, at least for most of them - sharing some does make sense and is ideal, especially value objects. But, your input types will likely morph over time and your public API will rarely match your domain perfectly, nor should it. You should be designing your public API with separate principals from your domain.

As for the output types, these can typically be mapped to your domain, with the addition of extended types to handle public API particulars.

Some people are mapping fully to their domain models for both input and output, and I think this is probably perfectly fine for some APIs.

@thecodingmachine thecodingmachine locked and limited conversation to collaborators May 16, 2024
@oojacoboo oojacoboo converted this issue into discussion #688 May 16, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants