Why I use FQL In Fauna DB

If you are not familiar with Fauna, it’s a database that is built for the modern serverless & JAM stack world. It is globally distributed, supports ACID transactions, has built in authentication, ABAC permissions model, and temporality. It is really quite interesting and powerful. For me it has replaced MongoDB and DynamoDB for my document stores.

If you have spent any time with it, you know you can do GraphQL and FQL to query the database. GraphQL allows for getting basic CRUD operations from the client. A schema is uploaded, and all the operations are instantly available to be used by your app.

FQL on the other hand is a custom functional query language for Fauna DB. It is functional in nature, and can be a little difficult to wrap your head around. But it is so much more powerful. While GraphQL handle CRUD operations, and is great client side, FQL is like it older sibling that can do a lot more. For example, creating databases, keys, roles and permissions, etc.

Because I want to use ABAC to handle what type of role a user account has and what they can do, that means I have to use FQL. So instead of splitting my code base and allowing CRUD operations to happen with GraphQL and administration actions, initialization of the database, and other tasks to happen in FQL. I might as well use it in both locations.

It is not without its quirks though. For example theIf query function requires three arguments, condition, statement to run when condition is true, statement to run when condition is false. So it is a If/Else statement, and can’t be just a If statement. Well it turns out it can, if you pass null to either condition.

If(
	Exists(Get(Document(Collection('user')))),
	null,
	Create(Collection('user', {
		data: {
			email: 'someone@example.com',
		}
	}))
)

In this example, If a user exists (any user), do nothing. Because the true statement is just null. If no user exists, create a user document in the users collection.

Another quirk are roles. They are called roles, as if you are assigning a logged in credential to a single resource. They sound as if someone in the user role can not also be a admin role. But in reality the admin role does not redefine all permissions someone in the user role has. It layers on top if they meet the conditions to be in both the user and the admin role. So it’s very strange that they are called roles and not access.