Ticket market project: notes on a backend challenge (part 1)

Introduction

In the end of last year I've decided its time to try my shoot at doing something bigger. In my 8 months short life as a developer, I've only had my hand at doing small projects to apply my learnings at the time. As 90% of the developers starting, I had the tendency to drop the work I was doing once I was no longer stimulated by the code I was writing. So, this time I decided that it was time to overcome the anxiety of building a full backend project.

The project could be summed up as a Ticket market where every user can buy first and second hand tickets and pay for them inside of the app. It aimed to be a smaller scale ebay app for tickets only.

I decided to build something using the microservices architecture and TypeScript so I could try my hand on both. In the way, I ended up using Docker, k8s, skaffold, Redis and NATS Streaming Service for the first time.

Looking back, I spent so much of my time just trying to learn the basics of everything. The documentation and tutorials were overwhelming but I really can't compare myself as a developer to before this project. Needless to say that everything was worth it. The learning process of this past few months can be summed up in these notes.

Decisions: giving up on the frontend

One of my biggest anxieties writing apps was the thought of needing to build a frontend to every project. Knowing that I wanted to specialize solely on the backend on web development and that me as a person always tried to walk the furthest away from any design-based work, building the graphical side of apps was the main bulk of my worries.** This used to take up so much space that I couldn't be worried with anything else**.

To tackle this, I decided to give up entirely on the graphical side for this project. The liberty of not having to worry about that was one of the reasons I kept motivated until the end, only having to worry how not to screw up the backend code (and boy, that was hard!).

I guess that focusing on how much i didn't know about the things that I really wanted to learn payed off in the end.

TypeScript. What?

My relationship with TypeScript was always a bit...non-existing. All the popular roadmaps available for web development gave me a detailed picture of frameworks such as the only trinity of React, Vue and Angular but TS was different thing.
As a self-taught developer on began with JavaScript only, having a strongly typed version of JavaScript sounded way more work than necessary to accomplish the same end product (having my schemas take up double the space with the added complexity was hard thing to have at first). Some of the amazing things I've learnt were:

1. Typed variables and functions kept me from running into silly bugs, which saved me from many frustations.
2. Interfaces and enums are precious little things that helped the consistency of my code. Also, its existence and use lead me into a more consistent use of OOP.
3. The built-in documentation of methods on classes is also chef's kiss 👨‍🍳. Not remembering what properties a class or method had and having everything in a click's distance bridged the gapped that existed between me and my understanding of (poorly written) documentation

(Don't) follow the hype: microservices

One of the earlier decisions for this project was to build this project having in mind the microservices architecture. My mentality was "hm, if this is the industry sweetheart and prime architecture pick might aswell have a go at it". Soon I found that I'd be using it to see its limits. A choice always gives up something to build up on something else. That's the basic thought behind architecture decisions. There's not a one size fit all pick and eventually I saw that I'd be using microservices to learn its limits.

I read somewhere that if your app scale is not asking for microservices, don't use it. I learnt it the hard way. Some notes on it:

1. First of all, the repetition of code is much higher, since I was having to start a new database for every service with duplicated models everywhere. This was a decision to minimize the dependency between services, but boy, if it is redudant.
2. CONCURRENCY ISSUES. CONCURRENCY ISSUES everywhere 😒 . The building of the event-bus was definitely a struggle. Resolving the inevitable latency problems was a bigger one.
3. To help with the duplication of code, I decided to publish a common npm module so all my services could use it, but even the idea of not forgetting to updated every service was something I wasn't doing reliable

With this I don't mean to trash the microservice architecture, I'm aiming to find it's silverlining. If one hand, this added complexity for a prototype project was way to much, I also learnt much more than I would if I didn't do it. And I understood that once I had the foundation of the app built-up (event-bus, common module, communication setup), the added complexity of building a new feature was way smaller than it would've been with a monolithic app.

So what now?

Looking forward, I want to finish this a document my learning process as much as possible. Being able to share it and to consolidate my learnings with writing is an amazing feeling by itself.
I'll be prepping this app to its delivery, the last step, while deciding what to do with its frontend (do I ignore it? do I look for someone to collaborate with me?)

I'll be posting another article about this project and my relationship with it, still. You can also contact me through my twitter, email, discord, dev.to or hashnode. It would mean the world to find people whom I can share these feelings and thoughts with! 🎊