Apps - Altogic Docs

In Altogic, you work on apps. An app is your workspace that packages all required design and configuration elements to run your backend app services. All application design elements are specified in snapshots, and all execution configurations are specified in environments.
Apps also hold additional data such as app parameters, external connection configurations, custom nodes, access groups, and application team settings.
Params
App parameters are name-value pairs that can be used in defining expressions and designing application services. You can define the default application parameters at the application level, and if needed, override them at the environment level.
Each app parameter has a name, type and value attribute. The type of the parameter can be either text, boolean, integer, decimal, date-time, email, link or identifier. 
For example, you can define the default value of a 3rd party API key (e.g., Twilio authentication token) as a text application parameter. 
Application parameters can be used across all snapshots of your app, and they are accessed through the expression editor while designing your services.
Authentication
Altogic supports authentication of your application users through third-party providers such as Google, Facebook, and Twitter. In the authentication settings of an application, you can specify the authentication providers that your application will use, the success and failure redirect URLs for your front-end, and the required client id and client secret for the OAuth flow.
By default, you need to provide a permanent user data model where Altogic will store authenticated user information such as the user name, email, profile picture, provider name, provider id, sign-up date, and last login date. Whenever a user of your application is authorized through one of the selected and configured authentication providers, Altogic creates or updates the user entry in the database and returns the user information, and if selected the session data to the success redirect URL in the "response" query string parameter.
Connections
External connections are the configuration settings to connect your apps to legacy email and database servers. These settings are primarily used by service nodes while designing your services. You can define the default external connections at the application level and, if needed, override them at the environment level.
Altogic currently supports SMTP (email) server external connections. In the future, we will be adding additional external connections, such as connections to legacy databases and their associated core nodes, so that you can use them in your service designs.
Access groups
Access groups are used to authorize specific endpoints of your application. When you create an endpoint, you can specify the list of access groups that are allowed to access the service exposed by the endpoint. For example, you can create access groups based on the functions of an organization such as sales, finance, HR, or production and allow only sales and/or finance teams to call endpoints that create, update or delete new sales entries.
To use access groups, sessions need to be enabled for the endpoints in consideration, and when creating the user session, the access group key needs to be provided.
Access group functionality is only valid for specific account plans. Please check your account plan whether you can use access groups or not.
Custom nodes
Custom nodes are your preconfigured "Call REST API Endpoint" nodes that you can use in your service designs. For example, if you will be repetitively using a "Call REST API Endpoint" node, you can define this node as a custom node and use it in your services without the need to configure each parameter of the node repetitively. 
If you believe other Altogic platform users can also utilize your custom nodes, you can submit your custom nodes to the marketplace so that other people can use them in their apps.
Team
Altogic allows collaborative application development with role-based access controls. You can add team members to applications with specific roles. Altogic provides built-in roles such as owner, admin, member and guest that can be used when adding new team members. You can also define custom roles with different permissions and assign these custom roles to your team members.
Roles
You can restrict access to specific views and actions to authorized users using role-based access control defined around roles and permissions. Roles can be created for various team member profiles and permissions to perform certain operations assigned to specific roles. Team members are assigned particular roles, and through these role assignments, they can or cannot perform certain actions.
Each role has a predefined number of permissions that grant or restrict access to specific views or actions. Permissions also have a hierarchy, meaning if top-level permission is disabled, child permissions cannot be enabled. For example, if you disable view snapshots for a particular role, then permission like view models, view services, etc., are automatically disabled.
Altogic provides 4 default roles that can be assigned to team members. These default roles cannot be deleted and modified; however, you can create a new custom role as a copy of a default role and customize its permissions.
Owner - The owner has all the permissions to manage an application. As its name implies owner role is assigned to the user who created the application. Therefore, there can be only one owner in an application.
Admin - Admins also have almost full permissions to manage an application, except they are not authorized to delete the app or transfer ownership. Only the user with the Owner role can delete the app or transfer its ownership to another app team member. 
Member - Member role provides permissions to design applications (create and update models, services, endpoints, tasks, queues, snapshots, etc.) but restricts administrative operations. For example, members cannot manage team members, add new team members, assign roles to a team member or create/update roles.
Guest - Team members with a guest role are only authorized to view application design elements and environments. Guest are only allowed to view snapshots, models, services, endpoints, tasks, message queues, and environments. They cannot create, update or delete these design elements. Even though guests are allowed to view environments, they are not authorized to view API keys of environments.
Role-based access control functionality is only valid for specific account plans. Please check your account plan whether you can use this functionality or not.
Members
Depending on your account plan, you can add team members to your applications so that you can work as a team in designing and managing your applications. In addition, you can assign a role to your team members that will allow access to specific views and actions to authorized users.
You can invite others to join you in developing your applications. All invitations of a particular application and their status can be viewed, and specific invitations can be resent or revoked. There is no limitation on the number of invitations that can be sent. You can send as many invitations as you like; however, the number of team members that can join your application by accepting an invitation is constrained by your account plan. If you have reached the maximum number of team members, any new person accepting an invitation will not join your team.
Only specific account plans allow adding team members to an application, and account plans limit the number of team members added to an application.

Must read - Previous

Key concepts

Snapshots

Last modified 8mo ago

Copy link

Contents