Quick thoughts about Fauna, FQL, and GraphQL

Disclaimer: I quickly put together these thoughts in free-style, sorry if they don’t make too much sense.

Remembering a chat that I had with Dhruv Gupta from Fauna, he asked me why wasn’t I using fauna as my only data store for my app. I just had some flashes of insights that I would like to quickly share in hopes that they will be a bit useful as feedback.

If fauna had a low-code solution alternative to FQL I could speed up my development and venture to dump more things.

I am very careful to add a field to Fauna since I have been burned before with making the schema dirty and therefor had to purge the database and start from scratch. So it seems like it’s easier to add fields than to remove. And when I modify I have the risk of screwing it up.

FQL is a convenient tool, but it is complicated to learn and verbose to read. To build sophisticated queries it is needed to nest a bunch of FQL commands with tons of parenthesis. On top of that there are no unit-tests for this so it’s a shoot-and-pray approach that it isn’t easy to handle. By no means I am thinking of a mutable language replacement. What would be cool is to have a kind of “Integromat.com” for fauna where I could jump in and build nodes that would immutably transform data. That would give me more peace of mind to do some complicated queries and would make it less tedious. Maybe if I was a full-time FQL developer it would be a breeze to build new user-defined-functions but in my case I am full stack and most of the time I’m working on JS and ReasonML. For quick things I don’t mind using FQL, but nested complexities are a drag in FQL.

If I had a low-code tool for fauna and a robust graphQL schema, for sure I would throw in way more data instead of using other third party databases like Monday.com in tandem.

Thanks for the feedback fellow Belgian :slight_smile:

At this point, FQL is quite verbose and we can certainly improve the error messages.
However, I’m surprised to get that feedback from someone who is used to ReasonML, most users like the functional approach once they get used to it and start composing queries. Many see it as daunting to the verbosity yet provide us with the feedback that once they learn how the most important functions fit together (Let/Map/Get/Match/Index/Paginate) it becomes easier. I personally find it easier to write a very complex query in FQL vs SQL. I experience FQL as much more powerful than many other query languages.

Is there any specific thing that you often bump into that makes you lose time? Your feedback on where you struggle is valuable to us, especially given that you are clearly used to functional languages.

I agree that it would definitely be cool to have such a visual tool, in fact… It’s on my wishlist of projects in my free-time since FaunaDB is a great fit for those kind of tools due to it’s temporality (easy to query what has changed).

That said, It’s interesting to see what
FQL was designed for:

  • Composable
  • Easily generated (this will come in handy for what you would like to see)
  • Powerful (complex conditional transactions)
  • Usable for User Defined Functions (not a separate language necessary for stored procedures)
  • Predictable and Scalable: in other words, good fit for pay-as-you-go and massive scale that means: A) that you can’t easily shoot yourself in the foot (hence the mandatory indexes/pagination)., you can’t accidentally write a Select * on a massive collection B) FQL is procedural which makes it easy to reason about the complexity and pricing whereas many other query languages are declarative. In that case, you never know how the query engine is going to optimise and that might even change when your data changes lading to unwelcome surprises.

We have seen that the goal of being able to generate is used already, community members are building their own libraries to query FaunaDB on top of FQL and it made it easy for us to develop the GraphQL capabilities. I assume if it continues like that, that we can expect to see people building visual things. Of course an integration with Integromat would be great as well.

2 Likes

Thanks for the response!
I agree, I rather work on FQL than SQL.

I think that if FQL would have pipes like ReasonML or other functional languages, it would flatten the function calling. Currently we see pyramid code similar with Node.js’ infamous “callback hell”.
Additionally, some improvement on dev tools would be very helpful. For example syntax highlighting, autocomplete, and a sandbox where we could experiment with UDFs without modifying the data (preview mode maybe).

A problem not only unique to Fauna but to all databases, is that migrations are cumbersome. For example when I have a field in a graphQL collection and later on I realize that I need to replace it. That means that I will need to write a script to migrate the current data to use the new field, and then deprecate the old field. That would involve using FQL, but how can I be sure that my FQL migration script will do the right thing once I run it if I can’t test it? That makes me anxious. Maybe there is a better process that I should follow and that I’m unaware of?

1 Like

Programs are trees, it’s not what is bad on callback hell. Callback hell is hell because of error handling, not because it’s a big tree.

1 Like

That’s great feedback, thanks!
Datomic had a great feature for that iirc which was exploiting their temporality (e.g. different from going back in history, you could create a ‘future’ database which you could throw away again iirc). Would be awesome of course but we don’t have anything like that I think at this point. The best you can do is set up a ‘dev’ database to verify that on and/or write your query in a sort of ‘dry-run’ modus where you could write a ‘UpdateOrUpdateInDryRun’ function if you are running in dry-run that takes the original docs and writes these updates to a temporary collection instead. I think that’s pretty feasible in FaunaDB though but it still leaves a small amount of anxiousness ;).

On the pipes! I’d loooove to have pipes, we already talked about that internally a few times so I’m sure that feedback will be taken into account when FQL progresses.

Also I stand corrected, I didn’t know our Fauna Data Manager had a ‘dryrun’ feature.

Let me know if that works for you and if not… why not :slight_smile:

1 Like

What low-code solutions are you using with other databases? (eg: Postgres, Dynamo, Mongo, etc)

I’ve struggled with that too. IMO better errors would fix that problem like @databrecht said.

I’m using Monday.com for low-code, as well as integromat

1 Like

thanks, I’ll take a look

I just found out about an upcoming product, Dgraph.io
looks like instead of a custom query language they use GraphQL declaratives similar to Prisma.
This approach is nice because the dev can keep everything in GraphQL instead of hopping back and forth between FQL and GraphQL.

DGraph is cool indeed, however this is not pure GraphQL so it’s a bit strange to say: 'instead of a custom query language. In fact this is a custom query language that looks like GraphQL since it’s non-standard GraphQL. For some that might be a problem (especially when they didn’t realise that upfront).

FaunaDB is in many ways different of course and did not start as a pure GraphQL database, it’s a massive scalable OLTP database that also offers GraphQL . We are working to make our GraphQL offering better while keeping it in the standard (we joined the GraphQL foundation to make sure we honour GraphQL :))

But there will probably always be a use for FQL since it was designed for a scalable database and to express complex transactions/security rules/functions :slight_smile: while GraphQL’s main goal will be querying. I think of it as: “hey I can use GraphQL and if I want I can open this window that gives me access to FQL to get full unlimited power”. :upside_down_face:

1 Like

DGraph, earlier this year, launched a native and graphQL spec compliant version . You can use regular GraphQL, and not just their version of “GraphQL±”.

Perhaps what @vasco3 means by “upcoming product” is just the new hosted service using native graphql, Slash GraphQL.

Until this point DGraph has not had a hosted service, nor has it been GraphQL spec compliant, like Brecht said.

DGraph is also a member of the GraphQL Foundation.

2 Likes

thanks for the correction

thanks, yes that’s what I meant

yeah I can see that could be an issue with Reason’s graphql_ppx since it needs the gql schema upfront

indeed, it’s very convenient to have FQL in any case

Ah, I thought it was still on there backlog, didn’t know they already released it, thanks :slight_smile:
Learning every day :upside_down_face: