Is this driver dead? about faunadb-swift

[evbruno]

Would you consider working with Grapqhl and FaunaDB or the FQL/driver is the "main argument" on adopting Fauna ?

[breathe]

@evbruno I would consider using the faunadb graphql api assuming that I can express all the interactions I need to support via faunadb auto-generated graphql api without having to overly contort my UI code ...

I've done some previous investigation of the faunadb graphql api -- but not used it yet for anything. A clean way to easily support upsert's seemed like it was missing when I last looked ... I want to have the simplest possible interface to the datastore from my UI -- as well as ensure that the client mutation model always loses as little information as possible. I want the application data layer to be easily organized in a way that will work well for declarative UI CRUD.

Upsert seems like a pretty convenient operation for simplifying the general programming model for CRUD for use in declarative UI while maintaining straightforward/clear ways to solve problems in a clean way (in my previous experiences) ... So I tend to look for 'how would upsert look' when evaluating a data management api ...

I see a partialUpdateMutation feature in preview now -- which might help ... --
https://docs.fauna.com/fauna/current/api/graphql/previews/partial_update_mutation

Feature seems interesting -- achieving the same with a postgres jsonb store requires either a whole bunch of hideous jsonb partial-update syntax or requires wrapping things carefully in serializable transactions to avoid read/write races -- so I appreciate this operation. But this op doesn't appear like it would directly support the ability for upsert to create an entity that doesn't yet exist when ID! is nil -- ? I think my ideal interface would consolidate create and update this way -- seems like it would be especially convenient when mutating embedded entities ...

If an embedded type is an array -- is there a way to do a partial update to add a new element to that array without sending a payload that contains all array elements?

I'd really like mutations (for say -- @Embedded types) to follow some form of consistent convention from the perspective of client code ...

upsert({some_collection, some_owner_id, { some_embedded_array: {prop1: "foo"}})
upsert({some_collection, some_owner_id: { some_embedded_array: {id: "foo", prop2: "bar"}})
upsert({some_collection, some_owner_id: { some_embedded_array: {id: "foo", prop1: "bar1"}})

// doc for some_owner_id: after running
{
...,
some_embedded_array: [
  {id: "something_autogenerated", prop1: "foo"},
  {id: "foo", prop2: "bar", prop1: "bar1"}
  ]
}

Not certain how many hoops are needed to achieve a client-side interface like this via the graphql api ...