Deno edge functions

Deno is a JavaScript and TypeScript runtime that executes TypeScript directly, uses web standard interfaces such as fetch and Web Crypto rather than Node's own, and requires permissions to be granted explicitly for network, file and environment access. Supabase runs its edge functions on it: you write a handler, deploy it to the project, and it executes with the project's service credentials next to the database. In practice it is where the code goes that must not run in a browser.

How we use it

360nutri has three of them and they carry the product. One takes an uploaded photograph of a meal and calls a vision model to return calories, protein, carbohydrate, fat, fibre, sugar, sodium, a detected ingredient list, a food category and the model's own confidence score, which the user confirms before anything is written to their log. A second sends the user's profile and recent meals back to the model to produce meal ideas that fit their calorie target, dietary preferences and allergens. A third writes recipes for the library and is called hourly from the database itself, a pattern covered on the queues and scheduled work page.

The reason all three are functions rather than browser code is the model key. A key shipped in a bundle is a key published on the internet, and the bill for that arrives quickly.

What it costs you

There is a cold start, which is small but real, and it lands on exactly the request a user is already waiting on. Compatibility is the bigger practical issue: npm packages can be imported, but the support is not complete, and anything that expects Node's file system, process object or a native addon will not run. Check the specific client library before designing around it rather than after.

Execution has a wall clock limit, and a vision model call takes seconds. A function that calls a model, waits, writes a row and then does one more thing is a function operating near its ceiling, and the failure mode is a timeout on the slowest and most interesting requests. Anything on that path wants to be split or moved off the request entirely.

Observability is whatever the project dashboard offers. Tying one bad analysis to one invocation involves more scrolling than tooling, and there is no local log to grep.

The deepest cost is coupling. Functions are deployed into a Supabase project and share its fate. 360nutri's front end still loads today: the sign-in card paints, you type an email, and nothing happens, because the project host it talks to no longer resolves in DNS. Every function went with it. We wrote that up in what breaks first when you stop maintaining a side project, because it is the ordinary way small products die rather than an unusual accident.

When we would choose something else

If the data does not already live in a Supabase database, Workers is the runtime we would pick: better tooling, more bindings, and no dependence on one project's continued existence. The reverse also holds. When the rows are in Supabase Postgres and row level security is doing the authorisation, a function sitting next to that database beats a Worker reaching across the internet to it, and the Supabase page covers where that boundary usually falls. For work with no user waiting, a scheduled job on a host you already run is duller and easier to see into.