This is a simple application to get country data from the World Bank API.

Countries can be filtered based on their:

1. Income Levels
2. Regions
3. Lending Types

To build world-bank-grpc, run the following make command:

make build

The binary will be compiled and placed in bin/world-bank-grpc.

You could also choose to install it for the user. Run the following make command:

make install

This places the binary in $GOPATH/bin/world-bank-grpc. If $GOPATH/bin is in your PATH already, you can simply run world-bank-grpc to use the application.

Depending on how you installed the application, you can run either bin/world-bank-grpc (if built) or world-bank-grpc (if installed).

To see available commands, run this command:

bin/world-bank-grpc --help

You can also view help for a sub-command by adding help after it. E.g.:

bin/world-bank-grpc client --help

To start the gRPC server, run this command:

bin/world-bank-grpc server

The server listens on port 50001 by default but this can be overridden by the PORT environment variable.

To view available client commands, run this:

bin/world-bank-grpc client --help

Example Usages:

1. List all regions

bin/world-bank-grpc client regions

2. List countries in Sub-Saharan Africa (ID: SSF)

bin/world-bank-grpc client countries --region SSF

3. List High Income (ID: HIC) countries with IBRD lending type (ID: IBD)

bin/world-bank-grpc client countries --lending-type IBD --income-level HIC

4. Get details about Nigeria

bin/world-bank-grpc client country --id NGA

We use mocking to test client-side logic without the overhead of connecting to a real server. Mocking enables users to write light-weight unit tests to check functionalities on client-side without invoking RPC calls to a server.

To create and update the mock, we use mockgen. Run this:

make mockgen

When tests have passed, the application is built and automatically deployed to Docker Hub.

Kubernetes manifests have been provided in kubernetes.

To make the service available to an external client from the cluster, the user can setup an Ingress to the provided service with the NGINX provider.

Optionally, the user can also provision TLS encryption. In this case, the client will have to be updated to trust the certificate authority (CA).

The benefit of having an event store will be to ensure that every change to the state of the application is captured as an event, and that the events are stored in the same sequence they were applied for the same lifetime as the application itself.

This application right now has immutable state, because the countries, regions, income levels and lending types do not change over the course of the application's lifetime.

However, if the application were to have mutable state, e.g. ability to edit countries etc, then the first step in integrating an event store is to define possible events. For example: DELETE_COUNTRY, ADD_INCOME_LEVEL, EDIT_REGION etc. Next step is to define the events object themselves, as well as a processor for each event.

Some key attributes of cloud-native applications can be found on TheNewStack.io. They include services managed through agile DevOps processes, centered around APIs for interaction, deployment on cloud infrastructure, etc.

This application successfully implements cloud native understanding.

12-factor app best practices include - storing config in the environment, one codebase tracked in version control, separate build and run stages, services exposed via port binding, logs as event streams, etc.

This application successfully implements 12 factor app best practices.