My path of learning-to-build web app.

“It is a great idea, but how can I build it?”

Reason to learn-to-build

To be fair, I am not a sophisticated web app developer. My goal of learning how to build web apps isn’t really about working for any company on the subject. The purpose of learning-to-build is to convert my ideas into reality. I want to create stuffs on web that I love. And, if there are people out there who also like my stuff, that would be awesome.

I am a strong Python coder, but it still wasn’t an easy decision to pick the coding path. Web apps had a huge scope, and there are so many things I would need to master. On the other hand, low/no-code path seems much easier that I can quickly create a prototype or MVP. However, after spending two weeks trying to make sense of this path, I figured I should just grind the code and avoid the no-code path as a starter. I have to admit that I didn’t like the fact I had to learn how to not code to build web apps.

For the past 7 months, I have been consistently learning to build web apps. While I am still learning it, I’d like share my experiences so far. I did some light journalling on Notion, and I am sharing it 🔖 here in case someone wants to read it.

Client-Side

I started with basic elements, e.g., HTML and CSS. I learned them through the curriculum of responsive web design on FreeCodeCamp, which is a fantastic resource for getting started with web development.

I continued with a full exposure to the chaotic JavaScript world, where I struggled with a lot of notions, e.g., Promise/async/await, DOM manipulation, and all kinds of nitty-gritty.

During that period of times, likely a couple of weeks, I really enjoyed digging into depth to understand the language at its core. I learned a lot of about topics, e.g., Event Loop, Microtasks, Garbage Collection, etc in JavaScript.

Followed the JS 🎢, I chose not to worry too much about TypeScript + UI design at the moment. I was really struggling to navigate through the massive frontend universe, figuring out all the dark magical JS Frameworks, which was so intimidating and confusing. I found Youtube videos were extremely helpful in this regard. As a newbie, listening to experienced developers talking about use cases and a lot of nuances was the best way I think.

I finally lent my heart to the rockstar 🎸 Svelte, which is more than just an awesome framework but also a language/compiler, a pure magic when I understood how it actually works. It also got me interested in knowing complier and intepreter for programming in general, but that is another story to share at some point.

In-between Cient and Server

What about other pieces? How about the full path?

I was so happy to learn Svelte. It comes with a amazing tutorial and REPL that facilitates the learning experience. After a few days of getting into Svelte/kit, I was puzzled by the other side of the business. That is the backend or the server side.

To be clear, it wasn’t that I didn’t know there exists a entire parallel universe of the web. After all, APIs, databases, and all kinds of server-side stuffs are very well known in the industry. But, the thing that made me extremely confusing was all these frontend guys trying to sneak into the backend.

For example, when I studied Sveltekit, it got me very confused when seeing e.g., “Sveltekit is a full-stack framework”. Then, there came a whole bunch of other stuffs that could easily drive anyone crazy. To name a few, Next.JS for React.JS, Nuxt.JS for Vue.JS, and Sveltekit for Svelte.

On top of that, there are so many tools, for bundling, e.g., Vite.JS, database, e.g., Supabase, hosting, e.g., Vercel, and many more. Then, we have our usual suspects, the champions in the dedicated backend framework world, e.g., Django for Python, Express.JS for JavaScript, etc.

Back to the topic of “Sveltekit is a full-stack framework”. For the sake of simplicity, I treated Next, Nuxt, and Sveltekit as pseudo backend frameworks, as I realized they mostly try to make the process of building UI/UX intensive apps and the experience of using the app smooth. These full-stack frameworks handles server-side rendering, routing, and many other things, which were traditionally handled by the dedicated backend frameworks.

These frameworks are also deeply engaged with the design of the app, such as Single-Page Application, Multi-Page Application, Progressive Web Application, and so on.

Server Side

While I was still learning Svelte and its full-stack buddy, I started exploring the backend universe. By backend, I refer to the server-side business, with APIs, databases, and all that. It was very important to me as, for example, I needed to be able to embed my awesome algorithms in my app, and I needed to be able to deploy my app so people can use it.

“It is a lot of stuffs going on.” I questioned why I signed up for the course of the journey.

