Architecture
This section explains what happens between the moment you save a route and the moment somebody calls it. You don't need to read it to use Fluxify — but if you are self-hosting, tuning performance, or just curious why your API is fast, this is the map.
The short version
Fluxify does not interpret your flowchart on every request. It translates your flowchart into JavaScript once, when you save it, and then runs that JavaScript directly for every request afterwards.
Think of the difference between a translator standing next to you repeating every sentence, and simply learning the language. The first has to do the work again for every sentence. The second did the work once.
The two halves
Fluxify splits into two halves that do very different jobs. Understanding this split explains most of the deployment choices you'll make.
| Control plane | Request workers | |
|---|---|---|
| What it does | Where you build things | Where your API runs |
| Who talks to it | You and your team | Your users |
| Touches the database | Yes | Never |
| How you scale it | One is usually plenty | Add more as traffic grows |
| If it goes down | You can't edit — your API keeps serving | That API stops responding |
Why the workers never touch the database
Workers receive your routes already translated into code. They have no reason to read your database, so they are never given the credentials to. A bug in your API logic cannot reach the tables that store your account, your projects, or anyone else's work.
Where to go next
- Request Lifecycle — the full journey of a route, from the moment you hit Save to the moment a user gets a response.
- The Orchestrator — what decides how many workers exist, and why it is a loop rather than a command.
- Performance — what the translation step actually buys you, with measured numbers.
- Deployments — how to run all of this yourself.