LIGHT

  • News
  • Docs
  • Community
  • Reddit
  • GitHub
Star

Router to render SPA

This tutorial is based on the taiji-faucet application in the folder networknt/light-config-test/light-router. The configuration is copied from taiji-faucet and modified in the router-spa folder.

In the previous tutorial, we have shown you how to create an instance of light-router for taiji-faucet service running in the Kubernetes cluster.

In this tutorial, we are going to enable the light-router to serve a single page application built on React. I am not going to complete the SPA but show you the steps to get it set up.

handler.yml

To serve the static content from light-4j application, we need to change the configuration for light-router to handler.yml in order to wire in PathResourceHandler.

# 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]
  # - [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]
  # Customer business domain specific cross-cutting concerns handlers
  # - [email protected]
  # Framework endpoint handlers
  - [email protected]
  - [email protected]
  # - [email protected]eus

chains:
  default:
    - exception
    #- metrics
    - traceability
    - correlation
    - header
    - path
    - router
    #- specification
    #- security
    #- body
    #- audit
    #- sanitizer
    #- validator

paths:
  - path: '/faucet/{address}'
    method: 'GET'
    exec:
      - default
  - path: '/faucet/{address}'
    method: 'POST'
    exec:
      - default

  - path: '/health/com.networknt.router-0.1.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

Please note that we have the

  - [email protected]

defined in the handlers section and this handler is referred in the defaultHandlers section at the end of the file.

defaultHandlers:
  - resource

This configuration tells the light-4j to handler all the other path/method combination with resource handler if they are not defined in the paths.

path-resource.yml

We also need to define some configuration parameters for the PathResourceHandler.

path: /
# This is the base used by docker
base: /public
# This is the base that is used for IDE debugging
#base: /home/steve/networknt/light-config-test/light-router/taiji-faucet/view/build
prefix: true
transferMinSize: 10485760
directoryListingEnabled: false

Please note that the configuration now is suitable for compose as a path in container is used. When you are running with debugger in an IDE, you need to switch to base: /home/steve/networknt/light-config-test/light-router/taiji-faucet/view/

This configuration tells the system to serve files from the base when there is request to the root path /. For example, if you put the following address in the address bar on your browser.

https://localhost:8443

Create application

Go the networknt/light-config-test/light-router/taiji-faucet folder and run the following command to create a React application called view.

npx create-react-app view
cd view
yarn build

Now we have a new React single page application built and it is readily to be served from the view/build folder.

Update Compose

Now let’s update the compose file to map this folder into the container.

version: '2'

services:

  light-router:
    image:  networknt/light-router:latest
    networks:
    - localnet
    ports:
    - 8443:8443
    volumes:
    - ./config:/config
    - ./view/build:/public

#
# Networks
#
networks:
    localnet:
        # driver: bridge
        external: true

You can see that we have mapped ./view/build to /public inside the container.

Start Compose

Let’s start the compose

docker-compose up

And then put the following URL into the address bar of your browser.

https://localhost:8443/

You will see an React starter application running. The next step is to update the React applicationt to access APIs on the portal.

The following is a video that walks through the process.

  • 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
“Router to render SPA” was last updated: April 2, 2019: fixes #62 add Chinese language for the document site (5c820aa)
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