#Event Logging, Caching and Throttling

I've just finished implementing these features.

Event Logging is a new feature that allows us to debug different methods on the bridge by hooking the events at client.EventLog, and examining the messages logged there.

Caching was already present on the previous version of the bridge, but it now supports multi-threading, and identical requests against the API are only made once even when using parallelism.

Request throttling wasn't part of the bridge up until now, the request throttler works similarly to other throttlers out there, providing a configurable sliding window of three seconds during which up to 30 requests can be executed, and a configurable maximum of 15 concurrent requests against the API.

You can read more about caching and throttling on BridgeStack on the wiki entry at GitHub.

Event Logging, Caching and Throttling

I've just finished implementing these features.

Event Logging is a new feature that allows us to debug different methods on the bridge by hooking the events at client.EventLog, and examining the messages logged there.

Caching was already present on the previous version of the bridge, but it now supports multi-threading, and identical requests against the API are only made once even when using parallelism.

Request throttling wasn't part of the bridge up until now, the request throttler works similarly to other throttlers out there, providing a configurable sliding window of three seconds during which up to 30 requests can be executed, and a configurable maximum of 15 concurrent requests against the API.

You can read more about caching and throttling on BridgeStack on the wiki entry at GitHub.

#Event Logging, Caching and Throttling

I've just finished implementing these features.

Event Logging is a new feature that allows us to debug different methods on the bridge by hooking the events at client.EventLog, and examining the messages logged there.

Caching was already present on the previous version of the bridge, but it now supports multi-threading, and identical requests against the API are only made once even when using parallelism.

Request throttling wasn't part of the bridge up until now, the request throttler works similarly to other throttlers out there, providing a configurable sliding window of three seconds during which up to 30 requests can be executed, and a configurable maximum of 15 concurrent requests against the API.

#Event Logging, Caching and Throttling

I've just finished implementing these features.

Event Logging is a new feature that allows us to debug different methods on the bridge by hooking the events at client.EventLog, and examining the messages logged there.

Caching was already present on the previous version of the bridge, but it now supports multi-threading, and identical requests against the API are only made once even when using parallelism.

Request throttling wasn't part of the bridge up until now, the request throttler works similarly to other throttlers out there, providing a configurable sliding window of three seconds during which up to 30 requests can be executed, and a configurable maximum of 15 concurrent requests against the API.

You can read more about caching and throttling on BridgeStack on the wiki entry at GitHub.