FLXBL, being a Backend-as-a-Service system does not contain any AI features, and that is by design.
Our product delivers predictable, complex engineering features, and we don't see any kind of AI features as a fit in the core of the product itself.
However, we are definitely aware of AI usage and many different use cases where AI and AI-assisted coding can be extremely helpful.
That's why our CLI is what we like to call AI friendly.
The CLI is built to be driven by agents. Every mutating command follows the same contract:
--json every command emits a stable JSON envelope on stdout. Errors emit { code, message, details?, exitCode } to stderr.
--stdin any command that takes a --data, --file, or --items argument also accepts the payload on stdin, so agents don't need a filesystem:
echo '{"name":"Widget","price":9.99}' | flxbl entity create Product --stdin --json
How do you handle changes over time, like migrations and keeping generated clients in sync?
@karimbenkeroum Great question!
We currently look at migrations as breaking and non-breaking.
The non-breaking migrations are generally create/safe field type changes.
The breaking ones are the ones where you might lose a portion of your data.
Schemas are versioned, which means that you can freely move from version X to Y to Z to X or B, or whatever else.
The generated clients can be guarded by the CLI - https://www.npmjs.com/package/@flxbl-dev/cli
which you can run in "watch"/dev mode, which pools constantly for changes.
There's also a generated metadata json file that informs you of the current active version.
Thank you!
Best of luck Marko, product looks very interesting. We currently have implemented in-house GraphQL server for Crana.AI but will keep an eye on this as it might help us on some smaller projects.
@vladdy_dotcom Thank you very much Vlad!