LIGHT

  • News
  • Docs
  • Community
  • Reddit
  • GitHub
Star

Web Client SPA

Since we have introduced handler.yml for multi-chain support in the light-4j platform, there are a lot of enhancements added to these frameworks. One of the most important features is to support the Single Page Application with path-resource and virtual-host.

In this tutorial, we are going to reconfigure the generated light-hybrid-4j server to serve the SPA with handler.yml config file. The project is the web-client for taiji-blockchain, and all source code can be accessed from the github repo. The sub-project we are going to modify is the server.

As of release 1.5.23, the light-hybrid-4j codegen still using PathHandlerProvider to define the handlers chain. To support path-resource handler, we are going to make some configuration change to enable handler.yml

First, let’s create a new folder under server called config. This folder will contain different configuration files for local development, testnet, and mainnet. For this tutorial, we are going to use a local folder for the configuration.

Copy config

Create a local folder under config and copy all the configuration files from the default folder under src/test/resources/config.

handler.yml

Add a handler.yml file with the content like below.

# Handler middleware chain configuration
---
enabled: true

#------------------------------------------------------------------------------
# Support individual handler chains for each separate endpoint. It allows framework
# handlers like health check, server info to bypass majority of the middleware handlers
# and allows mixing multiple frameworks like OpenAPI and GraphQL in the same instance.
#
# handlers  --  list of handlers to be used across chains in this microservice
#               including the routing handlers for ALL endpoints
#           --  format: fully qualified handler class [email protected]:given name
# chains    --  allows forming of [1..N] chains, which could be wholly or
#               used to form handler chains for each endpoint
#               ex.: default chain below, reused partially across multiple endpoints
# paths     --  list all the paths to be used for routing within the microservice
#           ----  path: the URI for the endpoint (ex.: path: '/v1/pets')
#           ----  method: the operation in use (ex.: 'post')
#           ----  exec: handlers to be executed -- this element forms the list and
#                       the order of execution for the handlers
#
# IMPORTANT NOTES:
# - to avoid executing a handler, it has to be removed/commented out in the chain
#   or change the enabled:boolean to false for a middleware handler configuration.
# - all handlers, routing handler included, are to be listed in the execution chain
# - for consistency, give a name to each handler; it is easier to refer to a name
#   vs a fully qualified class name and is more elegant
# - you can list in chains the fully qualified handler class names, and avoid using the
#   handlers element altogether
#------------------------------------------------------------------------------
handlers:
  # Light-framework cross-cutting concerns implemented in the microservice
  - [email protected]
  # - [email protected]
  # - [email protected]
  # - [email protected]
  # Cors handler to handler post/put pre-flight
  # - [email protected]
  # - [email protected]
  # - [email protected]
  # - [email protected]
  # - [email protected]
  # - [email protected]
  # - [email protected]
  # Header middleware to manipulate request and/or response headers before or after downstream server
  # - [email protected]
  # Direct requests to named services based on the request path
  # - [email protected]
  # - [email protected]
  - [email protected]
  - [email protected]
  # Customer business domain specific cross-cutting concerns handlers
  # - [email protected]
  # Framework endpoint handlers
  - [email protected]
  - [email protected]
  # - [email protected]eus

chains:
  default:
    - exception
    - json

paths:
  - path: '/api/json'
    method: 'GET'
    exec:
      - default
  - path: '/api/json'
    method: 'POST'
    exec:
      - default

  - path: '/health/io.taiji.server-1.0.0'
    method: 'get'
    exec:
      - health

  # In most case, the /server/info endpoint shouldn't be exposed. If it is, then it must be protected by OAuth 2.0 or Basic Auth
  - path: '/server/info'
    method: 'get'
    exec:
      - info


defaultHandlers:
  - resource

To make it simple, we only enable the exception handler and JsonHandler as default. For the JsonHandler, it maps to the path /api/json for both GET and POST.

Also, there are /health and server/info path and handlers wired in. For the SPA, we have added the defaultHandlers with the only path-resource handler.

path-resource.yml

We need to add this config file for the SPA resource handler.

path: /
# This is the base used by docker
# base: /public
# This is the base that is used for IDE debugging
base: /home/steve/taiji-chain/web-client/server/view/build
prefix: true
transferMinSize: 10485760
directoryListingEnabled: false

As we are using IDE for testing and debugging, we need to use the absolute path on my desktop computer for the base. Once it is dockerized, you can use /public which will be mapped to a volume on a directory of the host.

service.yml

The generated service.yml contains PathHandlerProvider and all the middleware handlers for the chain. We need to remove them all as we have switched to handler.yml for the chain definition. After modification, the config file looks like this.


# Singleton service factory configuration/IoC injection
singletons:
# StartupHookProvider implementations, there are one to many and they are called in the same sequence defined.
- com.networknt.server.StartupHookProvider:
  # registry all service handlers by from annotations
  - com.networknt.rpc.router.RpcStartupHookProvider

