Kalix on high performance APIs and Microservices

Kalix is the first and only developer platform to enable back-end or full stack developers to create large-scale, high performance microservices and API's with no operations required.

The benefits of such a solution are endless - but the process of getting started with Kalix is far simpler than most beginners expect. 

Developing, deploying and managing Kalix services is carried out via a command line utility (CLI). This needs to be installed, and is the first step in the process. According to the Kalix website, the process carried out differed slightly, depending is users are operating vis MacOS, Linux or Windows. The insurections for each process can be found here:

Once the installation has been carried out, users create a Kalix account by opening a terminal window and executing the following command:

$ kalix auth login

This immediately opens up a browser window with the Kalix log in page.

Start creating a new account by clicking “Register” or through an existing google account.

When the account is created, users are taken to a screen that askes them authorise their CLI. They should opt for “Authorize” thereby giving the CLI permission to deploy and manage projects and services for your account.

The CLI will then tell them, “You are now logged in”.

Toe streamline the process further, Kalix services are organised into projects. To launch the first service, users need to create a project. They do this by using the line:

$ kalix project new my-project --region gcp-us-east1

This action creates an empty project called my-project created, and is selected as default when creating services.

Implementing a Kalix service is carried out via an available Kalix SDK. Users can build projects using the Java or Scala SDK or the TypeScript or JavaScript SDK.

To ensure userbility, the command line client gives several quickstart projects that users can start from. These quickstarts are:  

$ kalix quickstart list

Users can download the:  customer-registry-java project, create and launch it.

$ kalix quickstart download customer-registry-java

unzipping file  customer-registry/pom.xml

unzipping file  customer-registry/README.md

unzipping file  customer-registry/docker-compose.yml

unzipping file  customer-registry/src

Users should open the project in theirJava IDE and texamine protobuf service descriptors in src/main/proto along with the corresponding entity service implementation in src/main/java/customer/domain/Customer.java.

The Kalix team will deploy the project to Kalix initially by compiling the Java sources and packaging them as a docker image. The image is then published to docker hub where Kalix will fetch it to deploy and start the service.

To move to the next stage of the implementation, users then need to have the following installed and available on their PATH:

• A recent version of Docker
• JDK 11 or later
• A recent version of Apache Maven

They also need to make sure the docker is logged in to docker hub:

$ docker login

After that, they must update the “dockerImage” property in pom.xml replacing my-docker-repo with their  docker hub account name. This is where the artifact will be published.

Create package and publish the project using maven:

$ cd customer-registry

$ mvn deploy

This next stage will publish the docker image to docker hub and also deploy the published image to Kalix. The output will show:

[info] Deploying project to Kalix

[info] Executing `kalix service deploy customer-registry johanandren/customer-registry:1.0-SNAPSHOT-20220622124847`

[info] Done.

Users may also utilise the following command line to verify that the service has been deployed:

$ kalix service list

NAME                AGE   REPLICAS   STATUS   DESCRIPTION

customer-registry   82s   1          Ready

By default, a deployed service is not available to the public internet. The service then needs to be ‘exposed’ using kalix service expose customer-registry

So far, these instructions have created a sample for training set up purposes. It does not need to be published. But users can also create a proxy connection from their local machine, giving Kalix access to the service without exposing it to the internet. Here’s how: 

$ kalix service proxy customer-registry --grpcui

This command creates the proxy forwards port 8080 from the local machine to the running service. It enables Kalix to hit it with a client. On the command line Users can use curl for plain HTTP or grpcurl for gRPC calls, but the additional parameter --grpcui here gives us a nice web-UI to explore and do sample calls to Kalix running service.

Once this is done, all the available methods of the deployed service can be seen in the method drop-down, each allowing triggering a call directly from the user’s browser.

They should now be well set up to explore what is possible with Kalix.

 Here are a few starting points in the documentation:

• Exposing a service to the public internet
• Map the gRPC services to nice HTTP/json endpoints
• Publishing and subscribing events to a message broker
• Querying state using views
• Fine grained service access control using ACLs