var createP = client.query( q.Create( q.Collection('test'), { data: { testField: 'testValue' } } ) )
https://docs.fauna.com/fauna/current/drivers/javascript
Why those capitalized functions names .Create() and .Collection()? Also the fact that you have to pass around that q. Maybe that could be changed with: let { Create, Collection} = q
I care about the syntax of the libraries I use and Fauna seems clumsy.
But it's just sugar, I basically write it the way you mentioned, by deconstructing `q`. See https://github.com/Vadorequest/rwa-faunadb-reaflow-nextjs-ma...
The snippet in the grandparent post is JavaScript; is there an ORM or other library that has an example of an idiomatic JS or Typescript syntax that either of you would prefer?
Yeah, I do that all the time. It makes FQL code much cleaner.
I mean, isn't Fauna more directly comparable to Dynamo than Aurora?
Dynamo is indeed closer and there is a comparison here: https://fauna.com/blog/comparing-fauna-and-dynamodb-pricing-...
Where does the $1,050 come from?
Even if scale to zero is eventually supported, some minimum capacity will still be required to avoid cold start latency.
I understand that companies with enormous data sets can't afford to use joins at all, but I've yet to work somewhere where a properly indexed RDS/Aurora db wasn't able to make use of them just fine. Almost all of my queries beyond simple CRUD reads rely heavily on inner/right joins, and last time I spoke with someone at Fauna, they said that their query logic wouldn't be able to support what my query was doing.
I'm rooting for DB alternatives, but unless a new contender can be as unconstrained as an RDBMS, it's very hard to move.
You can achieve the same thing, although maybe not in the way you're expecting since FQL is not SQL.
See this introduction I wrote about joins in Fauna:
https://fauna.com/blog/core-fql-concepts-part-5-joins#replic...
> Fauna is programmable, with a rich standard library of functions. It can run transactional business computation adjacent to the data and let the developer compose computational logic in a maintainable way.
I appreciate programming in PL/SQL isn't great or anything, but it exists and it works and I've used it to great effect in projects where the client pretty much only ever works with stored procedures, and I thereby don't really understand if they are actually different in fundamental ability here or if they merely have a better language (which I would even then question, as I have totally taken advantage of the ability to program PostgreSQL stored procedures in PL/Python).
My read on this is "if you already use postgres don't migrate, but if you want to use us for a new application that is a good fit."
I hate that it's this way but it is: all software-aware companies I've worked for won't look at something they can't attach at least a clunky, slow as all hell SQL interface too. And any overhead to do that doesn't make business sense.
