[AirClass Dev Log 2] Why FastAPI and Svelte: Criteria for the First Prototype

What this post covers

• The criteria I used for the first AirClass prototype
• Why I chose FastAPI + Svelte instead of Spring + React
• Why I postponed decisions about DB and Redis
• Why I first imagined running the system from the teacher's laptop on a local classroom network

As I wrote in the first post, AirClass started from real inconveniences in tablet-based teaching. The next question was natural: what kind of prototype should I build first to test the problem?

This post summarizes the first design decision.

The stack familiar to students was not the stack I chose

Students at Busan Software Meister High School often use Spring for backend work and React for frontend work. That combination is also common in the job market. At first, I wondered whether I should follow that more familiar industry stack.

But AirClass was not a portfolio team project. It was a tool I wanted to use in my own classes and revise quickly. The most important criterion was not whether the stack was popular, but whether I could read, modify, debug, and test it quickly.

So the conclusion was clear. For this project, I needed a stack that matched my classroom workflow and maintenance style.

Why FastAPI for the backend

The first choice was FastAPI.

The reason was simple: it was the API framework I had used most often in real automation work. Building a classroom prototype with a familiar tool was more realistic than learning a new framework while also solving classroom problems.

There were three main reasons.

1. It was already familiar

I had used FastAPI for small APIs and practical services. That made it easy to start a prototype without spending too much energy on framework setup.

2. It was fast and simple

The first version of AirClass did not need to be a large enterprise-style service. It needed to react quickly during class. At that stage, the ability to create and test endpoints quickly mattered more than a large architecture.

3. The code was readable

Readability was especially important because I was also using AI-assisted development. Generating code quickly is not enough. I still need to read it later, debug it, and change it during preparation. FastAPI made that easier for me.

Why Svelte instead of React

For the frontend, I chose Svelte rather than React, even though React is more familiar to many students and more common in industry.

The reason was again practical. I cared less about which framework was more widely used and more about which framework let me express the screen clearly with less code.

1. Less code

In AI-assisted development, code volume is also a cost. More code means more to review, more places to fix, and more room for mistakes. For a classroom prototype, shorter and clearer code was a real advantage.

2. A structure I could understand quickly

For me, Svelte screen code was easier to read at a glance. State and markup were close together, and many interactions could be written directly.

3. Simpler debugging

The first version of AirClass was not meant to show off frontend architecture. It had to be usable in class. For that, a simple and debuggable structure mattered more.

DB and Redis were intentionally postponed

I did not want to require DB or Redis from the beginning. Those tools are useful, but they should enter the design when the need is clear.

The first prototype needed to answer questions like these:

• Does the student screen follow the teacher screen reliably?
• Does being able to revisit recent content actually help students?
• Do short responses and interactions fit naturally into class?
• Is the local network fast and consistent enough?

If I designed a large storage and cache layer before answering those questions, the surrounding infrastructure could become larger than the real classroom problem.

The most important deployment model was a local classroom network

The most important design choice was not the framework, but the deployment model.

The first model I imagined was this: the teacher runs the app on a laptop, and students connect from the same classroom network.

There were three reasons.

1. Student data can stay closer to the classroom

Even a classroom tool can touch student data. Reducing external service dependency felt safer, especially in the early stage.

2. Response time can be faster and more consistent

A classroom tool cannot simply respond "eventually." When the teacher changes something, students need to see it immediately. A local network is often better than a remote server for that first experiment.

3. The teacher is the operator

This project is closer to a teacher-operated tool than a school-wide information system. So it made sense to begin with something the teacher could open and run directly.

HTTPS is inconvenient, but manageable

Local deployment has limitations, especially around HTTPS and certificates. Some browser features require a secure context.

Still, I did not see this as impossible. Internal certificates and controlled classroom devices could make it manageable. More importantly, building a perfect cloud service was less important than testing whether the tool worked well in the classroom.

The first prototype direction

The first prototype was therefore simple.

• Backend: FastAPI
• Frontend: Svelte
• Storage/cache: add DB or Redis only when needed
• Deployment: teacher laptop, classroom local network

The goal was not to show off a modern stack. The goal was to test a real classroom problem with tools I could understand and revise quickly.

Closing

The first design of AirClass was not about following industry standards exactly. It was about choosing tools that let me try something in class, read the code again, and change it when necessary.

That is why FastAPI, Svelte, and local-network deployment became the first direction. In the next post, I will write about how the first display-oriented attempt actually unfolded.