SPA

Now, go to the root folder of server project and create a React app with the create-react-app tool and build it.

npx create-react-app view
cd view
yarn build

A build folder will be created with yarn build, and it contains the final SPA application ready for production.

pom.xml

There are two modules need to be added to the generated pom.xml as there are not included by default.

        <dependency>
            <groupId>com.networknt</groupId>
            <artifactId>resource</artifactId>
            <version>${version.light-4j}</version>
        </dependency>
        <dependency>
            <groupId>com.networknt</groupId>
            <artifactId>health</artifactId>
            <version>${version.light-4j}</version>
        </dependency>

Summary

With the above steps, the server project is ready to serve static content. Start the server from IDE with the following VM options.

-Dlight-4j-config-dir=/home/steve/taiji-chain/web-client/server/config/local

And go to your browser with the URL https://localhost:8443 and you can see the React application running.

  • About Light
    • Overview
    • Testimonials
    • What is Light
    • Features
    • Principles
    • Benefits
    • Roadmap
    • Community
    • Articles
    • Videos
    • License
    • Why Light Platform
  • Getting Started
    • Get Started Overview
    • Environment
    • Light Codegen Tool
    • Light Rest 4j
    • Light Tram 4j
    • Light Graphql 4j
    • Light Hybrid 4j
    • Light Eventuate 4j
    • Light Oauth2
    • Light Portal Service
    • Light Proxy Server
    • Light Router Server
    • Light Config Server
    • Light Saga 4j
    • Light Session 4j
    • Webserver
    • Websocket
    • Spring Boot Servlet
  • Architecture
    • Architecture Overview
    • API Category
    • API Gateway
    • Architecture Patterns
    • CQRS
    • Eco System
    • Event Sourcing
    • Fail Fast vs Fail Slow
    • Integration Patterns
    • JavaEE declining
    • Key Distribution
    • Microservices Architecture
    • Microservices Monitoring
    • Microservices Security
    • Microservices Traceability
    • Modular Monolith
    • Platform Ecosystem
    • Plugin Architecture
    • Scalability and Performance
    • Serverless
    • Service Collaboration
    • Service Mesh
    • SOA
    • Spring is bloated
    • Stages of API Adoption
    • Transaction Management
    • Microservices Cross-cutting Concerns Options
    • Service Mesh Plus
    • Service Discovery
  • Design
    • Design Overview
    • Design First vs Code First
    • Desgin Pattern
    • Service Evolution
    • Consumer Contract and Consumer Driven Contract
    • Handling Partial Failure
    • Idempotency
    • Server Life Cycle
    • Environment Segregation
    • Database
    • Decomposition Patterns
    • Http2
    • Test Driven
    • Multi-Tenancy
    • Why check token expiration
    • WebServices to Microservices
  • Cross-Cutting Concerns
    • Concerns Overview
  • API Styles
    • Light-4j for absolute performance
    • Style Overview
    • Distributed session on IMDG
    • Hybrid Serverless Modularized Monolithic
    • Kafka - Event Sourcing and CQRS
    • REST - Representational state transfer
    • Web Server with Light
    • Websocket with Light
    • Spring Boot Integration
    • Single Page Application
    • GraphQL - A query language for your API
    • Light IBM MQ
    • Light AWS Lambda
    • Chaos Monkey
  • Infrastructure Services
    • Service Overview
    • Light Proxy
    • Light Mesh
    • Light Router
    • Light Portal
    • Messaging Infrastructure
    • Centralized Logging
    • COVID-19
    • Light OAuth2
    • Metrics and Alerts
    • Config Server
    • Tokenization
    • Light Controller
  • Tool Chain
    • Tool Chain Overview
  • Utility Library
  • Service Consumer
    • Service Consumer
  • Development
    • Development Overview
  • Deployment
    • Deployment Overview
    • Frontend Backend
    • Linux Service
    • Windows Service
    • Install Eventuate on Windows
    • Secure API
    • Client vs light-router
    • Memory Limit
    • Deploy to Kubernetes
  • Benchmark
    • Benchmark Overview
  • Tutorial
    • Tutorial Overview
  • Troubleshooting
    • Troubleshoot
  • FAQ
    • FAQ Overview
  • Milestones
  • Contribute
    • Contribute to Light
    • Development
    • Documentation
    • Example
    • Tutorial
“Web Client SPA” was last updated: July 5, 2019: update web-client-spa tutorial for syntax errors (e2ef0af)
Improve this page
  • News
  • Docs
  • Community
  • Reddit
  • GitHub
  • About Light
  • Getting Started
  • Architecture
  • Design
  • Cross-Cutting Concerns
  • API Styles
  • Infrastructure Services
  • Tool Chain
  • Utility Library
  • Service Consumer
  • Development
  • Deployment
  • Benchmark
  • Tutorial
  • Troubleshooting
  • FAQ
  • Milestones
  • Contribute