FaunaDB

The FQL Language Library provides tools to improve the developer experience when working with the Fauna Query Language (FQL). It includes:

1. A TypeScript library designed for providing auto-completion for FQL.
2. A standalone language server binary (LSP) for integration with IDEs and editors.

Fauna clusters are organized by replica types. Understanding the difference is critical for scaling and availability:

• Compute only replicas: These do not contain data. They act strictly as transaction coordinators to execute FQL queries.
• Data+Log replicas: These contain a full copy of the cluster dataset, participate in the global log, and process scan-based background tasks. They can also execute FQL queries.

When designing your topology, you can separate these concerns into different tiers.

Fauna provides two layers of access control:

• Role-Based Access Control (RBAC): For coarse-grained permissions.
• Attribute-Based Access Control (ABAC): For fine-grained, dynamic access rules.

It includes built-in user authentication and supports integration with third-party identity providers.

Fauna's CDC feature allows applications to react to data changes in real-time via two methods:

• Real-time event streams: Atomic push updates.
• Event feeds: On-demand batch pull updates.

These are useful for maintaining live application states, building collaborative features, or mirroring changes to external systems.

Every query in Fauna is a transaction, ensuring ACID compliance. Fauna uses the Calvin protocol to provide:

• Strict serializability for all read-write queries.
• Serializable isolation for read-only queries.

This consistency is maintained even across globally distributed region groups.

Fauna combines document flexibility with relational capabilities:

• Documents: Data is stored in JSON-like documents, removing the need for an ORM.
• Collections: Documents are organized into collections (similar to relational tables).
• Schema: Collections can specify document types to enforce structure, allowing for a transition from flexible to structured schemas.
• Relationships: Fauna supports first-class relationships between documents in different collections, enabling complex modeling without data duplication.

Fauna's database model supports isolation for multi-tenant applications and different deployment environments:

• Multi-tenancy: Create isolated child databases for each tenant with separate access controls and schemas.
• Environments: Create separate databases for staging and production to ensure changes in one do not affect others.

FSL allows you to manage database schema as code, enabling version control and CI/CD integration. You can define fields, computed fields, uniqueness constraints, and indexes.

Example FSL schema for a Customer collection:

collection Customer {
  name: String
  email: String
  address: {
    street: String
    city: String
    state: String
    postalCode: String
    country: String
  }

  compute cart: Order? = (customer => Order.byCustomerAndStatus(customer, 'cart').first())

  // Use a computed field to get the Set of Orders for a customer.
  compute orders: Set<Order> = ( customer => Order.byCustomer(customer))

  // Use a unique constraint to ensure no two customers have the same email.
  unique [.email]

  index byEmail {
    terms [.email]
  }
}

Use the following sbt commands to manage the development lifecycle:

• Compile all code and tests: sbt Test/compile
• Run all tests: sbt test (Note: This may take a long time)
• Run tests in a specific subproject (e.g., model): sbt model/test
• Run specific test Specs using a glob: sbt model/testOnly *DatabaseSpec
• Run a temporary database node: sbt runCore (Warning: This resets persisted state every time)

# Compile all code and tests
sbt Test/compile

# Run all tests
sbt test

# Run tests in a specific subproject
sbt model/test

# Run test Specs matching a glob
sbt model/testOnly *DatabaseSpec

# Run a temporary database node
sbt runCore