Main server for all wit products.
Introduction
The cornerstone of all wit
products, this is a suite of serverless microservices,
providing a common set of services across all wit
products including, but not limited to,
licensing & subscription, authentication & authorisation, application updates/upgrades, notifications,
billing, payments, account management, registration, user management and device management, in
addition to federating access to 3rd party services, such as, transport, news & weather.
Serverless Microservices
Serverless in deployment allowing to accommodate any dynamic load scenario as demand requires. Cloud Provider Agnostic - AWS, Azure, GCP and/or public/private cloud Kubernetes deployment.
Fine grained Microservices, allowing for fine scaling by function, isolation between function and benefitting from the best use of technologies specific to that function. WOZiTech promotes node.js and MongoDB, but being tech agnostic and having a experience in a large number of tech, WOZiTech will not shy away from say a "C#.net/SQLserver" microservice if that is more relevant for the task at hand.
Secure From Ground Up
Token-based API security built in from the ground up. Not just authentication, but authorisation too through client ids, audiences and claims. Auth0 is preferred by WOZitech, as the industry leading provider of security as a platform, supporting extensive set of Identity Management scenarios including, but not limited to, social media (Facebook, github, google, Twitter), native client (Microsoft, Android, iPhone), SPA web applications and significantly here, APIs.
All environments, except local development, enforce TLS (SSL) encryption to secure data in transit, passing JWT in the HTTP Authorization header.
API Gateway
wit-serve
itself is the gateway to the wit
set of microservices, providing
federated access across all discovered services including logging, profiling and, where necessary, caching.
API namespace is important; accessing microservices by portable URIs, across multiple environments. A microservice must be resolvable by URI and RESTful actions (GET, POST, DELETE, PUT) upon that URI.
Although microservices can be platform agnostic, all wit
microservices are deployed to the AWS platform.
This however has little sigificance, because as an API gateway, the deployment of wit-serve
only is significant; all wit
microservices, although individually directly accessible are accessed
via this gateway. Consequently only one root domain is required for the namespace to resolve wit-serve
microservices.
But separate namespaces are required for each environment. To allow for common TLS (SSL) certificates to
secure transport, the environment namespace must derive from a common namespace. All wit
microservices can be consumed by any wit
product.
The namespace used for wit
microservices will follow this pattern:
[http|https]://<environment>.api.wit.wozitech.click/<service name>
It is noted that by including the environment within the root namespace, each environment 'can' itself be deployed
to separate cloud providers; for example, production to AWS, acceptance to Azure and regression to GCP. All that is required
is a little cleverness to manage the sub-domains across cloud providers.
Different client platforms have different API interaction needs. An SPA web application will invoke an microservice API
differently to that of an Android client application. wit-serve
is the 'Backend for the Frontend' providing
facades to deliver the API more efficiently.
As a gateway, wit-serve
will employ good microservice patterns to ensure API availability, including, but not
limited to, circuit breaking and failover.
Local Development and Test
Develop and run functions locally to speed development and use best practice unit and integration tests.
Local deployment allows simple and effective development/testing of client applications & services
that depend on these functions. But rather the developer having to create individual test environments
with each dependable function then deployed and consequently configure their client accordingly, all
wit-serve
functions can be deployed to a local APIGW (nest.js single instance).
Alternatively, a wit-serve
Docker image using 'localstack'.
Showcase
Showcasing in this project is:
- Lambda Framework - despite its name, this is a Javascript API for abstracting serverless web applications for any provider (common cloud or custom).
- middy - lightweight middleware engine for AWS Lambda functions.
- pact.io - consumer driven contract test tool.
- Kong - the modern day API Gateway, along with Docker Kong = a Docker runable image of Kong (requires external Cassandra/PostgreSQL instance).
- AWS APIGW - industry leading serverless technology from AWS to expose lambda functions.
- AWS Lambda - industry leading serverless technology from AWS.
- AWS Step Functions - Orchestrating AWS Lambda.
- kubeless - Kubernetes answer to serverless functions.
- Azure Functions - Microsoft"s answer to serverless functions.
- GCP Functions - Google"s answer to serverless functions.
- localstack - A fully functional local AWS cloud stack, but more specifically localstack docker - a runable docker image.
- nest.js - node.js framework brokering local (test) access to functions by client services.
- Auth0 - never compromise on Identity; security from the ground up across all services.
-
Serverless Framework - open source agnostic serverless development and deployment.
And following on from this, introducing:
- Serverless Event Gateway - X-Cloud Providers event router.
- Serverless Dashboard - visualisation, monitoring & management of serverless functions x-cloud providers.