Aeron

Posted on Sep 4

Blog #2: What I Learned After Building My First Real App

#python #fastapi #webdev #beginners

Hey guys, it’s Aeron here.

This week officially marks 100 days in this journey, so I decided to write a blog about it.

This is not going to be an incredible learning lesson or a blog that will help you become a coder right away. Instead, this one is more about all the lessons I’ve learned throughout the journey so far.

If you’re also starting this journey from scratch like me, I hope this can save you some time.

The Context

Since my last blog, which I wrote after finishing the CS50 course, it’s been about two months now.

But tbh, my journey has been very up and down.

During the first month after CS50, around Day 30 to Day 60 or 70-ish, I was overwhelmed with my old job. That was my last month there, so there was a lot to do and a lot to transfer as well.

For anything I do in my life, I always try to do it with the highest level of responsibility and professionalism possible. So I was really packed back then, and that’s why there was a month-long gap in the journey where I barely coded anything.

This month, from around Day 70 until now, I’ve been fully focused on the journey. This is finally when I’ve been able to learn a lot.

If the first 30 days were mainly about learning how to code, this month has been more about learning how to actually build, test, and run a real app in production.

To do that, I first learned how to create and run an endpoint with FastAPI. Then I used Render to push it to public production. I also created a frontend with Streamlit.

The other half of the month was more about polishing the app and making it feel more professional, and more like a real app out there.

The three most important things were packaging the code with Docker, changing raw SQL to an ORM, and using Alembic to manage the database.

And of course, along with that learning curve came many lessons that I want to share in more detail below.

The Lessons

1. A small change could lead to an app crashing and several code refactors

I remember around two weeks ago, when I was in the middle of refactoring the raw SQL to ORM, I changed the class for the input information from class Transaction to class TransactionIn.

The initial purpose was simply to distinguish it from the other classes because after the refactor, I needed to add two more classes to identify the output: class TransactionOutMessage and class TransactionOut.

I barely thought about anything else back then, but it turned out to be a disaster.

The POST /transaction endpoint couldn’t run because it was still calling the old class.
Pytest started showing several failures because the tests could no longer call Transaction.

I needed to sit down and fix everything for a while.

That was the moment I really remembered.

After that, anytime I’m about to change something, I always think about what could be affected if I change this.

It sounds like a small thing, but for me, it was one of those lessons that only really makes sense after you break something yourself.

2. Pytest is green, but the new code actually hasn’t been tested yet

Before using SQLAlchemy like I do now, I was using psycopg2 for my main app.

That means for every request, I created a new connection, used it, and then closed it.

The code is much better now after I refactored everything to use session with SQLAlchemy. Instead of creating a new connection every time, the connection is already managed in the pool. I just borrow one, use it, and then return it back to the pool.

The thing is, after spending the whole day refactoring tons of psycopg2 code to use sessions in the main app, I checked pytest.

13/13 green.

I thought the code was good back then, until I suddenly realized:

Why haven’t I refactored the test app, but it’s still green?

It turned out that in the test code, I had dependency_overrides.

That meant my tests were never actually testing the code I had just refactored. They were still running against the old psycopg2 implementation.

That was another key lesson for me because I believe testing is always one of the most important parts, along with coding.

Getting the code to run is only part one.

Making it pass all the tests is the next step before putting it into production.

Thoughts

So yeah, those two above are the two biggest coding lessons I wanted to share from the last two months of this journey.

If there’s anything else I want to share, it would be this:

Always stick with your original plan, keep your promise, and never lose faith in yourself.

Tbh, there have been more than 10 times when I thought about quitting and going back to the blockchain industry.

But then I think, the journey has only just started.

Keep pushing, and the result will come sooner or later.

That’s it, guys.

See you soon in the next blog!

DEV Community