In this post, I'll share how I implemented a visitor counter on my website, which updates with each page visit. This feature though simple in concept, presented a unique set of challenges and learning opportunities in working with Javascript, AWS services, and understanding CORS. I'll also delve into the testing methods I employed to ensure the system's robustness.
Here's the page:
https://www.donangeles.com/and here's the link to the previous chunk: Chunk 2: Crafting the Backend - Visitor Counter
Show the Counter
The visitor counter's purpose is to update with each visit to the site. While the concept sounds simple, it took quite some time to figure out. The key to displaying the counter is using Javascript which makes a POST request to the APIGW which hosts the Lambda function. Then, the response should contain the counter. Although I have a background in Javascript, revisiting the concepts, especially in making HTTP requests. This is a quick reference on how that's done.
I initially utilized a plain JS fetch request which by default makes a GET request. While it was successful in getting a value to show on the website, using a GET request to update a value in the DDB is not semantically correct as it is designed for retrieving values from a server and POST is designed for submitting values. This is against best practices when making HTTP requests since it may have several implications for security and unintended updates to the server because of caching and pre-fetching.
CORS
As this is my first deployed live website, I encountered that invested considerable time understanding and implementing it. CORS, or Cross-Origin Resource Sharing, is vital for allowing a web application to request resources from a different domain. I found the following resources incredibly helpful:
These helped in configuring CORS settings in Lambda and API Gateway to allow for to my website to access resources that are not in its domain. Being able to properly configure CORS settings was the breakthrough to be able to finally display the counter on the website. It is essential to check the Network tab when inspecting the webpage for errors and to ensure that the Lambda function logs errors so that the browser can display them for troubleshooting as well.
Onto Testing
Quite honestly, the system works as intended without developing and performing tests. But since this is a requirement of the project, I took the opportunity to learn more about it and realized that testing, although non-critical for the system to function, is an essential aspect of any system being developed and a crucial skill for any engineer.
I utilized two types of testing methods which are unit tests and smoke/integration tests. Unit tests focus on testing the smallest parts of the application like the Python function on Lambda, that they should return values as expected based on the function and not necessarily an actual output of the system. The unit tests I have thus far create a mock version of the database and cover the following:
Increment of the counter
Handling of non-existent table
Handling of rejected GET requests
Proper return of status codes for each test
On the other hand, integration tests, are meant to test if the different parts of the system infrastructure are working and provide the expected actual output. My integration test the following using the live API:
API returns incremented value
DynamoDB contains the incremented value
API rejects GET requests and is handled
Ideally, more tests could be done to cover all cases that may render the system unusable and this can be made over the next versions of the project. The tests can be viewed here.
Reflections and Future Improvements
This chunk taught me that time-consuming tasks can offer the most significant learning opportunities. One aspect I'm looking to improve is the counter's incrementation with each page refresh, which I aim to refine in future updates, where counts consider unique visits.
I'd love to hear your thoughts and suggestions on this project! Feel free to reach out and thanks for reading!