A little adventure with PI
Recently went through an excellent article on PI from Peter Trüb on PI. He has calculated 22.4 trillion digits of PI and also generously donated the digits. You can have a look at his blog to get more details. I thought of taking it and then using it to have some fun. I thought of trying out the random walk experiment of PI. To do that I had to do a few things.
1. Create a PI service that returns 1 Billion digits of PI by position
2. Create a webpage that can consume this endpoint and produce a random walk.
Simple!!! Isn't it?
Before I go with the other details let me show what I got
This is the image that the webpage generates from my setup. This is a modification of the generous sample script that was shared by Peter. I have modified it a bit to suit my needs but the original credit goes to him.
Anyone who wants to render it on their own can visit the page.
The setup
Below is the simple architecture that I came up with
Let's break it down
1. API Gateway: The window to the world is the API Gateway. I am using Kong API gateway. Kong is really easy to use and quick to set up. Kong needs either Postgres or Cassandra backend. I am going with Postgres. API gateway gives a lot of options like it allows me to keep my other services private and still map the endpoints to the external world. It allows me to do rate-limiting on my API so that no one can abuse. It also allows me to do other things like monitoring, authentication, and authorization etc.
2. Pi Walk Webpage: The piwalk webpage is a static page. It is created using BabylonJS. The page is hosted in AWS s3 as this is a static webpage and served through the API gateway itself.
3. Database: Postgres database is used for multiple purposes. It is used by KongHq API gateway for storing configurations and also I am using it to store some metrics, like which position of PI is called how many numbers of times. This data is stored in the PiTable.
4. Cache: I am using Redis. Redis is used for caching the response and also it is used by KongHq for rate limiting purpose.
5. Pi Service: Considering I can't spend a lot of processing power and money but I want good performance the Pi Service is written in C++ using Bun as the database abstraction layer. The service endpoint is exposed through KongHq
The endpoint looks as follows:
http://api.brainlesslabs.com/api/getpi/<position>. The position tells the digit position of PI to fetch. This is a GET request. The returned result is just a number. For example, http://api.brainlesslabs.com/api/getpi/4 will return 1.
The Pi Service is a simple service as follows
The Pi Service gets the value of the position of PI from a local key-value database. When a digit is fetched the entry is made in the PiTable on how many times the digit has been fetched. For both of the activities, I am using Bun as the abstraction layer. The key-value store is a custom key-value store that I am currently implementing as a native key-value store for Bun (More on this later once I am done with that and tested it better).
Conclusion
It has been a fun experiment and setup. A lot of learning on the way. I will be further doing some fun experiments with PI and also e. But more on that later.
Feel free to use the PI service that I have exposed, just be generous and do not abuse.
