NGS Guides: Setting Up A Battery Charging Station Back-End in 20 Minutes
This guide illustrates a non-trivial solution that is easily and quickly accomplished with Synadia’s NGS service. NGS is a global utility delivering enterprise grade NATS-as-a-Service from multiple clouds and multiple geos. NGS is managed by Synadia, the core maintainer of NATS.io. You can sign up for a free NGS account and implement the solutions below in less than 20 minutes. We call this scenario The Battery Spa.
Introduction
The Battery Spa Inc. provides EV recharging stations in Asia, Europe, and the United States. They charge all makes and models of EV and provide added-value services such as real-time weather reports, mileage and efficiency log, and instant vehicle-to-vehicle "car chat." As a world-wide charging infrastructure and communications provider to diverse EV brands and types, The Battery Spa requires only that vehicles can connect over public networks to NGS.
Charging technology, core competency of The Battery Spa, is installed and operated at more than 1,000 autonomous "edge stations." Payment authorization and capture processing for "spa visits" are contracted to service providers who operate in their own clouds. Service connectivity from edge stations is via NGS as well.
The Battery Spa invests in continuous improvement and innovation inspired by constant transaction analysis and machine learning applied over business event streams from customer vehicles and charging stations.
In the following steps we use the NATS CLI tool. The NATS CLI is an excellent "multi-tool" but has no special super powers. Every step here could be accomplished (and often would be) in your own application leveraging highly-productive NATS client development libraries.
Pre-requisites and setup
NGS account and user
Linux or MacOS
bash shell
NATS CLI tool v0.0.31 or greater
Scenario Actors: NGS Clients
For demo, we'll set up several NATS.io login contexts with the NGS user credential created automatically at NGS sign up.
Set or replace $NGSCONTEXT in the following commands to the name of the NATS context created automatically at sign up. Here's an example:
export NGSCONTEXT="synadia_peaceful_shockley_default"
Use nats context ls to show existing contexts on your terminal. NGS new account signup automatically creates a context called synadia_{your account name}_default.
nats context copy $NGSCONTEXT vehicle1 nats context copy $NGSCONTEXT vehicle2 nats context copy $NGSCONTEXT vehicle3 nats context copy $NGSCONTEXT payauthorizer nats context copy $NGSCONTEXT payworker nats context copy $NGSCONTEXT cloudadmin nats context copy $NGSCONTEXT datascience nats context copy $NGSCONTEXT ngsleafnode
We'll add a few more scenario actors later when we configure an NGS-connected server at the Edge.
Use nats help {your CLI command} to get options specific to each CLI command.
The Zen of NGS: Dynamic Message Network
The Battery Spa initially selected NGS for its unique and innate abilities as a dynamic message network providing:
Participant Location-Transparency
Interest-Based Message Routing
Bi-Directional Asynchronous Messaging
Low-Latency
Extreme-Speed
Access-Policy
Their first implementation on NGS was "car chat."
Vehicle 1 publishes a message to subscribing vehicles by simple subject
nats sub vehicle --context vehicle2
nats pub vehicle 'Stay in your lane please!' --context vehicle1
We published and received messages on the subject "vehicle". NGS automatically routed the message from vehicle1 to vehicle2 based on subscription-interest graph. NGS also validated entitlement for vehicle1 to publish on subject "vehicle" and vehicle2 to subscribe and receive messages on subject "vehicle".
By default, all users of an account may publish and subscribe to subjects within their own account's subject namespace.
Vehicle 1 publishes a message specifically to Vehicle 2 subscribers
nats sub 'vehicle.2.>' --context vehicle2
nats pub vehicle.2.tickle 'Hello to vehicle 2 specifically' --context vehicle1
We published to a subject hierarchy enabling subscription interest and message routing to be as specific as we need for our solution.
Vehicle 1 publishes a message received by one subscriber (of a group of subscribers)
nats sub vehicle.cool --queue coolcars --context vehicle3
nats sub vehicle.cool --queue coolcars --context vehicle2
nats pub vehicle.cool 'Hello one of two coolcars workers' --context vehicle1
Message delivery to one member of a group of subscribers acting as a processing pool (shared queue).
Vehicle 1 sends a request (or action) to Vehicle 2 and expects to receive a reply
nats reply 'vehicle.2.>' 'Vehicle 2 got poked [Response {{Count}}]' --context vehicle2
nats request vehicle.2.poke 'I am poking you' --context vehicle1
API invocation using native Request-Reply asynchronous messaging with automatic reply subject.
Vehicle 2 and Vehicle 3 both may reply to "carpool" requests, but each request should go to only one vehicle
nats reply 'vehicle.*.>' --queue carpool --context vehicle2 \ 'Vehicle 2 got poked [Response {{Count}}]'
nats reply 'vehicle.*.>' --queue carpool --context vehicle3 \ 'Vehicle 3 got poked [Response {{Count}}]'
nats request vehicle.any.poke 'I am poking you' --context vehicle1
Instant load balancing for API services!
Life is but a Stream: Reliable and Durable Messaging
Vehicles and Stations emit business event notifications which The Battery Spa captures for analysis and ML
The Battery Spa configures two NGS JetStreams with limits policy to retain events for up to 7 days. They also put caps on the total size and number of messages for each stream to smooth retention spikes when vehicles get really chatty.
JetStream captures messages published to subjects that The Battery Spa architects designed for easy filtering and routing of event notifications including the ability to easily see events for a particular vehicle (or station) only or for all event emitters in a specific business region and sub-area.
NGS takes care of message reliability through persistence. The Battery Spa initially specifies only one copy -- or JetStream replica -- of event data but can expand to high-availability storage later (three replicas).
If your NGS subscription level includes JetStream high-availability (HA) storage, you may set the number of replicas to 3 when creating new streams.
The most active customers are in the Western US currently so The Battery Spa cloud administrator places the vehicle event stream in the NGS geographic region us-west using placement tags.
Any messages published matching the subject hierarchy vehicle.*.*.*.event.> will be ingested in the VEHICLE-EVENTS JetStream and available for later consumption by subscribers.
nats stream add VEHICLE-EVENTS --context cloudadmin \ --description 'Capture vehicle events in an NGS stream' \ --tags 'geo:us-west' \ --subjects 'vehicle.*.*.*.event.>' \ --retention limits --discard old --dupe-window 2m \ --max-age 7d --max-bytes 10485760 --max-msgs 1000 --max-msgs-per-subject=-1 --max-msg-size 131072 \ --replicas 1 --storage file \ --no-deny-delete --no-deny-purge --no-allow-rollup
We specify various growth limits on our VEHICLE-EVENTS stream:
<ul> <li>Maximum 10 MiB total for all messages</li> <li>Maximum 1,000 total messages</li> <li>Maximum 128 KiB a message</li> <li>Maximum age of 7 days for a message</li> <li>Duplicate message detection in a 2 minute window</li> </ul>
Likewise, any messages published matching the subject hierarchy station.*.*.*.event.> are ingested in the STATION-EVENTS JetStream. The cloud administrator places this stream in NGS geographic region us-east.
nats stream add STATION-EVENTS --context cloudadmin \ --description 'Capture station events in an NGS stream' \ --tags 'geo:us-east' \ --subjects 'station.*.*.*.event.>' \ --retention limits --discard old --dupe-window 2m \ --max-age 7d --max-bytes 10485760 --max-msgs 1000 --max-msgs-per-subject=-1 --max-msg-size 131072 \ --replicas 1 --storage file \ --no-deny-delete --no-deny-purge --no-allow-rollup
Vehicle 1 and Vehicle 2 each publish 10 low battery event messages
nats pub vehicle.1.R9.A7.event.lowbattery --count 10 --context vehicle1 \ 'Low battery, remaining 15% [Measure: {{Count}}]'
nats pub vehicle.3.R3.A9.event.lowbattery --count 10 --context vehicle3 \ 'Low battery, remaining 2% RED [Measure: {{Count}}]'
The cloud administrator verifies VEHICLE-EVENTS stream configuration
nats stream view VEHICLE-EVENTS --since 1h --subject 'vehicle.*.*.*.event.lowbattery' --context cloudadmin
We are able to instantly capture messages published to a given subject (with or without wildcarding) and persist them in named JetStreams to be consumed (and re-consumed) as needed by subscribers later.
In this example, no modification to publishing clients was required (stream ingestion happens silently). In a later example, we'll show that a publishing client can receive an ingestion acknowledgement from JetStream by doing a request instead of a publish, in this way providing reliable publishing.
We were able to influence where our streams physically (geographically in this case) reside in NGS to optimize round-trip network latency. In NGS, location-transparency is inherent so the streams are accessible from any NGS-connected client.
Configuring limits on streams allows us to control stream growth at aggragate and individual message levels and what should happen when limits are reached -- such as old messages deleted (most common) or new messages rejected.
We implemented a stream pattern ( Limits retention policy) in which messages can be consumed (and re-consumed or "replayed") any number of times by multiple subscribers.
The Battery Spa data scientists have multiple ML engines that read and import combined vehicle and station events
The Battery Spa cloud administrator creates a third JetStream to combine STATION-EVENTS and VEHICLE-EVENTS to single stream, ALL-EVENTS, for ML engine usage. After the ML engines consume messages from this stream they are no longer needed so the administrator sets an Interest retention policy on the new stream.
The ALL-EVENTS stream is placed in the European NGS geographic region as most of The Battery Spa analytics and machine learning is conducted by a team in Germany.
nats stream add ALL-EVENTS --context cloudadmin \ --description 'Aggragate events in an NGS stream' \ --tags 'geo:europe' \ --source '{ "name": "STATION-EVENTS" }' \ --source '{ "name": "VEHICLE-EVENTS" }' \ --retention interest --discard old --dupe-window 2m \ --max-age 7d --max-bytes 10485760 --max-msgs 1000 --max-msgs-per-subject=-1 --max-msg-size 131072 \ --replicas 1 --storage file \ --no-deny-delete --no-deny-purge --no-allow-rollup
We can optionally provide a subject filter for each stream source.
If desired, you may substitute --source '{ "name": "VEHICLE-EVENTS", "filter_subject": "vehicle.3.*.*.event.>" }' to only source vehicle3 events.
A JetStream (JS) Consumer is created for ML engine consumption of ALL-EVENTS stream
ML engine developers will pull messages from a JS Consumer service created for them. The JS Consumer establishes interest in new ALL-EVENTS messages and tracks reliable delivery to the ML engine clients.
nats consumer add ALL-EVENTS ALL-EVENTS-CONSUMER --context cloudadmin \ --description 'JS Consumer that reads everything from ALL-EVENTS stream' \ --pull --filter "" --ack explicit --replay instant --deliver all \ --max-deliver 10 --max-pending 500 --no-headers-only --backoff none
As the ALL-EVENTS stream was defined with Interest-based retention policy, you will see zero messages pending at first as previously there was no consumer interest so messages were immediately deleted from the stream. Publish new "lowbattery" events after creating the ALL-EVENTS-CONSUMER to see pending messages.
The cloud administrator verifies that the JS Consumer is ready to use
nats consumer info ALL-EVENTS ALL-EVENTS-CONSUMER --context cloudadmin
The datascience platform can now consume messages
nats consumer next ALL-EVENTS ALL-EVENTS-CONSUMER --ack --count 1 --context datascience
Using JetStream we combined (or multiplexed) two "upstreams" into a new stream. Through optional SOURCE subject filters we are able to split (or demultiplex) one upstream into smaller streams. By specifying Interest policy we implemented a multi-consumer durable topic pattern allowing multiple consumer "queues" on the same message stream, each receiving a copy of a message before ultimately being deleted from the JetStream.
The data science team at The Battery Spa regularly needs to train new ML engine versions on smaller event sets
The data science team at The Battery Spa is evaluating a new ML technology and wish to train it with a controlled set of vehicle events emitted just from business area 9. A second JS Consumer on ALL-EVENTS is created just for this trial.
nats consumer add ALL-EVENTS AREA9-SPECIAL-CONSUMER --context cloudadmin \ --description 'Read only new events from Area 9 from ALL-EVENTS stream' \ --pull --filter 'vehicle.*.*.A9.event.>' --ack explicit --replay instant --deliver new \ --max-deliver 10 --max-pending 500 --no-headers-only --backoff none
The ML technology engine under evaluation gets only Area 9-filtered messages from the new JS Consumer.
Vehicle 3 is moving through Area 9 when it reports low battery events:
nats pub vehicle.3.R3.A9.event.lowbattery --count 10 --context vehicle3 \ 'Low battery, remaining 2% RED [Measure: {{Count}}]'
The ML engine will see these events:
nats consumer next ALL-EVENTS AREA9-SPECIAL-CONSUMER --ack --count 4 --context datascience
The evaluation ML engine can process up to 4 events at a time so we asked the AREA9-SPECIAL-CONSUMER to deliver a micro stream of up to 4 events in this client request.
We created multiple consumers on a single JetStream to demonstrate Interest policy. Each JetStream consumer will have opportunity to read the events it is interested in before the messages are ultimately deleted from the underlying stream.
The development team at The Battery Spa has an offline environment for initial engineering work
From time to time, the data science engineering team at The Battery Spa needs an event data set for early development and unit test that they can import into their offline (in respect to NGS) engineering platform.
Currently, they need a copy of vehicle events.
The engineering teams reads VEHICLE-EVENTS to file on their workstation
nats stream backup VEHICLE-EVENTS '/tmp' --consumers --progress --context datascience
They subsequently, restore the stream from their workstation into their JetStream-enabled NATS Server instance
nats stream restore '/tmp' --progress --context '{offline engineering platform context}'
A JetStream called VEHICLE-EVENTS is created in their offline NATS Server environment, populated with all the event messages present at backup time. Any named durable JS Consumers defined against VEHICLE-EVENTS at backup time are also created.
We readily made backup copies of JetStreams (and JetStream Consumers if present) from NGS to a local system. We are able to restore the copies into a separate NATS Server environment. If we deleted the existing VEHICLE-EVENTS from NGS we could restore our copy back to NGS as well!
Keys to Success: Key-Store Materialized View
The Battery Spa implements an efficiency log for customers that records edge station visits
The product team at The Battery Spa approached engineering with a new in-vehicle app concept "Your Tracker" that would be available to all customers to log mileage and charge detail for every edge station visit.
In response, engineering and cloud administration created an NGS Key-Value (KV) store that is used to persist the last 10 charge visits for each customer vehicle. The latest charge visit and previous history are instantly available to The Battery Spa "Your Tracker" app hosted on vehicles anywhere in the world.
nats kv add VEHICLE-LOG --context cloudadmin \ --description 'KV store for misc vehicle information' \ --replicas 1 --storage file --history 10 --max-bucket-size 10485760 --max-value-size 131072
Each station visit by a vehicle records a "last charge" data record
nats kv put VEHICLE-LOG vehicle.1.lastcharge --context vehicle1 \ '{ "mileage": "23456", "timestamp": "1648583305", "station": "station1.R9.A7" }' nats kv put VEHICLE-LOG vehicle.1.lastcharge --context vehicle1 \ '{ "mileage": "23890", "timestamp": "1648647305", "station": "station345.R11.A1" }'
On-demand, a customer can recall their vehicle log (latest and historic log entries)
nats kv get VEHICLE-LOG vehicle.1.lastcharge --context vehicle1
nats kv history VEHICLE-LOG vehicle.1.lastcharge --context vehicle1
Some features of the "Your Tracker" App UX leverage real-time record updates
nats kv watch VEHICLE-LOG vehicle.1.lastcharge --context vehicle1
Leveraging the flexibility of JetStream, we materialized a Key-Value Store (bucket) with key-based put, get, history, and watch features. Each vehicle has a unique key.
Object of Desire: Object Store Materialized View
Object Store materialized views is a preview feature.
The Battery Spa displays targeted ads at spa locations to delight customers as they recharge their vehicles
To spice up recharging, The Battery Spa product designers specified audio-visual capabilities at each autonomous edge station.
Battery Spa cloud administrators created an object store in NGS to house advertisement images and videos that may easily be accessed by the audio-visual experience service at each station for recharge-time entertainment.
We'll use a simple image file (OG.jpg) for demonstration. Feel free to substitute any local file you like.
curl -s https://synadia.com/static/OG.jpg > /tmp/ad1234.jpg
Cloud administrators create an object store in NGS called STATION-ADS and upload audio and video files.
nats object add STATION-ADS --context cloudadmin \ --description 'Station advertisement artifact store' \ --max-bucket-size 10485760
We specified that our STATION-ADS object store will hold up to 10 MiB (10,485,760 bytes).
nats object put STATION-ADS --context cloudadmin \ '/tmp/ad1234.jpg' --name 'ad1234.jpg'
nats object ls STATION-ADS --context cloudadmin
Edge stations pull down audio and video files from the STATION-ADS object store.
nats object get STATION-ADS 'ad1234.jpg' --context station1 \ --output '/tmp/edgecache-ad1234.jpg'
We leveraged object storage in NGS, extending anywhere-to-anywhere messaging to storing and sharing binary objects of arbitrary type! Object store takes care of automatically chunking and reassembling binary objects such that size is limited only by the maximum size specified for the object store.
Living on the Edge: NGS Leaf Nodes
Each charging station of The Battery Spa is an autonomous physical installation
The Battery Spa prides itself on experience, particularly never failing a customer when they pull up to the "spa" in desparate need of a "restorative recharge." Several critical services that orchestrate near-field vehicle communication, payment acceptance, and recharge workflow all run as microservices locally at each station. Each station has real-time bi-directional communication with The Battery Spa services, each of which is hosted in multiple clouds and geographic regions; however, if a station is offline from cloud for any reason, it can continue to function until connectivity is restored.
Each station has a local NATS Server supporting microservice communication at the station and NGS connectivity
For demonstration, we can instantly start a local NATS server with the NATS CLI tool. We use the --jetstream and --extend options to specify that we will be configuring local streams and connecting to NGS using the ngsleafnode context (NGS connection URL and credential).
See also: NATS CLI embedded server documentation (Experimental)
nats server run --context ngsleafnode --jetstream --extend
Edge-local NATS login contexts are automatically created in the above command. We use context nats_development in subsequent steps.
Let's create some edge station actors for this part of the scenario
# These contexts are for edge-local connections to NATS server nats context copy nats_development edgeadmin nats context copy nats_development station1
Vehicles may request real-time weather reports from specific The Battery Spa stations
The weather microservice at a station connects to its local NATS Server and listens for weather requests
nats reply station.1.NA.NA.request.weather --context station1 \ --command 'curl -s wttr.in/?format=3'
Vehicles make weather requests to a given station number; both vehicle and station can be anywhere in the world
nats request station.1.NA.NA.request.weather --context vehicle1 \ 'Weather report at your station please'
Stations make payment authorization requests to cloud-hosted payment authorizer services
The payment authorizer services listen for authorization requests via NGS from their payment cloud in Asia.
nats reply 'cloud.payment.authorize.>' --context payauthorizer \ --command 'echo "Request {{3}} for {{4}} authorized"'
Each edge station makes payment authorization API calls (when connected to cloud services) to reduce payment fraud.
nats request cloud.payment.authorize.1234.vehicle1 --context station1 \ 'Payment auth request 1234 for $75.00'
Stations report a successful authorization request as a business event
The edge payment authorization microservice client publishes events locally which are available to other services at the edge as well as captured in the NGS stream
nats pub station.1.R9.A7.event.payauthsuccess --context station1 \ 'Payment authorization [1234]:[75.00]:[SUCCESS]'
We started a local NATS server instance and used Leaf Node to connect to NGS, thus securely extending communication to your hosted environments and services. We showed that applications at edge may connect locally to their NATS servers, but function and act globally!
The Battery Spa transactions must be captured reliably for post-visit payment capture processing in cloud
The edge administrator configures a JetStream (STATIONTX-LOCAL) at Station 1 to persist local transactions for up to 2 days
nats stream add STATIONTX-LOCAL --context edgeadmin \ --description 'Capture station transactions locally for reliability' \ --subjects 'station.1.*.*.tx.>' \ --retention limits --discard old --dupe-window 10m \ --max-age 2d --max-bytes 5242880 --max-msgs 500 --max-msgs-per-subject=-1 --max-msg-size 131072 \ --replicas 1 --storage file \ --no-deny-delete --no-deny-purge --no-allow-rollup
Leaf node JetStreams can be remotely administed from NGS by setting the --js-domain option in the NATS CLI (or programmatically by specifying JS domain in your code).
Every transaction that is captured locally at edge is automatically and reliably mirrored to NGS cloud
To make sure that we have an exact copy of every transaction captured at Station 1, we create JetStream STATIONTX-HISTORY in NGS as a mirror of STATIONTX-LOCAL. Each message of the STATIONTX-LOCAL stream will be copied -- sequence number and order preserved -- and available at STATIONTX-HISTORY. Breaks in connectivity between the mirror source and target JetStream are not an issue. The target JetStream will be caught up when connectivity is restored.
nats stream add STATIONTX-HISTORY --context cloudadmin \ --description 'Mirror edge station transactions in an NGS cloud stream' \ --tags 'geo:us' \ --mirror '{ "name": "STATIONTX-LOCAL", "external": { "api": "$JS.NATS_DEVELOPMENT.API" } }' \ --retention limits --discard old \ --max-age=-1 --max-bytes 10485760 --max-msgs=-1 --max-msgs-per-subject=-1 --max-msg-size 131072 \ --replicas 1 --storage file \ --no-deny-delete --no-deny-purge --no-allow-rollup
Note the additional configuration of an external JetStream domain "NATS_DEVELOPMENT" to tell NGS that the mirror source is in a JetStream Domain different from the NGS domain, i.e. our edge Leaf Node's JS Domain.
With JetStream we can continuously replicate streams by mirroring one JetStream to another, preserving both messaging sequence and unique IDs. Mirroring can be completely within NGS or can be used in combination with NGS-connected Leaf Nodes. The retention and other policies of the target JetStream need not be the same as its mirror source creating great flexibility in solutioning, e.g. short-lived work streams and long-lived archive streams.
The Battery Spa contracts with a payment processor in Asia to do credit payment capture
The Battery Spa cloud administrator creates a JetStream in NGS, STATIONTX-PROCESS, and places it in Asia to be geographically co-located with the payment processor's cloud. This JetStream is a mirror of STATIONTX-HISTORY (a complete history of station transactions), but with a WorkQueue retention policy insuring that each message is consumed and acknowledged only once (a traditional queue).
nats stream add STATIONTX-PROCESS --context cloudadmin \ --description 'Edge station transactions work queue in NGS cloud' \ --mirror '{ "name": "STATIONTX-HISTORY" }' \ --tags 'geo:asia' \ --retention workq --discard old \ --max-age=-1 --max-bytes 10485760 --max-msgs=-1 --max-msgs-per-subject=-1 --max-msg-size 131072 \ --replicas 1 --storage file \ --no-deny-delete --no-deny-purge --no-allow-rollup
The payment processor microservices use a durable JS Consumer to "dequeue" from STATIONTX-PROCESS
nats consumer add STATIONTX-PROCESS PAYMENT-CONSUMER --context cloudadmin \ --description 'JS Consumer that reads process queue' \ --pull --filter "" --ack explicit --replay instant --deliver all \ --max-deliver 10 --max-pending 500 --no-headers-only --backoff none
This JS Consumer is configured to allow a maximum of 500 payment transactions to be in-flight (not yet acknowledged) at any one time. Also, that a particular payment transaction will be attempted a maximum of 10 times.
Edge station 1 completes a customer recharge order
To guarantee the order transactions are captured (and never lost) the station's order microservice makes a publish request to JetStream and requires an acknowledgement (ACK) message from JetStream in reply. If no acknowledgement is received it will re-publish the transaction until ACK is received. The order microservice adds a Nats-Msg-Id header to the order transaction message with a unique transaction id value. JetStream will automatically detect any duplicate transaction publishes within a 10 minute window to avoid duplicate transaction messages from traveling downstream to the payment processor.
nats request station.1.R9.A7.tx.order --wait --context station1 \ --header 'Nats-Msg-Id:order567' \ 'Order 567 for Vehicle 1 made for $75.00'
Verify our order transaction is captured locally
nats stream info STATIONTX-LOCAL --context station1
And mirrored to transaction history in NGS
nats stream info STATIONTX-HISTORY --context cloudadmin
And our work queue now has has the order transaction too. Ready to process!
nats consumer info STATIONTX-PROCESS PAYMENT-CONSUMER --context payworker
Let's process payment capture for our order transaction
nats consumer next STATIONTX-PROCESS PAYMENT-CONSUMER --ack --count 1 --context payworker
We captured order transactions at our edge reliably -- even in the event of an edge-cloud network connectivity outage -- by leveraging a JetStream local to our edge microservices. Our transactions are automatically mirrored to a long-retention "history" stream in NGS and further mirrored to a stream configured as a payment processing work queue. We leveraged placement tags to place stream persistence in optimal geographic regions for our solution.
Scenario Cleanup
Remove NGS JetStreams created for the scenario
nats stream rm ALL-EVENTS --force --context cloudadmin nats stream rm STATIONTX-PROCESS --force --context cloudadmin nats stream rm STATIONTX-HISTORY --force --context cloudadmin nats stream rm STATION-EVENTS --force --context cloudadmin nats stream rm VEHICLE-EVENTS --force --context cloudadmin nats stream rm STATIONTX-LOCAL --force --context edgeadmin nats kv del VEHICLE-LOG --force --context cloudadmin nats object del STATION-ADS --force --context cloudadmin
Remove NATS contexts on your workstation created for the scenario
nats context rm vehicle1 --force; nats context rm vehicle2 --force nats context rm vehicle3 --force; nats context rm cloudadmin --force nats context rm datascience --force; nats context rm ngsleafnode --force nats context rm payauthorizer --force; nats context rm payworker --force nats context rm edgeadmin --force; nats context rm station1 --force nats context rm nats_development --force nats context rm nats_development_service --force nats context rm nats_development_system --force
Terminate the NATS CLI embedded NATS server
Thanks for following through this NGS Guide. If you have more questions on any of this, pop over to the NATS.io Slack. There you can ask the friendly NATS community and the Synadia team anything.
About the Author
Todd Beets serves as the Director of Product Solutions at Synadia. Todd is an enthusiast of the tech and art of connective tissue that unlocks and amplifies composite applications. With over 20 years of experience, he has designed service communication, hosting, and access solutions for a wide-spectrum of use-cases and scales. Prior to Synadia, Todd served as principal architect at Starbucks and Qualcomm.
