graphql

atticmaverick 2019-10-08T19:11:54.037400Z

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 ?

atticmaverick 2019-10-08T19:13:21.038100Z

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

hlship 2019-10-08T21:30:30.039Z

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

hlship 2019-10-08T21:31:02.039600Z

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.

hlship 2019-10-08T21:31:33.040200Z

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

hlship 2019-10-08T21:32:45.041600Z

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.

hlship 2019-10-08T21:33:52.042400Z

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

hlship 2019-10-08T21:34:58.043100Z

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).

hlship 2019-10-08T21:35:51.043700Z

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.

hlship 2019-10-08T21:36:31.044200Z

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

hlship 2019-10-08T21:37:25.045200Z

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.

atticmaverick 2019-10-08T22:20:24.046800Z

@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.

1šŸ’Æ
hlship 2019-10-08T22:35:12.048Z

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

orestis 2019-10-09T12:59:10.002Z

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

lxsli 2019-10-11T12:35:55.012Z

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 & šŸ‘

steveb8n 2019-10-08T22:47:31.048100Z

In that case, Iā€™m using it (Pedestal in Datomic Ions) and Iā€™m having a great experience with it as well šŸ™‚