Backend functions

The app Fabapp generates runs in the browser of the person using it. Almost everything fits there: screens, data, login, AI, the catalog's integrations. Some tasks, however, cannot run in the browser, and that is what the backend function exists for.

What it is

A backend function is a piece of code that runs on the server, outside the app that appears on screen. The AI writes it when the request needs it: it creates the file functions/<name>.ts and registers the function in fab.functions.json. The app's screens call the function by name, wait for the response and show the result.

You do not need to write anything. The files are visible in the Code tab, in the functions folder.

When you need one

Three situations, and in all of them the answer is a backend function:

• an external API or feed blocked in the browser. Many sites do not let the browser read their data directly from another address (the lock is called CORS). The typical case is RSS feeds from news portals. The server has no such lock: the function fetches the content and hands it to the app;
• a secret key. Everything in the app can be read by whoever opens the app. An API key for a paid service can never go there. In the function, it stays on the server. To store the key, use the External APIs sub-tab, in the Integrations tab: it registers the API and the credential, and the function uses it by name;
• a calculation or a rule the app needs to trust. If the rule runs in the browser, the person can change it. Examples: applying a discount, reserving a spot "only if it is still free", validating something before saving.

To read and write the app's own data, or to use AI or the catalog's integrations, you do not need a function: the app already does that without one.

Plan

Backend functions are a Builder plan feature. On the Free and Starter plans:

• the assistant says the request needs code on the server and that this depends on the plan, and offers an alternative or the upgrade;
• if a new function gets written anyway, the platform removes it from the app at build time, because it would be refused on every call.

What the assistant must never promise is a "route" of the app itself, such as /api/rss: the app has no server of its own, and that address does not exist.

Who can call the function

Each function declares who may use it:

• any visitor, with no login (for example, a contact form on a public page);
• only people who signed in to the app (the default, when nothing is declared);
• only people with a role, such as administrator.

Say in the request who should be able to use it. Inside the function, the code has access to all of the app's data, without the access rules: that is why checking who is calling matters.

Cost

• writing the function is the AI's work and costs AI credits, like any building;
• each call counts as one app request;
• if the function uses AI, sends a notification or calls an integration, that usage consumes integration credits, just as it would outside of it.

Without Builder: the alternatives

If you do not want to change plans right now, you can solve the same problems with an intermediary of your own, outside Fabapp.

A flow of your own in n8n, Make or Pipedream

This is the recommended alternative. On these services you build a flow that starts at a webhook (an address that receives the call), does the server's work and returns the result.

1. on the service, create a flow with a webhook trigger;
2. in the flow, fetch the feed or call the API. If there is a secret key, it stays stored on the service, never in the app;
3. make the flow respond with the data, as JSON;
4. set the response to accept calls coming from your app's address (the service's CORS or allowed origins option). Without that, the browser blocks the response, exactly as it blocked the feed;
5. copy the webhook URL and paste it into the chat, asking: "fetch the data from this URL and show it on the news screen".

Things to watch:

• the flow's URL is visible in the app, and anyone can call it. Do not make the flow run anything that costs money or changes data without protection;
• the flow runs on your account at the service, with that plan's limits and price.

A public RSS conversion service

There are services on the internet that read an RSS feed and return the content ready for the browser. It works, but it is not ideal:

• it is a third party: if it goes down, your app's screen goes down with it;
• it usually has a usage limit, and the app can stop when the limit is hit;
• it sees everything your app reads through it.

Good for a prototype. For an app in use, prefer your own flow or the backend function.

What not to do

Never put a secret key in the app, neither by asking the AI nor by pasting it into the code. Everything in the app reaches the browser of the person using it, and anyone can read it. If the task needs a key, it needs a server: the backend function or an intermediary of your own.

How to know it worked

• the Code tab shows the file in functions/ and the function's entry in fab.functions.json;
• the screen that uses the function shows the result (the feed items, the calculated value);
• if the screen shows an error, tell the assistant what appears. The most common errors are the function requiring login from someone who did not sign in, and the account's plan not including functions.

Common problems

• The assistant said I need another plan. The account is on Free or Starter. Move to Builder or use one of the alternatives above;
• The screen says to log in when calling the function. The function is on the default (only people who signed in). If it should be open to visitors, ask for that in the chat;
• The account left Builder and the screen stopped. Functions stop running outside Builder. Rebuild the screen with one of the alternatives or go back to Builder;
• The n8n, Make or Pipedream flow responds, but the app shows nothing. It is almost always CORS: the flow has to allow calls coming from the app's address.