Factories / Usage (Symfony)

[christian-lorenz]

Hi,
I'm struggling a little bit with the best way on how to mutate data.

Let's say, I've got an entity "Article" with like 20+ fields. And maybe some OneToMany stuff in there like "ArticleElement" or whatever.

The "normal" way to handle an edit would be:

1. loading the article by a Query in a gqlController action (getArticleById(int $id) :Article)
2. do some editing in the frontend
3. calling a mutation (updateArticle(int $id, string $title, DateTimeImmutable $publishDate, bool $isFeatured , ...) :Article)

Which looks very exhausting to me.

So I gave Factories a shot, mutating with an ArticleInput instead.
But it looks like I'm just moving that Problem to another (weird - as the factory has to be in the entity folder?) place, as now the factoryMethod needs to look like:
getArticle(int $id, string $title, ...) and I've got to set the data and do some business logic (throwing exceptions if article not found, uploading an image ...) already there before the Article-entity gets injected into the gqlController-mutation-action.

I'm quite sure, this can't be the right way.
This maybe just works on small brainless models (like the Location class in the examples).

So what would be the best way for this "real world" example? Would these Proxy classes help in that case?

[oojacoboo]

@christian-lorenz can you please re-state the actual issue here? It sounds like you're frustrated about something, but I'm not entirely sure what. Is it the verbosity? What's your goals here? What would you like to see or improve in your design?

The factories do not have to be in the Entity dir. We do not have ours there and wouldn't put them there either. We have a separate namespace for all our GraphQL logic, outside the Entity namespace.

[christian-lorenz]

well yes,

1. it's an overall design question how to approach / structure with graphQLite kinda large entity mutations with relations / inputTypes. Like using many "small" mutations and no InputTypes for them at all. Or ... well a different way ;)

2. I didn't get factories working outside of the namespace dir. Is there a configure option where / how graphql maps factories?

[oojacoboo]

1. When it comes to design, it's typically best to always use an input object, especially for larger mutations. Part of the reason for this is BC support. It's much easier to modify the requirements of an input type object, rather than multiple fields. Here is a resource with some really good patterns you might consider in your design: https://graphql-rules.com/.
   Specifically related to your question here is, https://graphql-rules.com/rules/mutation-input-arg
2. You may need to addTypeNamespace to your SchemaFactory config. I can't think of anything else off hand.

[hjerichen]

Just a reminder:
You don't need factories anymore when using the new annotated input types.

[christian-lorenz]

Hi thanks to your quick replies.
And I'm sorry using this channel for "advices", but I work at a very small IT (it was bigger before covid :( ...), in fact I'm the only senior dev left there. So I can't ask / plan with coworkers and need some "extern people".
The graphql-rules really help in changing my mindset, moving away from a simple CRUD.
I only worked once with graphql - but with a js backend. And as I liked the concept of it - the boilerplate to setup a simple query / mutation was super annoying. So I headed to graphqllite.

And as queries are as simple as I imagined with graphqlite, mutations still give me a headache on how to do them without rewriting stuff (the field descriptions) over and over again as they should already be known by the entities.

I will try the input types on Monday.

Regarding the factories, don't they have to be on the same namespace?
And is it ok to ask more questions like these here or is there a better channel?

[oojacoboo]

The factories do not have to be in the same namesapce. And, as @hjerichen said, they're not required for basic input types anymore. You can simply annotate them. This will save you a lot of boilerplate. This was something frequently complained about and was recently added in 4.2.0.

The purpose of the Discussions widget here in Github is questions like this and to keep them out of the issues. Hopefully more people will contribute going forward :)