Improve developer productivity with Ballerina, Choreo, and Asgardeo

The combination of Ballerina, Choreo, and Asgardeo offers a powerful and cohesive suite of tools for developing secure, cloud-native applications with robust integration capabilities. By using the Ballerina language for your projects, integrating Asgardeo for identity and access management, and utilizing Choreo for deploying Ballerina backend services, you can achieve sustainable developer productivity. This open-source stack aligns with modern architectural principles, accelerates development cycles, and ensures that applications are built with scalability, security, and seamless integration in mind.

What is Ballerina?

Ballerina is the only programming language specifically designed for integration, facilitating the development of cloud-native applications and seamless integrations. Traditional solutions to integration challenges have relied on restricted drag-and-drop tools, DSLs, or general-purpose programming languages that do not fully address the unique complexities of integration.

Explore ballerina: https://ballerina.io/

What is Choreo?

Choreo is an internal developer platform as a service (iPaaS) offered by WSO2, a leading open-source integration company. It enables organizations to effortlessly connect applications, data, and devices across cloud environments. By simplifying tedious and time-consuming workflows, Choreo allows you to focus on writing efficient code. This platform empowers businesses to accelerate digital transformation initiatives, streamline workflows, and enhance operational efficiency while ensuring scalability, security, and reliability.

Explore Choreo: https://choreo.dev/

What is Asgardeo?

With Asgardeo, identity management becomes straightforward. Asgardeo simplifies identity and access management for your application, eliminating the need to develop authentication components yourself. It handles both the frontend and backend aspects of authentication and authorization. For instance, you can use Asgardeo to register users and authenticate them based on their privileges.

Explore Asgardeo: https://wso2.com/asgardeo/

Why should you use Ballerina, Choreo and Asgardeo?

This stack ensures that applications are developed with scalability, security, and seamless integration in mind, while also accelerating development cycles and adhering to modern architectural principles. WSO2 has created the Ballerina language, Choreo, and Asgardeo to provide a comprehensive ecosystem for developers, enabling them to achieve their goals with minimal effort. For example, Asgardeo eliminates the need to develop user login and registration UIs by offering pre-built solutions. When hosting your backend on a different platform, managing access tokens and client IDs is crucial for securing API services. However, by integrating Asgardeo with Choreo and hosting your backend services within the WSO2 ecosystem, securing APIs becomes a seamless process. Choreo and Asgardeo work together using the same client ID, ensuring enhanced security without additional complexity.

Figure 1 illustrates the integration of Ballerina services, Asgardeo, and Choreo with a React application. In this setup, both the React application and Ballerina services are deployed on Choreo, with a MySQL database connected to the Ballerina backend.

Figure 1

1 — The Asgardeo React application initiates a request for an access token and user credentials. All user credentials and privileges are managed within the Asgardeo system.

2 — Receive the access token and user credentials,

3 — The React application forwards the access token to the Ballerina service via an HTTP request.

4 — The Ballerina service then executes MySQL queries to access the database.

5 — Data corresponding to the request is received.

6 — The Ballerina service sends an HTTP response to the React application.

For development and testing purposes, we can use in-memory storage with bal persist instead of a separate MySQL database. However, this is a temporary database (bal persist can also be used to access MySQL data). In this scenario, if you redeploy the backend, your in-memory database will reset. Persistence is essential for storing and retrieving data in integration solutions, enabling state management, fault tolerance, scalability, and data analysis. By persisting data, Ballerina applications can maintain state across interactions, recover from failures, scale horizontally, and analyze data for monitoring and reporting purposes, ensuring robust and reliable integration capabilities.

The Ballerina SQL connectors can also be used to construct this data service. However, doing so requires writing SQL queries to perform CRUD operations against the database servers. In contrast, using the `bal persist` functionality only requires defining the data model. The client object and record types are then automatically generated based on this model to communicate with the data store. If we use `bal persist`, Figure 1 should be updated to reflect the new architecture, as shown in Figure 2.