Not every app requires a dedicated backend. A lot of apps can be engineered with a combo of e.g., svelte + selltkit. However, if I want to build compute/memory-bound stuffs, like ML/AI models/algorithms, I need to build a solid backend. Even just to store the data without crashing the client, a backend is a must.

The backend was a puzzle, with the pieces all over the place. Among all the pieces, I personally think Authentication and Authorization are the hardest ones. As a matter of fact, as a beginner, to distinguish between these two guys was already a tough task. Fortunately, a lot of service providers, even some of the backend frameworks, have Auth built-in, so I wasn’t worrying about how to create them from scratch. But, understanding how they work and how to use them is still very important and … not easy.

Another hard piece is database. I had been mainly using PostgreSQL at work for many years, but I wasn’t a database expert in backend. I knew SQL and can even create a very complex function with PostgreSQL. But, the database in backend universe is way more complex than my practice.

For the database, I like Supabase. It uses PostgreSQL as its database with all kinds of features, including vector db through postgres pg_vector, which is an essential feature for developing any AI related apps. I am also using its hosting platform (free tier obviously), so I get to use its built-in authentication and other cool features like storage. I use Python for backend, right? So, for manipulating data through database, I use both SQL and ORM, where my favorite ORM is SQLModel.

An very important decision to make is to pick my language for backend. It would be nice to use one universal language for both sides of business, and that is the god blessed JavaScript. While I had no problem of using that, I personally felt more confident in using Python for the backend. Indeed, it is not just about confidence. Python is a native data-science/machine learning language, but there wasn’t much good support for JavaScript. There wasn’t even a numpy equivalent for JavaScript. JavaScript’s asynchronousness comes from its nature, but Python isn’t that bad in async with, e.g., asyncio.

The choice of language for backend is a big decision, as it dictates the tech stack, the way you code, and even the way you think. When it was about the time to choose my backend framework …

I could actually choose a more comprehensive, full-blown, full-battery framework like Django. But, as long as I started studied with FastAPI, I felt in love with it. It is really neat and amazingly fast. Its features were neither too much nor too few. It was just about right! The documentation is one of the best I have ever seen for any open-source project. The integration with Pydantic and Uvicorn makes cooking up an API a pure joy. Overall, it is probably the best Python backend framework with a perfect balance between developer experience and functionality.

The learning process of backend wasn’t easy. After a couple of weeks, I pretty much finished reading and experimenting every bit of juice I can extract from FastAPI documentations as well as other online resources.

Did I make any working stuff?

Once I felt that I learned enough of HTML, CSS and naive JavaScript, as well as enough of API and database, I committed to my first non-toy project.

For some reason, my team (at work) lost access to a very nice vacation planner, where my peers had been reporting their personal holidays, sick days, and vacation days for many years. It wasn’t until I found out many other teams also had same issues that I realized it could be a good opportunity to put my study into serious practice.

I spent a week without doing my usual stuff at work, focusing entirely on making my first full-stack app. I didn’t use Svelte as it could only slow me down. I sticked to the naive JavaScript for reactive/dynamice piece, and it turned out just fine. For backend, I used PostgreSQL and FastAPI to handle user authentication, basic CURD, and some basic API functions.

It was the following Monday, I posted a short MP4 video of demo in a few slack channels at work before lunch. When I came back from lunch, I was totally surprised there were many people responding to the post and DM me. A lot of teams wanted to use my app! How about that!

In the end, there was only a few of them willing to make commitment to my vacation planner. The major issue I had was to figure out how to get the app hooked with the company’s authentication. It was very complex as I went through the documentations and talked to the dedicated team, and it was clearly beyond my scope.

The end of the story wasn’t very bad. One team signed up for the vacation planner (and my team did too), and they had a experienced backend deverloper who knew all the dirty details of dealing with the company’s auth process. (They actually modified the app a lot so to make it much safer to use at work. After all, I wasn’t a very trustworthy web developer regarding security.)

Here is the demo of the app (This is my insecure version before the enhancement was made by the other team.)

The end of this story, but more to share later

That’s about everything I wanted to share for a blog post requiring 10 minutes of reading.

However, this is not the only things I wanted to share, and I plan to write more articles to report my detailed works and progress, with a hope that my experience could help others who wanted to break into the field to do fun works.