Appearance
Programming Guide
The Programming Guide provides technical reference material for Creators building custom behavior in ioLoop Projects. Use it when working with Page Flow, Cloud Flow, or the ioLoop Client API and Server API.
The guide is organized by where code executes:
- Frontend Programming covers browser-side interactions in Pages and Forms.
- Backend Programming covers server-side processing through Cloud Flow and related Project capabilities.
For explanations of where to find these features in the Project Editor and how to configure them, use the Project Editor documentation. The Programming Guide focuses on the blocks and APIs available when implementing their behavior.
Frontend Programming
Frontend programming runs in the visitor's browser as part of a Project Page or Form. It is used to respond to events, read or update supported Page content, work with Forms and Widgets, access permitted Project data, and coordinate with server-side workflows.
| Reference | What You Will Find |
|---|---|
| Frontend Programming Overview | How browser-side programming fits into ioLoop and when to use Page Flow or the Client API. |
| Page Flow Blocks | Reference for ioLoop-specific visual Page Flow blocks and their configuration. |
| Client API | Reference for browser-side ioLoop API functions available to supported frontend code. |
For a product and editor-oriented introduction, see Page Flow.
Backend Programming
Backend programming runs on the server through Cloud Flow. It is used for trusted processing, business rules, database operations, integrations, file handling, web hooks, and supported background or AI Agent workflows.
| Reference | What You Will Find |
|---|---|
| Backend Programming Overview | How server-side programming fits into ioLoop and when to use Cloud Flow or the Server API. |
| Cloud Flow Blocks | Reference for ioLoop-specific visual Cloud Flow blocks and their configuration. |
| Server API | Reference for server-side ioLoop API functions available to supported backend code. |
For a product and editor-oriented introduction, see Cloud Flow.
Choosing Frontend or Backend
| Requirement | Start With |
|---|---|
| Respond to a Button click or Page event | Frontend Page Flow |
| Validate input and show immediate feedback | Frontend Page Flow |
| Update Page Elements or Widgets | Frontend Page Flow or Client API |
| Access Project data from the browser, subject to access rules | Supported frontend data blocks or Client API |
| Enforce protected authorization or business rules | Backend Cloud Flow |
| Use private credentials or perform trusted integration operations | Backend Cloud Flow or Server API |
| Process a server-side web hook or background task | Backend Cloud Flow, where configured |
A Project often uses both. For example, Page Flow can collect a Form's values and initiate Cloud Flow processing. Cloud Flow performs the protected operation and returns a result; Page Flow then updates the interface.
Frontend logic is not a security boundary. Browser-side values and checks should not be trusted as proof of authorization. Apply Database permissions and server-side validation where required.
Blocks and APIs
Both programming areas provide two complementary kinds of reference:
- Block references document ioLoop-specific visual programming blocks, including their available inputs and behavior. The generated references do not cover standard Blockly blocks.
- API references document functions available to supported custom code in the relevant execution environment.
Use blocks when the visual workflow expresses the operation clearly. Use supported custom code and APIs when the workflow needs logic that is more convenient to express in code.
The exact parameters, results, and supported operations are documented in the linked reference pages. Do not assume that a Client API function is available on the server, or that a Server API function is available in the browser.
Where to Go Next
Start with the Frontend Programming Overview for Page and Form behavior, or the Backend Programming Overview for trusted server-side workflows. Then open the appropriate block or API reference while implementing the workflow.