Flowly
AI Enabled Visual Workflow Automation — From Trigger to Action.
A Zapier-style automation platform that lets you build event-driven workflows without writing a single line of code. Connect an incoming webhook to an email action, configure your flow in minutes, and let the platform handle the rest — automatically routing data from trigger to delivery every time an event fires.
Built for developers and non-technical users alike who want to automate repetitive tasks without stitching together APIs manually. The flow builder gives you a clear visual of what happens at each step, and the extensible integration model means new triggers and actions can be added as the platform grows.
AI AGENT AS TRIGGER
System Architecture
Flowly/How it works
A Zapier-style automation platform — connect a trigger to one or more actions, and an AI assistant helps draft them conversationally.
A Next.js 16 App Router app — dashboard, visual zap builder, AI-assisted action drafting, and settings. Talks to apps/api via axios, currently pointed at a hardcoded http://localhost:5001 across four different files rather than a single env-driven client.
- Client-rendered dashboard/builder sits behind Google sign-in
- AI chat helps users draft trigger → action chains conversationally
- Calls apps/api via axios — no centralized API client yet
- Dashboard list view client-polls apps/api rather than pushing updates
Data flow
Deployment shape
Engineering highlights
Flowly/Not just CRUD
Behind the "connect a trigger to an action" UI sits a real event-driven system — auth, idempotency, rate limiting, and crash-safe delivery, not just forms over a database.
Service-to-service auth
apps/web mints a short-lived JWT server-side from the verified NextAuth session — never from client input — and sends it as a Bearer token on every API call.
apps/api verifies the token and checks per-zap ownership before any read or write, instead of trusting a client-supplied user ID.
Idempotent action execution
An ActionExecution table with a unique constraint on (zapRunId, sortingOrder) is checked before every send.
Kafka's at-least-once redelivery can never double-send an email or double-create a GitHub issue on retry.
Rate limiting
A per-zap token bucket (30 req/min) guards the public webhook endpoint, plus a general per-user/IP limit on the API.
One noisy or misconfigured webhook source can't flood ZapRun inserts and starve every other user's automations.
Staged, ordered execution
A zap with N actions runs as N sequential Kafka round-trips, one per sortingOrder stage, with results merged into ZapRun.metadata as it goes.
Later steps can reference earlier results — e.g. a Gmail step reading {github.html_url} from a prior GitHub step — real chaining, not isolated single-shot actions.
Crash-safe delivery
Kafka offsets are committed manually, only after a stage finishes executing — not on receipt.
A worker that crashes mid-stage loses nothing: Kafka redelivers the message and the idempotency check makes the retry safe.
AI-assisted flow drafting
A conversational chat interface in apps/web helps users describe what they want in plain language and drafts the trigger → action config for them.
Lowers the barrier from 'I want to automate X' to a working zap, without hand-configuring every field.
Horizontally scalable by design
apps/worker runs as a named Kafka consumer group; apps/hook is a stateless insert-only service.
Both are built to scale by adding replicas — Kafka's own group rebalancing spreads partitions across workers with no custom coordination code.
Config-driven, multi-environment
A single centralized API client reads NEXT_PUBLIC_API_URL — no environment logic hardcoded into call sites.
Shipping a staging or prod environment is a config change, not a code change or redeploy of call sites.
Independently deployable pieces
apps/web ships to Vercel; the backend stack runs via docker-compose on a VM; Caddy fronts it as its own standalone compose project reachable only over localhost.
Any one piece — frontend, backend, or proxy — redeploys without coordinating with, or even being aware of, the others.
Flowly — shortcomings & fixes
12 areas identified — 3 resolved, 9 still open.
Recommended fix order: apps/hook auth → DLQ/retry cap → Kafka/kafka-ui network exposure → Observability → Kafka replication + multi-replica workers → Sweeper push-based handoff → DB indexing/replicas
POST /hooks/catch/:userId/:zapId accepts a userId straight from the URL path with no verification — anyone who can guess or enumerate a userId can insert a ZapRun against another user's zap. The apps/api JWT fix doesn't transfer here, since the caller is an arbitrary external system, not apps/web.
- FixPer-zap signing secret / HMAC verified on each webhook call
- FixReject requests whose signature doesn't match the zap's configured secret
- RiskCurrently the last unauthenticated write path into the system
Priority summary