Lesson 5 / 97 min read

Actions: server-side work (devany.fn)

Reaching outside, using a secret key, and receiving notifications from outside — without writing code.

A generated app runs in the browser and can never call out — a deliberate boundary: an API key placed in the page is a leaked key. Work that needs the outside world happens in ACTIONS: the owner describes it, the platform writes a validatable recipe, and the app calls it by name.

The path of an action

Describe

"Get a tracking number from the courier API"

Recipe is drafted

The model writes the steps

Machine validates

Secret leaks, hosts, caps

You approve

It won't run unapproved

Calling it from the app

// Eylem sunucuda koşar; anahtar tarayıcıya hiç gelmez.
try {
  const out = await devany.fn('fetch_tracking', { orderId: order.id });
  show(out.trackingNo);
} catch (e) {
  // 'no_such_action'  → sahip henüz tanımlamadı
  // 'action_disabled' → tanımlı ama kapalı
  // 'rate_limited'    → saatlik tavan doldu
  note('Takip numarası şu an alınamadı.');
}

With no action defined the screen must still work: hide the capability or show a calm note.

Arbitrary code vs a validatable recipe

Writing server code

Asks non-coders to write code
Sandbox escape, infinite loops, secret leaks
A deploy per function
A mistake ships as working-but-wrong code

DevAny actions

You describe it, then read and approve
No eval; steps and duration are capped
No deploy — one interpreter, at the edge
A mistake is caught by the validator, on screen

Receiving a notification (webhook)

1
Mark the action inbound
Turn the option on when saving; a secret address unique to that action is generated.
2
Give the address to the other side
The payment provider, form service or automation POSTs there. The address is shown only once.
3
The body becomes the input
The incoming JSON is the recipe's input; query parameters arrive under `query`.
4
Revoking is one tap
Disabling the action kills the address instantly; a leaked address is limited to that one action.

Tasks that run on their own

1
Define an action
What gets scheduled is not arbitrary code but an action YOU approved — the scheduler opens no new risk.
2
Pick the frequency and time
Hourly, daily, weekly or monthly. No cron expression; your timezone is respected, daylight saving included.
3
See the next run
The dashboard shows each task's next run, how many times it has run, and the last outcome.
4
Typical uses
A morning summary email, a nightly inventory sync, a weekly report, an invoice reminder on the 1st.

The steps a recipe can use

	What it does
http	A request to an allowed address (secrets allowed)
db.list / db.put / db.remove	The app's own collections
mail	Transactional email (if email is on)
set / if / return	Compute, branch, result
loops	NONE — runtime is deliberately bounded

Key takeaways

The app can't call out; an action does it server-side on its behalf.
You don't write code — a recipe is drafted, validated and enabled by your approval.
Secrets are injected only into the outbound request; they never return to the browser.
You can schedule an action — no cron expression, in your own timezone.