taxi

Taxi Demo

Live Demo

This demo showcases the MQTT and REST protocols proxied to Kafka by Zilla. Zilla is using OpenAPI and AsyncAPI spec definitions to generate the necessary proxy config. The demo uses Open Street Maps, Open Route Service, and the MQTT Simulator to demonstrate a real-world taxi-hailing and location tracking service.

Using the Taxi UI

The Taxi Map UI highlights downtown San Jose, CA bars. You can hail a taxi to simulate traveling to each destination. Some shuttle buses also run routes to the bars and make permanent round trips.

• Clicking on one of the bar markers lets you hail a taxi
• The hailed taxi will "pick up" the passenger at the San Jose, CA Convention center
• The taxi will then proceed to the designated location on the map and stop sending location updates

Using the Demo

1. This demo has multiple taxi/bus IoT clients publishing location updates to Kafka using Zilla as the MQTT broker.
2. The red Bar markers indicate destinations and the green Vehicle markers represent the taxi/bus IoT clients.
3. Use the Taxi Map UI and click on a bar icon to "Hail a Taxi".
4. The map will show the route and the hailed taxi following it. You can use the "Clear Route" button in the sidebar or click the Aklivity logo to see the full map.
5. Open the Kafka UI in live mode to see the taxi locations updates.
   1. Notice the MQTT topic includes the bar name in the key: taxi/Fox_Tale_Ferm-86439137/location.
   2. Each message is an individual location update with a new Lat Long coord.
   3. Once the taxi gets to the destination, it will stop sending new updates.
6. The demo architecture is streamlined with Zilla.
   • No MQTT broker
   • No Kafka Connect
   • No web server
7. Zilla is proxying the MQTT and REST calls to the native Kafka protocol.
8. Use the OpenAPI Editor and AsyncAPI Studio to see the specs used to generate the Zilla config.
   • Kafka AsyncAPI
   • MQTT AsyncAPI
   • Taxi REST OpenAPI
9. Now you know how Zilla's Design-first, API-native approach to integration will:
   • Reduce architecture and DevOps complexity
   • Accelerate developer velocity
   • Maximize the investment in Kafka

Run the Demo

Demo architecture:

flowchart LR
    style zilla1 stroke:#0d9b76,stroke-width:4px

    tsgrpc[Dispatch Service] --> ttiot[Taxi 1] & ttiotb[Taxi 2] & ttiotc[Taxi 3]

    tmuisr[\Web/] -.- |HTTP| ztos

    subgraph zilla1 [Zilla Taxi Tracking]
            ztos{{OpenAPI REST}} --- ztoc[consume]
            ztas{{AsyncAPI MQTT}} --- ztapc[pub/sub]
    end

    ttiot & ttiotb & ttiotc -.-> |MQTT| ztas

    subgraph cc [Confluent Cloud]
        cciot[[Tracking Kafka Cluster]]
        ztapc -.- cciot
        ztoc -.- cciot
    end

Loading

Requirements

• Docker Compose

Setup

1. Start all of the services using Docker compose. The startup.sh script will build and start all the services. This command will also restart an existing stack.

   • You can run this demo with Redpanda by adding the --redpanda flag

   ./startup.sh

2. Use the local Taxi UI for the demo.

Data on Kafka / Redpanda

1. The Kafka topics are created during startup.
2. Browse the topics in the Kafka UI.
   • The Redpanda Console is available instead if you specified the --redpanda flag.
3. You can browse the log compacted topic taxi-locations to see each location update from active taxis.
   • The bus-locations topic is all of the automatic updates that are routed by the zilla config
   • Zilla is using the other topics listed to manage the MQTT and gRPC bindings
4. The Taxi UI pulls the most recent location for all of the unique taxis from Kafka.

Load Testing

The mqtt-simulation service includes a default_routes.json file, which starts a looping set of routes used in the demo. An additional file, default_routes_load_test.json, is available, which leverages the simulator's ability to generate multiple topics.

1. You will see in the JSON file the config for managing the number of topics to generate by updating the "RANGE_END" value:

   "TYPE": "multiple",
   "RANGE_START": 1,
   "RANGE_END": 500,

2. The taxi-tracking-service in the docker-compose.yaml file mounts the default config. Update the volume mount to map the load_test file.

   volumes:
     - ./grpc/service/default_routes_load_test.json:/usr/src/app/default_routes.json

3. Ensure the DEFAUlT_ROUTES env var is true so the service will start the sim and the PRINT_SIM_LOGS is true so the container will print the simulator output.

   environment:
     DEFAUlT_ROUTES: true
     PRINT_SIM_LOGS: true

4. Happy Load Testing!