The ad service now returns ads matching the categories of the product that is
currently displayed. Changes in this commit:
- List all products' categories in products.json.
- Pass the current product's categories from the frontend to the ad service when
looking up ads.
- Store a statically initialized multimap from product category to ad in the ad
service.
- Return all ads matching the given categories when handling an ads request.
The ad service continues to return random ads when no categories are given or
no ads match the categories.
* Introducing super basic health check for cart service
- Generated C# proto implementation for grpc health check
- Moved all C# protos to a dedicated folder
- Implemented basic health checking to ping CartStore (which is Redis in default implementation)
- Base plumbing for health checks
* Introducing super basic health check for cart service
- Generated C# proto implementation for grpc health check
- Moved all C# protos to a dedicated folder
- Implemented basic health checking to ping CartStore (which is Redis in default implementation)
- Base plumbing for health checks
* Changing Ping health probe to call Redis Cache Ping method
1. Making sure we re-create redis connection upon disconnect
2. Fixed local cart store implementation to handle updates (useful for testing w/o redis)
3. Fixed windows scripts to work against redis correctly
1. Added more telemetry around starting redis cache
2. Now if you don't specify redis cache address via command line
or environment variable, it will run with local cart (no redis).
This is useful for debugging purposes
1. Added more telemetry around starting redis cache
2. Now if you don't specify redis cache address via command line
or environment variable, it will run with local cart (no redis).
This is useful for debugging purposes
Now GetCart returns an empty cart for non-existing user
(user that haven't added anything to the cart before)
Added test to cover that
Also enhanced windows script for running cart service locally.
Now we have two options:
- Running the service and redis locally (assuming redis emulator is installed)
This is good for easier local debugging and troubleshooting
docker_setup local
- Running the service and redis in two separate docker containers
This is good for better simulation of what will happen in the cloud