Stock Price Movement Reflections

Jason Oh — Fri, 06 Jun 2025 21:50:02 +0000

Continuing on with improving my backend development skills, I decided to engineer a project using these new and unorthodox approaches to application development: Serverless & IaC. Here are some of my reflections regarding the experience and you can preview my project via: https://github.com/Jason0h/stock-price-movement

Part I: Serverless is Cool!

This project made use of a variety of AWS serverless services. Most notably, Python code was written for AWS Lambda. AWS Lambda is cool because as a Function as a Service, it removes the headache of having to learn and use a web framework such as Flask or Spring in order to write logic that serves requests, and then wrapping of all that in a container. With Lambda, you write plain Python code and deploy it.

When engineering my last project, I used the AWS console to provision my resources (in order words via many mouse clicks). But having learned about IaC coolness, I aimed to write a CloudFormation file that when deployed via the AWS SAM CLI would automatically provision the resources I needed. Frankly speaking, writing the configuration file was quite painful and took pretty long, missing the guiding information embedded in the console. However, the philosophy is that from now on, someone could create a copy of my infrastructure with a single key press. That being said, on future projects i'd probably provision resources via the AWS console first and then reverse engineer a CloudFormation file from that.

Part II: Thoughts on Writing Tests

Writing tests for code that is pure logic is pretty straightforward. Validate the functional output with the expected output. However, things are not as clear when what you're trying to validate is a side effect. For instance, in my Shorten URL project (for which I previously made a post about), I had to reason about how to test my database interaction logic. The key to the solution lied in a technique called "mocking", where I'd mock the actual database with an in memory database whose contents were cleared between tests, with the help of a testing framework (JUnit) that facilitated mocking.

I had to do something similar with this project, for instance with testing lambda logic that interacted with DynamoDB. Fortunately, AWS provides a Python library called moto for mocking AWS resources locally. With this I could run my lambda logic as many times I wanted locally without having to worry about disturbing my production database. It is clear to me that engineering application tests is an art in its own right, and ironically can sometimes be harder than writing the actual logic itself. It's definitely something that I will find worth leveling up on in my career.

Shorten URL Reflections

Jason Oh — Tue, 03 Jun 2025 21:43:46 +0000

In getting my hands dirty with backend development, I had tasked myself with engineering a Java based URL shortening service akin to TinyUrl. Here are some of my reflections regarding the experience. https://github.com/Jason0h/shorten-url

Part I: Deciphering the Magic of Spring

Trying to understand Java code built on top of Spring can initially be a deeply frustrating experience. That's because there's no control flow to be traced. There're definitions of classes but no evidence of their instantiation to be found. It's as if the application developer has written themself a library but has forgotten to take the final step to use said library. But the code works, so what sorcery is going on here...

The key to understand what's going on is Spring's principle of Inversion of Control. Simply put, you write the "template" code that defines business logic (e.g. mapping http requests to responses) but nothing much afterwards. Instead, Spring handles the instantiation of your templates ("Beans" in Spring terminology), piecing them together, and dynamically calling them when appropriate. In other words, Spring abstracts away control flow from being the responsibility of the programmer, making it magic that happens in the background. This concept was quite strange at first, much like driving a Tesla in autopilot, handing over control from the human to the machine. Accepting its strangeness, however, accelerated my understanding of Spring.

Part II: Navigating Deployment on AWS

A Spring app on its own can only persist and serve data locally. Thus, I had to familiarize myself with AWS for the purpose of deployment. After creating an administrative account on AWS, I was bombarded with 100+ services and had little clue as to which was appropriate. Thus, what I anticipated as being a quick process ended up being a weeklong rabbit hole into learning about the AWS ecosystem. Notably, I had found the concept of serverless Lambda functions to be especially fascinating (my next project will most likely be using it). Nevertheless, I reasoned that deploying a Docker container of my app to AWS AppRunner and porting my SQL schema to AWS RDS would be the most appropriate. While I had thought deployment would be a minor part towards the end my project, exploring the AWS ecosystem and online console was itself an important journey.

DEV Community: Jason Oh

Stock Price Movement Reflections

Part I: Serverless is Cool!

Part II: Thoughts on Writing Tests

Shorten URL Reflections

Part I: Deciphering the Magic of Spring

Part II: Navigating Deployment on AWS