Skip to content

Commit

Permalink
docs(faq): cleanup stale FAQ entries (#4160)
Browse files Browse the repository at this point in the history
  • Loading branch information
alecthomas authored Jan 23, 2025
1 parent 4ed5000 commit c589e41
Showing 1 changed file with 0 additions and 40 deletions.
40 changes: 0 additions & 40 deletions docs/content/docs/help/faq.md
Original file line number Diff line number Diff line change
Expand Up @@ -35,43 +35,3 @@ for how to work around this limitation.
In its least abstract form, a module is a collection of verbs, and the resources (databases, queues, cron jobs, secrets, config, etc.) that those verbs rely on to operate. All resources are private to their owning module.

More abstractly, the separation of concerns between modules is largely subjective. You _can_ think of each module as largely analogous to a traditional service, so when asking where the division between modules is that could inform your decision. That said, the ease of deploying modules in FTL is designed to give you more flexibility in how you structure your code.

## How do I represent optional/nullable values?

FTL's type system includes support for optionals. In Go this is represented as `ftl.Option[T]`, in languages with first-class support for optionals such as Kotlin, FTL will leverage the native type system.

When FTL is mapping to JSON, optional values will be represented as `null`.

In Go specifically, pointers to values are not supported because pointers are semantically ambiguous and error prone. They can mean, variously: "this value may or may not be present", or "this value just happens to be a pointer", or "this value is a pointer because it's mutable"

Additionally pointers to builtin types are painful to use in Go because you can't obtain a reference to a literal.

## Why must requests/responses be data structures, can't they be arrays, etc.?

This is currently due to FTL relying on traditional [schema evolution](https://softwaremill.com/schema-evolution-protobuf-scalapb-fs2grpc/) for forwards/backwards compatibility - eg. changing a slice to a struct in a backward compatible way is not possible, as an existing deployed peer consuming the slice will fail if it suddenly changes to a data structure.

Eventually FTL will allow multiple versions of a verb to be simultaneously deployed, such that a version returning a slice can coexist temporarily with a version returning a struct. Once all peers have been updated to support the new type signature, the old version will be dropped.

## I can't export a Verb from a nested package inside a subdirectory of the module root. What do I do?

Verbs and types can only be exported from the top level of each module. You are welcome to put any helper code you'd like in a nested package/directory.

## What types are supported by FTL?

FTL supports the following types: `Int` (64-bit), `Float` (64-bit), `String`, `Bytes` (a byte array), `Bool`, `Time`, `Any` (a dynamic type), `Unit` (similar to "void"), arrays, maps, data structures, and constant enumerations. Each FTL type is mapped to a corresponding language-specific type. For example in Go `Float` is represented as `float64`, `Time` is represented by `time.Time`, and so on.

Note that currently (until [type widening](https://github.com/block/ftl/issues/1296) is implemented), external types are not supported.

## SQL errors on startup?

For example:

```bash
# ftl dev ~/src/ftl
info: Starting FTL with 1 controller(s)
ftl: error: ERROR: relation "fsm_executions" does not exist (SQLSTATE 42P01)
```

Run again with `ftl dev`. This usually indicates that your DB has an old schema.

This can occur when FTL has been upgraded with schema changes, making the database out of date. While in alpha we do not use schema migrations, so this won't occur once we hit a stable release.

0 comments on commit c589e41

Please sign in to comment.