This is an overview of some key things that will help when you're getting started with Comnoco.
How Comnoco Works
Comnoco's primary use is to create functions that can then be called by other systems, usually by publishing them as APIs or triggering from a Webhook.
You can re-use functions within your work instead of publishing them. This allows you to build re-useable bits of functionality that can be maintained in a central place to avoid repetition. When building with Comnoco you should break everything down into manageable chunks of work (functions).
Published functions are secure (unless you opt to make them unsecure) and scalable. They run on our scalable infrastructure as a no-code Function as a Service (FaaS).
Every user must be a member of one or more teams. When you first log in you are automatically assigned to a new team with just you in it. It is given a random name that you can change.
Teams can contain multiple users and Workspaces, you can either invite others to your team or be invited to another team.
Your user profile can be edited to update your name, email and security settings.
You can choose to sign in with a social profile (e.g. Google or Github). If you have signed up with an email and password, you can link a social profile to your same account as long as it shares the email address you signed up with.
❗️ We strongly recommend you set up Two Factor Authentication
Within a team you can have one or more Workspaces which are are virtual environments for developing and running processes. You can think of them as areas to organise your work into projects and there is no limit on the number of Workspaces you can have.
Workspaces act as isolated units so they are ring-fenced from one another and can't share functions.
🛣️ Our roadmap includes the ability to have multiple users working within the same workspace but for now it is locked to one user working on a workspace at any time.
Within teams, as well as regular users you can also set up Service Users.
Service users are for other systems to connect to Comnoco and can have API keys assigned to them. These Service users allow you to secure the processes you expose from Comnoco.
There are three basic file types in Comnoco.
1. Trigger Files
A Trigger file allows you to expose:
- A function as a Webhook
- A set of functions as a REST API. You don't have to expose a set though, you could choose to simply expose a single function as an API.
In addition to exposing the function trigger files also define the security that will be applied to the trigger.
🛣️ On our roadmap (future functionality) is the ability to run a trigger on a schedule.
2. Logix Files
Logix files hold your business logic broken down into Functions. They are the heart of Comnoco.
Within each file there are two places you can create functions:
- Public Functions - This is where you create functions that you want to make available for using elsewhere (another logix file or a trigger).
- Private Functions - Here you can add functions that are only available to other functions within the same logix file.
There are multiple types of Functions
- Standard Function - This is a basic function type that can be called from other functions.
- API Function - This is a function that has extra pre-defined input and output parameters specifically for use when wanting to publish a function as an API.
- Webhook Receiver - This is a function that has extra pre-defined input and output parameters specifically for use when wanting to use a function to receive data from a webhook.
3. Template Files
Template files allow you to build complex dynamic, data driven templates with embedded business logic.
Use these to build your transactional business communications (Customer Communications Management - CCM).
Templates are split into:
- Email Templates - For visually building responsive HTML emails based on top of MJML.
🛣️ Coming soon, on the roadmap:
- Document Templates - For visually building complex business documents as PDFs.
- HTML & Text Templates - For building text based templates visually.
The Comnoco Tree & Blocks
All file types in Comnoco are based on a Tree view of Blocks.
Blocks represent functionality and/or data.
The tree shows the relationship between the different blocks and how they flow together to achieve a specific outcome. Each block represents a node on the tree, with child nodes representing the inputs and outputs of the block, as well as any sub-blocks that are nested within it.
This allows you to easily visualize the process and make changes as necessary, without needing to write any code. As you add, remove, or rearrange blocks, the tree view updates in real-time to reflect the changes and ensure that your process remains organized and easy to follow.
The tree view represents a timeline starting at the top root node, moving through the child nodes in a top-down manner, and flowing out through the leaf nodes as it goes. It's kind of like a flow chart but more compact and organised. In Comnoco we refer to tree nodes as Slots.
Constant, Parameter and Variable Slots
At the top of each Logix file you will find a slot for Constants.
Constants are values that do not change during the execution of a function (process). They are for you to assign fixed values that you can use throughout your file.
At the top of each Function you will find slots for the below. The combination of these defines your function signature:
- Input Parameters - For passing values into functions each time they are run.
- Variables - Values that can change during the execution of your function. They are usually assigned a value at some point during the run and can be modified as the function runs.
- Output Parameters - For passing values back to the calling entity when a function completes.
In a Comnoco tree, all slots are typed.
Typed slots represent a specific data type or object. For example, a slot might represent a text string, a number, a date, or a list of items. These slots are "typed" because they are associated with a particular data type and have specific behaviors and properties that are unique to that type.
When building a Comnoco process, using typed slots helps to ensure that the correct data types are being used throughout the process, which helps to prevent errors and improves the overall performance of the process.
These typed slots ensure that Comnoco can guide you as to what is possible on any particular slot via the add point.
By default your workspaces remain private and unexposed until you publish them. Publishing them takes a snapshot and places it in a live environment.
This way you can develop and publish changes only when you are ready.
🛣️ Coming soon, on the roadmap: We will allow multiple published environments (e.g. Staging, UAT, Production)
Within each workspace you can go to the status screen which will show you your running Triggers. It also shows you details of the activity on each trigger and allows you to access generated OpenAPI definitions and logs from each event.
Secrets and Environment Variables
Each workspace and published environment can have its own set of secrets, which might include OAuth2 credentials, API keys, or other sensitive information that needs to be kept secure. Additionally, workspaces can also have environment variables, which are values that can be used by the processes within that workspace.
For each secret or environment variable that you define in a workspace you can set a corresponding value for the workspaces published environment(s).
In the Comnoco system, secrets are stored securely using advanced encryption techniques to protect them from unauthorized access. The encrypted secrets are then stored in a separate location that is designed specifically for storing sensitive information, and access to this location is strictly controlled and monitored to prevent any unauthorized access. This helps to ensure that your secrets remain safe and secure at all times, and can only be accessed by authorized users or service users who have the necessary permissions. Once created, a normal user can't see a secret though users can update secrets with new values.
❗️ Please note that secrets are held against a workspace so any secrets or Oauth2 credentials that you set up in a workspace can also be used (but not read) by any team members that also have access.
Comnoco excels at connecting systems, see our connectors guide for details of how easy it is to connect to other APIs such as OpenAI, Airtable or Supabase.
Exporting, Importing and Version Control
In the Comnoco system, users can export their no-code processes and workspaces in JSON and ZIP file formats, respectively. This allows users to easily share their work with others or save a copy of their work for backup purposes.
In addition, these exported files can be used with version control systems like Git to help manage changes to the code and maintain a history of revisions. When importing these files back into the system, users can review the changes and decide which ones to keep. This makes it easy for teams to collaborate on no-code projects and maintain a consistent development workflow, while also providing a way to backup and restore their workspaces.