Demo Experience
Guardian now includes a "Demo Experience" feature which separates the production and demo versions by default. In order to access either the production or demo version, the user will need to build and deploy Guardian, defining on the â.envâ file present in the root directory the variable âDEMO=trueâ if the demo is desired or not stating it at all if the production mode is intended.
It's important to note that if âDEMOâ is present with a value other than âDEMO=trueâ, the auth-service, api-gateway, guardian-service and web-proxy modules will still be built as if the demo is intended, so either use âDEMO=trueâ or delete the variable altogether.
Demo Mode
Procedure:
./.env
/## DEMO ENVIRONMENT
# in case it is desired to build Guardian in "demo" mode, you will need to define DEMO=true
# if "production" mode is intended, delete this variable altogether
DEMO=true
When deploying in demo mode, the demo accounts created on build will be included. Additionally, when it comes to the API, the present âapi/v1/demoâ endpoints will be accessible, leading to the availability of the "Demo Admin Panel", and the âapi/v1/accounts/registerâ POST method can be used by anyone even when logged out, as before. The header will make it evident that the user is using the demo as "Guardian" will have "Demo" written in superscript and the color of the header will turn grey instead of the default black.
Production Mode
Procedure:
./.env
## DEMO ENVIRONMENT
# in case it is desired to build Guardian in "demo" mode, you will need to define DEMO=true
# if "production" mode is intended, delete this variable altogether
When Guardian is built in production mode, the demo accounts that have been present until now will no longer be produced on deployment, besides a single Standard Registry account. The âapi/v1/accounts/registerâ POST method is now guarded to be used exclusively by logged in Standard Registries while the âapi/v1/demo/â methods are deactivated as well. Finally, on the frontend side, the "Demo Admin Panel" will no longer be present.
To summarize, the "Demo Experience" feature in Guardian allows for the separation of the production and demo versions. By defining the âDEMOâ variable in the â.envâ file, the user can access the desired version. In production mode, the demo accounts and related features will no longer be present, whereas in demo mode, they will be available and the header will indicate that the user is using the demo version.
Deploying with Docker Compose
Much like what was already done for the âweb-proxyâ service, now the âauth-serviceâ, âapi-gatewayâ and âguardian-serviceâ services also contain separate Dockerfiles and tsconfig files for both demo and production modes. This allows further liberties when configuring each mode. For the already existing âweb-proxyâ service, as we are now allowing the toggle of building with demo configurations, some of these can be found at the bottom of your .env.${GUARDIAN_ENV}.guardian.system, such as:
./guardian/configs/.env.${GUARDIAN_ENV}.guardian.system
# DEMO CONFIGS - WEB PROXY
# --------------
GATEWAY_HOST="api-gateway"
GATEWAY_PORT="3002"
GATEWAY_CLIENT_MAX_BODY_SIZE="1024m"
MRV_SENDER_HOST="mrv-sender"
MRV_SENDER_PORT="3005"
TOPIC_VIEWER_HOST="topic-viewer"
TOPIC_VIEWER_PORT="3006"
API_DOCS_HOST="api-docs"
API_DOCS_PORT="3001"
In order to make use of the already existing demo configuration files, the intention was to make the deployment in either demo or production mode as seamless as possible, leading, unfortunately, to a compromise. Because â.ymlâ files do not allow native logic operations and Docker Compose does not allow âif elseâ operations, the âweb-proxyâ, âauth-serviceâ, âapi-gatewayâ and âguardian-serviceâ services will build the demo versions every time the variable âDEMOâ is stated, even if it is equal to a random value or even âfalseâ. As stated before, the rule of thumb is if you want the demo, state âDEMO=trueâ, otherwise delete the variable all together from your root .env file. The following diagrams summarize what has been said:
New way of creating accounts (transversal to both Demo and Production modes)
Up until now it was possible to generate new accounts on the âCreate New Accountâ under the /login page, however, with these changes, this will only remain true if under a Demo build (DEMO=true defined on the ~/.env). This requires a new way for Standard Registries to be able to create new accounts. The /accounts/register POST method is still available on both versions, exclusively for Standard Registries if on Production mode (no DEMO variable defined on ~/.env), however Standard Registries also have a new menu option once logged in. Under the âAdministrationâ menu one can find a âCreate Accountsâ option that will lead to the same account creation process as before. This is depicted in the figures below.
Last updated