In the previous proxy step, we have set up a light-proxy instance to mimic the transactions service in case transactions service is not built on top of light-4j and doesn’t have any cross-cutting concerns addressed. Given there are several distributed services in the same application, monitoring these services on production will be a challenge. In this section, we are going to explore the distributed tracing with Jaeger. We will also support Skywalking tracer from Apache and will implement it if someone interested. Read More »

In the previous step, we have configured the light-router instance to route traffic to the microservices we have built. It is recommended that each application has a router instance or a cluster of instances. In this sense, the light-router is designed for consumers. For an enterprise, services might be built with different technology stack, and it is not feasible to rewrite all of them in microservices. When you build a new application, chances are you need to leverage some of the legacy APIs. Read More »

In the previous router step, we have exposed the services to the Internet through https://ob.lightapi.net subdomain. Eventually, the services will be consumed by other services, single page applications or mobile applications. In this step, we are going to build a consumer application using React and deploy it to the light-router instance on the portal as another virtual host. Environment Preparation React App with long-lived token React App with cookies Login View of Light-OAuth2 Light-OAuth2 Config and Start Light-router proxy and virtual host Debug light-router Test Cloud Deployment Localhost Hot Reload Node Environment Variable Leverage Remote Services SaaS OAuth 2. Read More »

In the previous step, we have created a docker-compose to start all the services on the test2 server in the test cloud. In this step, we are going to add configuration to the light-portal router instance to enable routing requests to these services from the Internet. We have already got the router instance running on the portal server, and the configuration can be found at https://github.com/networknt/light-config-test/tree/master/light-router/test-portal For this configuration, it is in the networknt organization, not the open-banking organization on the github. Read More »

In the previous step, we have enabled security and dockerize the services. In this section, we are going to create a docker-compose to start all services together with externalized configuration. We will also register the services to the Consul cluster in the test cloud so that the client can discover them. We are going to use another repository for the deployment configuration, and it can be accessed at https://github.com/open-banking/light-config-test First, let’s create a service folder and a docker-compose. Read More »

For the real open-banking application, each user should only be allowed to access his/her own account information. This is controlled by the access token he/she can get from the OAuth 2.0 authorization code grant flow. In the previous hardcoded step, we have all four microservices implemented based on two userIds: stevehu and ericbroda. Before we have the single page UI application implemented to interact with the light-oauth2 to get the JWT token, we are going to use two long-lived tokens for testing. Read More »

The first step to demo the services is to implement with some hard-coded logic on the generated project. In the future, we can hook the service with a database or in-memory data grid or make the service an event consumer to update the local no-SQL database. In this step, we have updated the handler logic to have a hard-coded userId stevehu and use it to retrieve the data. accounts The updated code is located in the hardcoded folder. Read More »

In the previous step, we have created specifications for four microservices. In the same folder, along with the openapi.yaml and openapi.json, we also added two more files. README.md and config.json In the README.md, there is a link to the original specification and more details about the API. In addition, there is a link and a command line to guide users to generate the project from the specification with light-codegen. config.json is a control file for light-codegen to direct code generation. Read More »

The specifications are based on the Account and Transaction API Specification from OpenBankingUK. And the original repository can be found at https://github.com/OpenBankingUK/account-info-api-spec The original specification is Swagger 2.0, and it is designed as a monolithic API with one spec. We first convert it to OpenAPI 3.0 format and then break it up into several microservices. Open Banking specification contains too many endpoints, and we cannot implement all microservices but only 4 of them for demonstration purposes. Read More »