Fork me on GitHub
#graphql
<
2019-10-08
>
atticmaverick19:10:54

im a little confused about input objects with lacinia. It would seem that you'd often want have an object and input-object with the same name and structure. But apparently you are not allowed to have conflicting names. What is the best way to handle something like this? just add something to the start of end of the object name? i.g. create_my_object ?

nenadalm04:10:24

I think that you can't have identical names because these names are in fact types all in one global namespace. I took inspiration on naming from here: https://blog.apollographql.com/designing-graphql-mutations-e09de826ed97 Usually when I am unsure how to name or structure something (I am pretty new to graphql) I am just looking for graphql articles on the subject and translating that to Lacinia.

atticmaverick19:10:21

is there a good reason why you cant have identical names? Maybe I am not understanding input-objects.

hlship21:10:30

As long as you are thinking in terms of REST, it will seem odd that input objects and schema objects are side-by-side.

hlship21:10:02

Because you are used to getting a copy of an object via a GET, modifying it in the client/browser, and then POST-ing it back to the URL to update it.

hlship21:10:33

Even though that style of REST doesn't have reasonable answers for issues like partial updates, or changes that span across entities.

hlship21:10:45

But if you link Input Objects to a specific use case of an update (not "update this order" but instead "change the quantity of the line item", for example), then the need for input objects mapping directly on top of schema objects starts to go away.

hlship21:10:52

It's an asymmetry that requires a greater coordination between client and server, but removes a lot of ambiguities present in the REST model.

hlship21:10:58

So don't think in terms of modifying the street address of your user object; think in terms of providing an AddressUpdate to a user (identified by id).

hlship21:10:51

And that gives you an opportunity to, for example, move a lot of validation and processing that normally would have to be done in the client to the server, behind the mutation.

hlship21:10:31

To be honest, our app is 99% query and 1% mutation, so we haven't had to explore all of that space.

hlship21:10:25

But again, the split between input object and schema object can work towards your favor, by allowing the input object to reflect the UI more closely, and the schema object to reflect your data store more closely, and the mutation in the middle doing the mapping.

atticmaverick22:10:24

@hlship i see. Thanks for the awesome response.I think I understand better now and it makes sense. And btw thanks for amazing work on lacinia and lacinia pedestal. It's been a pleasure to use. Really good stuff.

💯 4
hlship22:10:12

Thanks! Feedback is really helpful; as the (primary) author, all I see in the code is the broken, ugly stuff.

steveb8n22:10:31

In that case, I’m using it (Pedestal in Datomic Ions) and I’m having a great experience with it as well 🙂

orestis12:10:10

Hey, we're building our whole new platform on top of Lacinia. Works a treat! Much appreciated 😄

lxsli12:10:55

Also relying heavily on Lacinia, thank you very much. Updating recently cleared up a couple of niggles too, like having to put {} around the schema and remove & 👍