Skip to main content

Redis website had some out of date references

I picked the wrong place to refresh my Redis know-how 

I started this post with the intention of making some notes about my experiences with learning more about how to apply Redis to solve a few common problems, but I stumbled across some out of date content and odd behaviour of the redis.io website so I'm making some notes about that instead.

Rate limiting

Java sample code missing 

This was of interest as it sometimes comes up in interviews, so I wanted to look into an elegant solution.

https://redis.io/learn/howtos/ratelimiting

As I am mainly a Java developer, I followed the instructions for Java but didn't get very far as the repository that is mentioned seems to have been cleared out.

The commit history seems to indicate that the repository has not been updated for a couple of years, so this wasn't a great start.

Python. NodeJS and Ruby all show as still having code in their Github repositories.

Website connection timeout

The references section on the rate limiting howto page linked to pages that result in timeouts.
 

I don't know the details, so I'm speculating that somewhere in the configuration between Cloudflare and redis.io the "not found" situation goes into a timeout black hole. To test but not necessarily prove that theory I have attempted to access a non-existent page under the redis.io site and observed that it results in the same timed out error.

What have we learnt?

Not much about Redis, but a little bit about some grey areas of the redis.io website.
 
If you're applying a content delivery network (CDN) to front for your website then be sure to pay attention to how errors will be handled.
 
Handling of "not found" URLs isn't a difficult optional extra feature to have in place.

Reported to the AI Chatbot

Unsurprisingly the AI Chatbot on the redis.io site wasn't able to reason about the Cloudflare configuration or the empty Github repository when I mentioned the issues.

Comments

Popular posts from this blog

2022 - A year in review

Just a look back over the last 12 months. January I moved back to Christchurch to live, after having spent a few months further south since moving back from London. Work was mainly around balancing other peoples' understanding and expectations around our use of Kafka. February I decided that it would be worthwhile to have a year's subscription for streaming Sky Sports, as some rugby matches that I would want to watch would be on at time when venues wouldn't be open. Having moved to Christchurch to be close to an office, now found myself working from home as Covid restrictions came back into effect across New Zealand. March Got back into some actual coding at work - as opposed to mainly reviewing pull requests for configuration changes for Kafka topics.  This became urgent, as the command line interface tool that our provisioning system was dependent on had been marked for deprecation. April   Had my first direct experience with Covid-19.  I only went for a test because ...

Speeding up Software Builds for Continuous Integration

Downloading the Internet Can you remember the last time you started out on a clean development environment and ran the build of some software using Maven or Gradle for dependency management? It takes ages to download all of the necessary third party libraries from one or more remote repositories, leading to expressions like, "Just waiting for Maven to download the Internet". Once your development environment has been used for building a few projects the range of dependencies that will need to be downloaded for other builds reduces down as the previously referenced ones will now be cached and found locally on your computer's hard drive. What happens on the Continuous Integration environment? Now consider what goes on when Jenkins or your other preferred Continuous Integration server comes to build your software. If it doesn't have a local copy of the libraries that have been referenced then it is going to pay the cost of that slow " download the Internet" p...

Designing systems - The "ity"s That Limit or Enable Profitability

Introduction This started off as a little aide-mémoire to get my head into the right space for preparing for an interview. It's not an exhaustive list, and twists terminology that has been used to represent other things (see:  to Velocity), so don't treat it as a text book reference to work from. Most of the listed points can be associated back to so called "non-functional requirements" - NFRs. I don't like that particular terminology, so alternatively we might consider them as dimensions of the quality of the sytem. Usability "If you build it, they will come" should come with a provisor, "... but if it's awkward to use they'll soon go away, and might not come back." Security All of the aspects that combine to protect data from being seen or manipulated by anyone other than the intended recipient or sender, and also assuring users that the data has originated from the intended source. Velocity Here I'm cheating a bit by trying t...