Doctrine and GraphQLite

[Maxim]

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?

[Jacob Thomason]

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.