The `bal persist` command creates an immutable artifact containing the Ballerina code and its dependencies. This persistent artifact can be easily shared and deployed across different environments, ensuring consistent behavior. Additionally, `bal persist` enables optimizations such as ahead-of-time compilation and tree shaking, resulting in smaller file sizes and improved startup times. In contrast, the traditional method of running Ballerina code requires manual management of dependencies and configurations, which can be error-prone and less efficient, especially in complex applications or team environments.

Figure 2

We have created a Bookstore application as a demonstration project to help you understand the aforementioned architecture. This architecture integrates Ballerina services with Ballerina persist, React, and Asgardeo, with both the frontend and backend deployed on Choreo. Below, you will find the link to the GitHub repositories. You can fork them and test the application yourself. For comprehensive insights into deploying on Choreo and configuring Asgardeo, I recommend referring to [How to Create a Service in WSO2 Choreo | Choreo Community Call #1](https://www.youtube.com/watch?v=FX06RgpNUB4).

When utilizing Choreo for deploying your application, there’s no need for specialized expertise in CI/CD pipelines or Kubernetes, as Choreo seamlessly manages all aspects of the deployment process. Once you link your GitHub repository to Choreo, all you need to do is commit your code to GitHub. Choreo handles various deployment stages within a CI/CD pipeline, as illustrated in Figure 3. The Choreo free tier includes three levels: Setup, Development, and Production. Additionally, Choreo enterprise accounts feature a staging level, which serves as a pre-production environment.

Figure 3

You can see how Choreo makes it easier to deploy your application to enhance productivity. To manage your application’s builds and deployments effectively according to the git commit, follow these steps:

• Go to the Build tab from the right side navigation.
• Click on the Build tab to access the logs for each build, which correspond to your GitHub commits (Refer to Figure 4).
• Enable the Auto Deploy feature to automate the build and deployment process whenever you push a new commit to your GitHub repository.
• Alternatively, deploy manually at any time according to your preference.
• Monitor each commit from the Choreo dashboard associated with each build.

Figure 4

Choreo provides more options to test the deployed APIs. In the left side navigation under “Test”, it provides a user-friendly console to test each API (Figure 5). Alternatively, you can add your postman account to the Choreo or use the API Chat. Choreo API Chat is a tool that allows users to interact with APIs using natural language. It’s powered by the Generative Pre-trained Transformer (GPT) 3.5 large language model (LLM) from Azure OpenAI. With Choreo API Chat, you can try out APIs that are running or proxied via Choreo without the need for traditional methods or deep API specifications exploration.

Figure 5

Before testing the API from the console you need to publish your APIs. Go to the Lifecycle tab under Manage in the left-side navigation (Figure 6) and move to published. From this dashboard, you can change the state. There are six states as follows:

Created: APIs in this state are not ready for consumption. They are not visible to subscribers in the Developer Portal.

Pre-released: A prototype is created for early promotion and consumer testing. APIs can be deployed as prototypes to provide subscribers with an early implementation. Pre-released APIs are visible in the Developer Portal.

Published: APIs in this state are ready for subscribers to view and subscribe to via the Developer Portal. They are fully available for subscription.

Blocked: Access to the API is temporarily blocked. Runtime calls are halted, and the API is not visible in the Developer Portal.

Deprecated: When a newer version of an API is published, the old version is moved to this state. Existing subscribers can continue using it, but new subscriptions are disabled.

Retired: APIs in this state are no longer in use. They are unpublished and removed from the Developer Portal

Figure 6

In Choreo, adding a mount file serves a crucial purpose for your Docker containers. When deploying web applications, you need to mount runtime configurations and secrets as environment variables or file mounts. This ensures that your application behaves consistently across different environments. For web apps with a backend server, you can inject environment variables and mount files. This allows you to manage runtime configurations and secrets securely. If you’re hosting static web content (such as HTML, JS, CSS files), you can create a Web Application component and link it to a repository containing the required static assets. Select the Static Websites preset, and the files will be served as-is without triggering a build process. To add the mount file, go to “configs & secrets” tab under DevOps in the ride-side navigation (Figure 7). The Mount path should be “/usr/share/nginx/html/config.json”. You can use a .json file or a .js file.

Figure 7

After deploying both the frontend and backend in the Choreo using the same organization you need to subscribe to the backend APIs from the frontend.

• Go to the developer portal.
• Click on the “application” tab located on the right side.
• Create a new application.
• Navigate to the subscription tab from the left side navigation.
• From this dashboard (Figure 8), you can subscribe to the APIs that you deployed.

Figure 8

You can see the client id in the Credentials tab as customer key, which is the same client id in Asgardeo in the credential tab for both Sandbox and Production (Figure 9). When integrating Asgardeo as an external Identity Provider (IdP) with Choreo, you can configure them to use the same Client ID. Here’s how you can achieve this:

Prerequisites:

• Create an Asgardeo application by following the Asgardeo guide for registering a standard-based application.
• Find the well-known URL and the Client ID for your Asgardeo application. You can locate these details in the info tab of your Asgardeo application

Add theAsgardeo as an External IdP in Choreo:

• In the left navigation menu, click Settings.
• In the header, click the Organization list to access the organization-level settings page.
• On the Application Security tab, click Identity Providers, and then click + Identity Provider.
• Select Asgardeo as the Identity Provider.
• Provide a name and a description for the IdP.
• Enter the Well-Known URL of your Asgardeo instance (which you copied during the prerequisites).
• Leave the Apply to all environments checkbox selected. However, if you want to restrict the use of the external IdP to a certain environment, you can select them from the Environments list.
• Click Next to complete the configuration

Figure 9

Asgardeo provides a lot of features to manage users and authenticate your application (Figure 10). Asgardeo, a powerful identity and access management (IAM) solution, offers a comprehensive suite of features to enhance user management and streamline authentication for your applications. Whether you’re building web or mobile apps, Asgardeo provides seamless, secure, and private access experiences.

Figure 10

When configuring Asgardeo, you’ll need to adjust several settings to ensure smooth integration with your application in the Protocol Tab (Figure 11). Let’s delve into the essential configurations:

Client Credentials:

• Upon registering your application in Asgardeo, a client ID is generated as the application’s identifier.
• For traditional web applications, a client secret is also generated.
• These credentials are crucial for secure communication between your app and Asgardeo.

Allowed Grant Types:

• Determine how your application communicates with the token service. Common grant types include:
• Code: Used for executing the OAuth2 Authorization Code flow. After user authentication, the client receives an authorization code, which is then exchanged for an access token.
• Client Credentials: Used for executing the OAuth2 Client Credentials flow. Users are authenticated based on their credentials, and an access token is granted.
• Refresh Token: Allows obtaining a new access token without re-authenticating when the original token expires.
• Implicit: Not recommended due to security reasons. Directly provides the access token in the URL for clients without a back-channel.
• Password: Also not recommended. The client sends user credentials to obtain an access token.
• Organization Switch: Custom grant type for accessing suborganization APIs within Asgardeo.

Public Client:

• A public client cannot securely store client credentials.
• Use the authorization code grant type for public clients.
• Employ PKCE (Proof Key for Code Exchange) to mitigate code interception attacks.

Authorized Redirect URLs:

• Determine where Asgardeo redirects users after authentication and logout.
• An application can have multiple authorized redirect URLs.
• Ensure that the redirect_uri in login requests and post_logout_redirect_uri in logout requests match registered authorized redirect URLs.

Figure 11

Here you can get the source code from github:

Book store front end: https://github.com/JIshanRandika/book_store_front_end

Book store back end: https://github.com/JIshanRandika/book_store_back_end

To configure the Book store front end you need to Update configuration file src/config.json with your registered app details. (You will only have to paste in the client ID generated for the application you registered.)

{
    "clientID": "<ADD_CLIENT_ID_HERE>",
    "baseUrl": "https://api.asgardeo.io/t/<org_name>",
    "signInRedirectURL": "https://localhost:3000",
    "signOutRedirectURL": "https://localhost:3000",
    "scope": ["profile"]
}

And add the following configurations to .env in the root folder.

PORT=3000
HOST="localhost"
DISABLE_DEV_SERVER_HOST_CHECK=false
HTTPS=true

Then you can run the application using the command:

npm install && npm start