LIGHT

  • News
  • Docs
  • Community
  • Reddit
  • GitHub
Star

Virtual host on light-router

In the previous tutorial, we have shown how to sever a single page application from a router instance. In this tutorial, we are going to expend it again to host multiple domains in the same router instance.

The first step is to create a virtual-host folder in networknt/light-config-test/light-router and copy the content of taiji-faucet content into this folder.

After that, we need to update the configuration files a little bit.

handler.yml

We need to update the handler.yml to add VirtualHostHandler inject to replace the 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:
  - virtual

Please note that we have

  - [email protected]

And the defaultHandlers is defined as virtual

virtual-host.yml

This file defines all the domains and their base.

hosts:
  - domain: www.edibleforestgarden.ca
    path: /
    #base: /home/steve/networknt/site/edibleforestgarden/build
    base: /edibleforestgarden/build
    transferMinSize: 10245760
    directoryListingEnabled: false
  - domain: taiji.io
    path: /
    #base: /home/steve/networknt/site/taiji/build
    base: /taiji/build
    transferMinSize: 10245760
    directoryListingEnabled: false
  - domain: lightapi.net
    path: /
    #base: /home/steve/networknt/site/lightapi/build
    base: /lightapi/build
    transferMinSize: 10245760
    directoryListingEnabled: false

As this file is added, we need to remove the path-resource.yml as it is only for a single domain. Please note that we have the absolute path for base commented out. They are used when you are running the light-portal in a standalone mode or running it in an IDE for debugging.

Create Applications

Now, let’s create several react applications.

cd ~/networknt/light-config-test/light-router/virtual-host
npx create-react-app edibleforestgarden
npx create-react-app lightapi
npx create-react-app taiji

You should see there are three folders created. The next step is to modify these application so that we can differenciate them by domain.

Go to each folder and edit the App.js under src to replace

Edit <code>src/App.js</code> and save to reload.

To the corresponding domain name.

Edible Forest Garden
Light API Portal
Taiji Blockchain

Build Applications

Go to each SPA folder and run

yarn build

After that you can see there is build folder created under these three folders. You can also run the application to confirm that changes are shown on the home page. To start the server.

yarn start

Repeat the above steps for all three domains.

DNS Setup

To support multiple hosts, we need to set up DNS to point these host to the server. If you are using real VM, then you need to update your DNS entry to point to that address for all three hosts.

In my local test, we are going to update the /etc/hosts with the following.

127.0.0.1       localhost www.edibleforestgarden.ca taiji.io lightapi.net

To ensure that DNS setup is working, you can ping these three sites.

ping www.edibleforestgarden.ca
ping lightapi.net
ping taiji.io

Update Compose

Now let’s update the docker-compose.yml to add the volume mapping for the three domains.

version: '2'

services:

  light-router:
    image:  networknt/light-router:latest
    networks:
    - localnet
    ports:
    - 8443:8443
    volumes:
    - ./config:/config
    - ./edibleforestgarden/build:/edibleforestgarden/build
    - ./lightapi/build:/lightapi/build
    - ./taiji/build:/taiji/build

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

As you can see that we have mapped local SPAs build folders into the docker container folders defined in virtual-host.yml

Start Compose

Now let’s start the docker-compose and try it out.

Go to the browser and type the following addresses

https://www.edibleforestgarden.ca:8443
https://taiji.io:8443
https://lightapi.net:8443

And you can see the different home page per domain.

Debugging

If the home page is not shown up, then you can debug the router in your IDE to see what is really going on.

Before debugging session you need to shutdown the docker-compose.

docker-compose down

Also you need to update the virtual-host.yml to use the absolute path for base in each domain.

Here is the updated file.

hosts:
  - domain: www.edibleforestgarden.ca
    path: /
    base: /home/steve/networknt/light-config-test/light-router/virtual-host/edibleforestgarden/build
    #base: /edibleforestgarden/build
    transferMinSize: 10245760
    directoryListingEnabled: false
  - domain: taiji.io
    path: /
    base: /home/steve/networknt/light-config-test/light-router/virtual-host/taiji/build
    #base: /taiji/build
    transferMinSize: 10245760
    directoryListingEnabled: false
  - domain: lightapi.net
    path: /
    base: /home/steve/networknt/light-config-test/light-router/virtual-host/lightapi/build
    #base: /lightapi/build
    transferMinSize: 10245760
    directoryListingEnabled: false

Now we need to set up the debugging session IntelliJ IDEA for the externalized config folder as below.

-Dlight-4j-config-dir=/home/steve/networknt/light-config-test/light-router/virtual-host/config

If you are unsure how to debug light-4j application, please refer to this video

Video

Here is a video that walks through the configuration and gives a demo.

  • 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
“Virtual host on light-router” was last updated: July 5, 2021: fixes #275 checked and corrected grammar/spelling for majority of pages (#276) (b3bbb7b)
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