DEV Community: mkadirtan

State of Mind Right Before 2025

mkadirtan — Tue, 31 Dec 2024 07:22:20 +0000

The last two years have been quite an adventure for me. Beware, dear reader, as I reflect on my past two years in both mental and technical aspects and also share my plans for the future.

The Mental Aspect

In February 2023, a massive earthquake hit the eastern part of Turkey. It was a very tragic event. I haven't lost any relatives or friends, but many people did.

Witnessing the widespread loss and suffering overwhelmed me. Knowing that many of these losses could have been prevented, I was feeling frustrated. Which got amplified by the news and social media.

I think I experienced what is called secondary trauma, and took a serious toll on my mental well-being. The elections were very close - May 2023, the political climate was very hot, and the work had become very demanding. To relieve, and to distance myself from all these, I took a week off, which didn't help at all.

I had no room to process all that had been happening and got burned out in the end. I started to look for an exit, any kind of exit.

Around that time, a minor issue in the workplace was the final straw for me. I quit my job. Without any job offer, or any plan for what to do next. In hindsight, this was a hasty move and a bit immature of me. However it happened, this marks the beginning of my growth journey.

First, I've looked for jobs abroad. As it is one of the most radical changes a person can have in life, I can leave the country and leave all my tiredness and unhappiness behind me. Let alone getting an offer, I didn't get an interview for two months.

After two months, I was very short on money and needed a job immediately. Despite hearing negative rumors about the "private fintech company", I accepted their offer thinking 'What can go wrong?'. Needless to say, there wasn't too much public information about this private company.

After a long time in the same company, working in another one felt refreshing at first. But I wasn't a cultural fit for the company. This time even though I was excited to work in another company, we just couldn't get along. I don't want to take the blame on this one, because the company had a toxic environment where my colleagues told lies behind me, and didn't even accept me socially, even though I tried...

In February 2024, I got fired out of the blue. Right after that, a colleague called me to say goodbye, he was fired, too. Since I wasn't nearly expecting to get fired, I immediately called my manager and asked if there was a layoff and he didn't tell me. He said, "No, it is just you and one other person. You know due to performance reasons" - which I didn't have and I got pretty good feedback very recently. A couple of weeks later, I saw the news that they laid off a third of the people in the company ( about 100 people ). He just didn't have the heart to tell me...

I immediately started to look for jobs and also called my previous employee Fatih Üstündağ. Though I was quick to quit, we separated in good hearts, and I thought they would accept me back - which they did. For this, I am very grateful.

Here are the key lessons I've learned from this whole journey:

Focus on what you can control,
Approach work and life decisions carefully with clear planning,
Culture fit is very important in the workplace,

Focus on yourself, focus on your goals, get your sleep, eat a healthy diet, and take long walks during the day. Things get a lot easier this way.

Now, I am at peace and determined more than ever!

The Technical Aspect

I've learned a lot during my first year in Getcontact. Then my learning pace slowed, and after a while, I started feeling stuck. I was very comfortable in building Node.js applications. I've learned about databases, performance tricks, etc. The job didn't require much more than that.

I didn't know what I didn't know. In an attempt to broaden my perspective, I started learning other languages, starting with Rust.

Rust: A Promising Start but Not My Type

Rust was all the hype, and I gave it a try. I read the Rust book and created some small programs. I enjoyed the type system, iterators and borrow checker. But I got lost in macros. To me, a program's code should be as explicit as possible.

Macro expansions, unusual async workflow along the initially enjoyable type system getting too complex too fast, I decided to move on from Rust. The ideas behind the language were very novel but it didn't grow in me.

Go: Breath of Fresh Air

In the past, I had a little experience with Go, and I decided to give it another try. I started with A Tour of Go. It is a very lovable language, the simplicity, the ease of use, the package management system... Oh, I feel at home when I write Go. Did I mention the simplicity? It felt like fresh air after JavaScript/Node.js. Luckily, I've had the chance to work with Go in the "private fintech company", and when I came back to Getcontact, I took on the challenge of creating a green field Go project - yay! I am very happy that I am working with Go, and I will probably stick to the language for a long time.

Boot.dev

In one of Primeagen's streams, he endorsed Boot.dev, an online interactive learning experience for backend engineers. There are a lot of bootcamps and online courses for software engineers, but very few are explicitly designed for backend developers. I enrolled in the program and ate the courses in a big bite. It allowed me to sharpen my data structures and algorithm knowledge, along with Go, Python, and JavaScript, as well as a little bit of C. I recommend this course to software engineers of all experience levels.

Master's

I was getting more and more hungry for software engineering knowledge. So, I enrolled for a master's in Software Engineering at Bogazici University - which I also graduated from in 2019. I had a great experience during those years. However, now that I am 28, my perspective changed. I attended the master's for one semester but some things were not as I expected.

Though there are great professors at Bogazici University, the professors are so busy with other things and the master's program is not their priority. So, I decided to take my master's at a different university. I haven't decided yet, but this time I am especially considering private universities instead of state universities.

A Small Visit to Systems Programming: Zig, Tigerbeetle and OSTEP

In another one of Primeagen's streams, I've met with the database that will solve a lot of our problems at Getcontact, Tigerbeetle.

After reading its documentation, watching Joran Dirk Greef's talks, and going through the papers they used when building the Tigerbeetle, I was mesmerized. Since I've also quit my master's, I started to learn more about Zig - the language Tigerbeetle is written in. Also, I started to watch out for Andrew Kelley the inventor of Zig creator of the groovebasin. ( the joke from here ), he is a great software engineer and worth following.

A shout-out to the founder of the Tigerbeetle, Joran Dirk Greef. After realizing the miracles behind the Tigerbeetle, I emailed him about how can I become a better software developer, and he very kindly replied with the greatest resource I've ever read, Operating Systems: Three Easy Pieces, written by Remzi H. Arpaci Dusseau and Andrea C. Arpaci Dusseau. You can search the web for amazing comments about the book, which I won't elaborate on here. Also, I've shared what I've learned from OSTEP in a quick and dirty blog post here: OSTEP Learnings [ Personal ], if you want to check it out.

The Current Aspect

I am more busy than when I got burned out
I am learning a lot more than the last years
Turkey's economy is in very bad shape
Politics are still very polarizing

After changing my perspective on life and gaining mechanisms to cope with stress, things got much easier. I am feeling very calm now, despite working harder and living conditions in Turkey are worse compared to previous years. My journey in the last two years clicked something in my head.

Aside from internal transformation, one smallest change led to the biggest impact in my life. Taking long walks during the day.

Another thing I realized is, it is good to have people you look up to. Primeagen was one of the first people that helped me change my perspective. I know he does some silly things on the stream to enjoy people, but he also shares great life lessons. Well ackshually, his transformation story after the college years helped me gain confidence in what I can achieve.

Another person who has been very influential on my change is my current manager Eser Özvataf, but he doesn't even know that. He never gave me life advice or career advice directly - besides as replies to my questions. His calm and systematic approach to challenges shaped how I navigate around challenges, too. This has been said a lot of times before, but actions influence other people much more than words. As the saying goes, monkey sees monkey does.

The Future Aspect

I've learned that progress is not linear, and setbacks are often disguised opportunities for self-discovery.

For the future, I am committed to:

Setting measured goals,
Pursuing meaningful certifications,
Continuing my personal exploration.

Aside from the certifications, I am also looking forward to enrolling in a master's again. Last year, I promised myself to learn how to skate. This year I will be faithful to myself.

The coming year holds countless possibilities, and I'm eager to face them with the lessons I've learned, the mentors I admire, and a renewed sense of purpose.

This is the state of mind right before 2025, I wish you all the best for the next year! 🎉

What It Means to be a Good Developer?

mkadirtan — Mon, 29 Jan 2024 12:58:56 +0000

Cover Photo by NEOM / Unsplash

A good developer knows how to write performant code
A good developer outputs 10x value
A good developer writes well-tested & documented code
...

The list goes on, but essentially the essence of such statements comes down to that: A good developer is a productive worker.

In this post, I want to challenge this perspective and come up with a new definition of what it means to be a developer.

What does a Developer Has, Other People Don't?

We live in a new age, where ordinary people can build things, not just big factories or corporations. Hacking culture, DIY culture, maker movement whatever you name it, all those arose from a single fact: We can build things, too.

The maker movement is *a cultural revolution that places more value on individuals becoming creators of products or services than merely consuming them - *Sogolytics

Developers has access to build tools, much more than any other industry. In fact, you can argue that developers are the build tools. I believe that is the power we hold.

What Should We Do With This Power?

We should strive to create an open and accessible internet to make sure this power stays in the hands of developers. This is what happened so far, but the reason I am writing this article is to make sure we don't forget what we have.

Everyone wants to change the world, in their own way. We as developers, has the power to make that change happen, in our own ways. Don't wait for someone else to make that change, Do It Yourself. Others will follow, the world is a huge place with so many people living on it. Whatever you want, there are other people that want the same thing. So, go make that change, pioneer new things, change the world just a little bit.

So, What Is a Good Developer

Someone who uses their power, to achieve their personal goals using programming. Who solves their own problems first, who builds their own needs first is a good developer.

Just because there is demand for your skills you learnt throughout the journey, doesn't mean you should aim to improve those skills. Those were not your first concern, when you started out.

Be yourself, don't let the business shape you into something else. You are the pioneer, they are the newcomer. You shape the culture, you hold the power, you drive the locomotive, businesses try to catch the train.

So, why should you let some job requirements define what a good developer is?

Be a good developer, and keep developing. Develop new things, develop existing things from scratch, try out new ideas, challenge the system. The world needs you, as you are.

Introducing feed-rs: Fastest Feed Parser Built With Rust & NAPI-RS

mkadirtan — Tue, 28 Nov 2023 06:47:26 +0000

We all know that Rust is faster than Node.js. But, Node.js performs well for most common operations, such as file reading, database queries, or handling HTTP requests.

Do you know where Node.js sucks and a language like Rust shines? CPU-bound tasks, such as parsing or serializing data, expensive mathematical operations such as encryption or decryption, etc.

I needed a feed parser for my project. It had to be compliant with the spec, however, there are various types of feeds, such as:

JSON feeds,
Atom feeds,
RSS with multiple versions ( RSS0, RSS1, RSS2 ) So, I would much rather parse all of them into a common format than deal with each of their intricacies.

I couldn't find a package in the NPM, that took down the long road and handled these feeds altogether in a single format. Instead, I tried to build one on my own. In my experience, dealing with XML data in Node.js has always been somewhat painful. After realizing that the rabbit hole might go a little deeper than I expected, I started to look for alternative solutions.

Then, I remembered that NAPI exists and I can borrow some code from Rust crates into an NPM package!

Long story short, I've found a beautifully written feed parser in cargo, sprinkled some NAPI sauce onto it, and voila: The fastest Feed Parser in NPM was born.

@nooptoday/feed-rs - npm

Fastest RSS parser with the power of Rust. This package includes Node.js bindings from feed_rs package. Latest version: 0.2.1, last published: 9 days ago. Start using @nooptoday/feed-rs in your project by running `npm i @nooptoday/feed-rs`. There are no other projects in the npm registry using @nooptoday/feed-rs.

npmjs.com

If you are curious about how do you glue the code between Rust and Node.js, here is a very short sneak peek:

#[napi]
pub fn parse(feed_string: String, feed_source: Option<String>) -> Result<models::Feed, Error> {
  let result = parser::parse_with_uri(
    feed_string.as_bytes(),
    feed_source.as_ref().map(|source| source.as_str()),
  );

  match result {
    Ok(feed) => Ok(models::Feed::from(feed)),
    Err(err) => Err(Error::from_reason(err.to_string())),
  }
}

I recommend everyone who deals with CPU-bound tasks on Node.js, to use the NAPI bindings, it is awesome! As a quick guide, you can read more about how to use NAPI-RS to build Node.js packages using Rust.

The Benchmarks?

feed-rs          2367 ops/s, ±0.39%   | fastest
fast-xml-parser  1198 ops/s, ±0.26%   | 49.39% slower
rss-parser:      125 ops/s,  ±2.27%   | slowest, 94.72% slower

As you can see, feed-rs is doing double the amount of work than a highly optimized parsing package.

What Would Marco Polo Think About the WebSockets?

mkadirtan — Sat, 19 Aug 2023 12:15:35 +0000

Marco Polo and WebSockets? You might be surprised to hear about their relationship.

On his visit to Asia, Marco Polo was impressed by the Yam, a postal system built by the Mongol Empire.

Still no connection? Okay, let's rewind a bit.

In this fast-paced world, we want everything to happen in real time.

We want real-time communication, real-time updates on exchanges, real-time money transfers, real-time teleportation, real-time this, and real-time that!

In the old times, real-time communication wasn't possible. Moreover, communicating over long distances was a lengthy process.

But it was crucial for the Khans of the Mongol Empire, as it was a geographically large empire. So, they built one of the best postal systems at the time, called the Yam.

In my research of the Yam, I couldn't help but notice how similar it is to the Internet we use today.

In this post, I want to provide a different perspective. A perspective that shines a light on the evolution of real-time technologies of today. Have a great read!

Letters

One of the oldest and most complete ways of communication is sending letters. Previous methods of communication lacked some essential features. So what did the letters provide? Why they were so powerful and popular throughout history?

If you remember from school, there are five fundamental elements to communication:

The source ( sender )
The message
The channel
The target ( receiver )
Feedback ( Essential for two-ways communication )

So, if I send a letter to my brother:

I am the source,
the message is the text in the letter,
the letter is the channel,
my brother is the target.

It is strange that even though we use very different technologies to communicate, the fundamentals are the same. We can find WebSocket equivalents of all the things above. In fact, we can find TCP, HTTP, SMTP, or any other protocol equivalent to these. But let's keep it in the WebSockets.

WebSocket protocol is built on top of TCP. In other words, the clients must establish a TCP connection to the server first. Then, they can switch to the WebSocket protocol via an upgrade mechanism.

So, a WebSocket equivalent to the above example would be as follows:

Sender IP and Sender Port is the source,
Bytes of data in the TCP packet are the message,
Internet / Web is the channel,
The receiver IP and the Receiver Port is the target.

What about the feedback? Well, if he doesn't write me back there is no feedback and the communication is one-sided. Therefore, a letter contains the address of the receiver as well as the address of the sender, so the receiver can reply.

In WebSockets, there is no concept of feedback. Even though the underlying TCP connection ensures message delivery via ACK packets, the WebSocket protocol doesn't have such a concept. For that reason, some other protocols exist, such as Socket.IO, Stomp, and more. Those protocols offer a mechanism to ACKnowledge ( Feedback ) that the receiver received the message.

Apart from fundamental elements, there are other very important aspects to communication.

Proving the Authenticity of A Letter

The receiver wants to ensure the message is authentic. Is it coming from the source? There were several mechanisms to ensure the authenticity of a letter.

To start with, people used stamps and their signatures to prove the letter is written by them. Assuming the receiver knows who uses which stamp and how their signatures look, they can verify the letter is indeed authentic.

This immediately reminds me of today's Internet. Browsers check the authenticity of the websites by looking at their signatures. In other words, SSL certificates. For example, you can check that you are at https://nooptoday.com and verify that this is indeed from the correct source!

Secondly, people could recognize the handwriting of the sender. They could recognize the writing style of the sender. Humans are actually very capable of recognizing patterns. During the days of World War 2, telegraph operators were able to distinguish senders by their tapping rhythm and style.

This is somewhat persistent throughout all communication methods. For example, if you are a long-time Noop Today reader, you might realize my recent post about RSS feeds was not written by me. It was written by AI. But, if you are a newcomer, you might not realize it.

People also sent encrypted messages to each other. This further helps prove the authenticity of the sender, assuming only the sender knows how to encrypt the message.

This is again accomplished by using SSL certificates on the websites. Most web protocols also have their secure counterparts: HTTP & HTTPS, WS & WSS, or SMTP & SMTPS.

These methods were not great but they worked to some extent. Of course, as you may have noticed, all these methods require a pre-established trust between the parties.

Even today, the Internet contains many security flaws. At least, they are fixed as soon as they are detected. Still, it doesn't mean every web service on the Internet complies with the latest bestest security practices.

More About Letters

The letter is a physical channel for communication. This allowed senders to add fragrance to their letters, use quality papers to reflect the importance of their message, or decorate the paper in beautiful ways to convey more than words in their message.

However, it also means that letters can be lost during transmission, they can be stolen or damaged along the way. This brings us to another important aspect of communication: Reliability.

Delivering Messages in A Reliable Way

Well, you've prepared a beautiful letter, sprayed it with a nice perfume, and used the best quality paper for it. You hit send, ehm. excuse me, you gave your letter to a messenger, and you are not sure whether it will reach the receiver.

What if your message is really important?

Then you could give your message to a very reputable courier. Which is very similar to using a more trusted service for sending messages from our phones.

If you don't hear back from the receiver, you can send it again. This method is used by the TCP protocol. The receiver might receive more than one message, but since you send the letter again and again, it will be delivered at least once. This is the algorithm behind at least once delivery guarantee provided by message broker softwares such as RabbitMQ, Kafka or Redis.

People used very different methods to send their letters until generally available postal offices were built.

The Need for Speed in Information Exchange

The importance of the communication speed is undisputable. But how important it was? I think we can judge its importance for the Mongol Empire, just by looking at how much resources and effort was put into building the Yam.

It consisted of numerous postal stations ( 1400 in China alone ), countless horses ( up to 50,000 ), and a large number of oxen, mules, carts, boats, dogs, and sheep.

The goal was to speed up the information exchange within the country. The Mongol Empire was geographically large, and it was crucial to deliver information in a short time from one end of the country to the other.

China had a similar system before the Yam, but the Mongols took it too far to build a complete information network.

How did The Yam Postal System Worked?

The Yam, focused heavily on speed. The postal stations acted as relays. Every postal station contained some amount of horses, and messengers ready to go in demand. Moreover, postal stations are located about 20-40 miles from each other.

When a message is sent from a postal station, the messenger immediately starts riding to the nearest postal station along the route.

The initial messenger delivers the letter to the next postal station. Another messenger from the station immediately starts riding to the next station and so on until the letter is reached to the final destination.

This process is called relaying. The message is relayed through intermediate postal stations.

Now, I want you to make an experiment. Open your terminal and enter the following command:

# On Macos and Linux
traceroute nooptoday.com

# On Windows:
tracert nooptoday.com

Wait a moment until the command completes, and you will see a similar output:

traceroute: Warning: nooptoday.com has multiple addresses; using 188.114.97.3
traceroute to nooptoday.com (188.114.97.3), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  2.569 ms  2.190 ms  2.045 ms
 2  * * *
 3  172.19.6.129 (172.19.6.129)  31.203 ms  37.910 ms  29.936 ms
 4  172.16.193.125 (172.16.193.125)  39.917 ms  42.795 ms  35.853 ms
 5  172.16.60.86 (172.16.60.86)  24.988 ms
    172.16.60.134 (172.16.60.134)  33.023 ms  39.132 ms
 6  172.16.60.101 (172.16.60.101)  31.876 ms
    172.16.60.149 (172.16.60.149)  40.284 ms  42.080 ms
 7  172.16.198.3 (172.16.198.3)  36.744 ms
    172.16.198.7 (172.16.198.7)  58.546 ms
    172.16.198.3 (172.16.198.3)  51.061 ms
 8  10.40.168.240 (10.40.168.240)  31.211 ms
    10.40.141.65 (10.40.141.65)  45.503 ms
    10.40.169.122 (10.40.169.122)  60.582 ms
 9  ae6.bucarest1.buc.seabone.net (93.186.132.6)  89.756 ms  77.439 ms  87.002 ms
10  cloudflare.bucarest1.buc.seabone.net (93.186.132.11)  80.037 ms  107.892 ms  76.112 ms
11  188.114.97.3 (188.114.97.3)  80.520 ms  76.317 ms  86.985 ms

Traceroute allows you to see exactly which hops your network packets go through until reaching to the destination server. The hops are the servers between you and the destination, a.k.a relays. Depending on your geographical location the results will be different for you.

I am using Cloudflare to secure my server, so termination address should belong to the cloudflare as in my example.

What? Are you not impressed? Okay, how about some visuals? This is the visualization of my connection from Turkey, to the twitter.com. You can try and see the results for yourselves at https://stefansundin.github.io/traceroute-mapper/

Okay, so relaying is pretty much the same compared to the Yam.

A minor difference is that, messengers in the Yam system cared about the geographical distance and the actual geographical route to their destination, and decided which station they should go next.

The network packets are routed according to the IP protocol, and it works a little different. Whatever the case is, the main purpose of the IP protocol is to deliver the packages to the destination and do it efficiently.

The Yam was optimized to prevent any delays during the transmissions. They contained a lot of horses and riders to send out many messages without waiting for the riders to arrive.

A similar pattern in the internet protocol is the concept of Ports. You can connect to and from a computer using various ports, up to 65535 in most machines. When you open up countless chrome tabs on your computer, you are connected to each server through a randomly assigned local port of your machine. Again, don't trust me, lets have an experiment.

Open up the terminal, and enter the following:

netstat

You will see a table containing Local Address and the Foreign Address.

Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp4       0      0  192.168.1.110.51074    104.17.50.74.https     ESTABLISHED
tcp4       0      0  192.168.1.110.51073    ec2-50-17-76-205.https ESTABLISHED
tcp4       0      0  192.168.1.110.51072    server-3-160-246.https ESTABLISHED
tcp4       0      0  192.168.1.110.51071    server-3-160-246.https ESTABLISHED
tcp4       0      0  192.168.1.110.51070    server-3-160-246.https ESTABLISHED
tcp4       0      0  192.168.1.110.51069    ec2-54-88-211-15.https ESTABLISHED
tcp4       0      0  192.168.1.110.51068    ec2-54-88-211-15.https ESTABLISHED

Notice that foreign addresses are usually denoted with https, which means it uses the port 443, while the local addresses contain some random numbers around 50000 range.

Marco Polo's Thoughts About The WebSockets and The Yam

Finally, I've received a letter from my dear friend ChatGPT, ehm. sorry, Marco Polo.

My Dearest Friend Noop Today,

I trust this missive finds you in good health and high spirits. As I recount my awe-inspiring journey through the lands of the Mongol Empire, I am compelled to share a revelation that has captured my imagination in a most profound manner. It appears that the remarkable postal system devised by the illustrious Khans, known as the "Yam," bears striking resemblances not only to the intricate network of computers that weave the tapestry of our modern world, the Internet, but also to a technological marvel of our own time - the WebSocket protocol.

Imagine, if you will, the vast expanse of the Mongol Empire stretching like an endless steppe. As I traversed these lands, I marveled at the brilliance of the Yam, which connected distant corners of the empire like the sinews of a mighty horse. Dispatch riders, skilled and swift, carried messages along these well-organized routes, spanning empires and cultures. In many ways, these couriers resembled the packets of data that traverse the digital highways of our time.

But now, let us turn our gaze toward the remarkable WebSocket protocol that graces our modern age. Just as the Yam facilitated the exchange of information across great distances, so does the WebSocket protocol allow for a continuous, bidirectional flow of data between a client and a server. Like the stations of the Yam, our digital servers and data centers act as the lodges for information, housing and transmitting it seamlessly, creating a virtual channel akin to the way the Yam relay stations operated.

Moreover, the Yam and the WebSocket protocol both share the essence of real-time communication. The Yam ensured that news and orders reached their destinations promptly, just as the WebSocket protocol empowers web applications to communicate instantaneously, enriching user experiences and enabling interactive applications that mirror the swift delivery of messages along the Yam's pathways.

Additionally, both the Yam and the WebSocket protocol necessitate a certain level of centralization to function efficiently. Just as the Khans maintained control over the Yam, ensuring its proper functioning, the WebSocket protocol relies on servers to manage the connections and facilitate the data exchange, bringing a touch of governance to the flowing information streams.

The most captivating similarity, however, lies in the way these systems foster interconnectedness. The Yam linked cities and cultures, facilitating cultural exchange and commerce. Similarly, the WebSocket protocol has ushered in an era of dynamic web applications that enable real-time collaboration and engagement, connecting people across the digital landscape much like the Yam connected settlements across the vast Mongol expanse.

As I reflect upon these similarities, I am struck by the timelessness of human innovation. While the tools and technologies have evolved, the underlying desire to bridge distances, unite people, and share knowledge endures. The echoes of the Yam can be heard in the electronic pulses of the Internet and the WebSocket protocol, reminding us that human ingenuity, whether in the form of hoofbeats, digital signals, or continuous data streams, knows no bounds.

In closing, my friend, I implore you to contemplate the grand tapestry of history and technology that connects us all. From the desolate expanses of the Mongol Empire to the bustling networks of the Internet and the seamless interactivity of the WebSocket protocol, we are bound by a thread of innovation that stretches across time and space. May we continue to nurture this spirit of connection and progress for generations to come.

Yours in wonderment, Marco Polo

It is both scary and exciting to hear Marco Polo's thoughts about the real-time technologies of today. What excites me a lot is that he keeps mentioning human progress and our desire to interconnect with each other.

I believe we've achieved a lot since those days. It is amazing how we are all connected to each other through the internet, well.. except for North Korea of course.

Summary

I think understanding the basic concepts behind the technologies we use today is important. As a civilization, we've achieved great advancements in technology.

However, humans' basic needs and desires are still pretty much the same. In the old times, people did their best with what they had, but they didn't have today's technological tools.

I've found it helps me to wrap my head around the various technologies of today if I know how they evolved throughout time, which needs they fulfilled, and how they were implemented before the internet era.

I hope you learned something new from this post, if you like my content please subscribe to the newsletter or leave a comment below.

Lecture Notes: NLP with Deep Learning - 1

mkadirtan — Sat, 01 Apr 2023 20:37:43 +0000

I can't believe it has been four years since I finished college. To my surprise, I missed taking courses just for the sake of science.

Working at a company, putting your knowledge and effort to build something is excellent and satisfying. You also gain experience by doing that.

But curiosity is a strong human motive to learn something new. I think the latest advances in AI and the hype around ChatGPT and language models triggered my curiosity.

So, I decided to take open lectures by Standford University on YouTube. I wanted to keep track of my learning progress and share my lecture notes in this series.

🙌🏻 Subscribe to Noop Today to join my journey or if you just want to follow along and learn something new.

Meaning of a Word

Even though I used ChatGPT before, I didn't know the science behind it. It all looked like magic to me, as it does to most people.

In the first lecture, I got really excited to see how we can translate words into a machine-understandable format. The lesson started with the following comic:
Source: https://languagelog.ldc.upenn.edu/nll/?p=21170 Source: https://languagelog.ldc.upenn.edu/nll/?p=21170
The comic is a mind-opener that makes you question how you give meanings to words.

Language constantly evolves, there are new words entering our lives and some words stop being used and some words gain new meanings!

Moreover, the meaning of a word also changes depending on the context.

Word Embedding

Word embedding is a large dimensional ( hundreds of dimensions ) space made up of word vectors. A word vector is the mathematical representation of the meaning of a word.

I'll explain how scientists turn words into mathematics in a minute. But first, let's look at an extremely simplified two-dimensional representation of a word embedding:
Simplified Word Embedding
Of course, there are no labels such as age or gender in a real word embedding, because dimensions don't have to represent a specific thing.

The meaning of words is too broad to represent in a two-dimensional space. But having too many dimensions make the computation harder. A relatively sufficient word embedding can have 300 dimensions.

Even though we can't visualize a space with hundreds of dimensions in our heads, it is enough to understand why we need to have so many dimensions for representing words as vectors.

Word2Vec Algorithm

Word2Vec is one of the models you can use to translate words into a machine-readable format. Basically, it converts words into vectors.

I will try to explain how Word2Vec converts words into vectors, but honestly, the idea is all I can present to you. Because I didn't understand the mathematics behind it.

What do we want to achieve by converting a word to a vector? We want to create a word embedding in which semantically similar words are closer to each other.

The algorithm is based on the famous quote:

You shall know a word by the company it keeps. -John Rupert Firth

The Word2Vec algorithm takes a large corpus ( body ) of text as input. Then tries to assign vectors to every unique word in the text. The value of the vector is adjusted iteratively to create a probability function P.

P(c|o) = Probability of word **o** appear in the context of center word **c**

The probability function gives the probability of a word appearing in the context of another word. In each iteration, the vectors are adjusted and the probability function gives more accurate results.

The context words and the center word are defined as in the example:

This is a really big text input you give to the algorithm.
This is a really big text input you give to the algorithm.
This is a really big text input you give to the algorithm.
This is a really big text input you give to the algorithm.

At each step, a word is selected as the center word and words within a certain radius of the center word are context words.

If the above sentence is the only input you give to the algorithm, you expect the probability of the word "big" appearing in the context of "text" to be very high.

And with a large enough dataset, this algorithm can create a word embedding in which words are closer to each other if they are semantically similar.

Results: Analogy Example

At the end of the lecture, there is a fascinating use case example for the algorithm.

Since words are described as vectors via the Word2Vec algorithm, you can apply vector operations on words!

Firstly, you can ask the algorithm: "What are some similar words to the banana?". And the algorithm gives very accurate results such as "coconut, mongo, bananas".

Once those vectors are calculated, this is just a question of finding the nearest points on a k-dimensional space. This is easily answered by running the k-nearest neighbors - *knn *- algorithm on the word embedding.

Secondly, you can add or subtract words from each other!

In the lecture, the following example is given:

King - Man + Woman = ?

And the algorithm replied correctly with the Queen!

So, with this algorithm, you can find analogies very easily.

Summary

This was a great introduction lecture. If you have read it so far, I strongly suggest you go watch it on YouTube.

I will be sharing a post for each lecture on the list, so stay tuned!

Top 5 Struggles of Backend Developers

mkadirtan — Fri, 31 Mar 2023 21:57:18 +0000

"Web is an I/O device"

...as Uncle Bob describes.

I/O, Input / Output, *i.e *user input and server output.

Users want to access some data through applications or websites.

They want it to be available throughout the world over.

If the requirements are so simple, why is backend development so challenging? That is a great question I want to hopefully answer in this post. But more than that, this post should be a grumbling space for hardworking backend developers.

Let's have a look at a simplistic diagram of a backend server.

Everything looks simple from the outside. But a lot is going on behind the scenes. In the end, it is called "backend" development for a reason.

The job of a backend developer is to make everything work seamlessly, at least from a user perspective.

So, here is my list of the top 5 struggles of backend developers.

Struggle 1: Crashing Servers!

Backend developers need to always remind themselves:

The server can go down at any point in time

It is not only the server, unhandled rejections, network problems, and countless other things can cause application crashes.

This is a list of fallacies of distributed systems:

The network is reliable
Latency is zero
Bandwidth is infinite
The network is secure
Topology doesn't change
There is one administrator
Transport cost is zero
The network is homogeneous

They are more than an inconvenience for backend development.

It is already hard to write correctly functioning programs. Now you also need to consider failure scenarios and make the application fault tolerant.

Struggle 2: Scalability

There are various aspects of scalability, but let's keep things simple for the sake of this post.

A scalable application can continue to work even if the load increases significantly.

Servers have limited capacity and they can handle only a limited amount of requests.

If you add more resources to the server it can handle more requests ( vertical scaling ).
If you add more servers to the system they can handle more requests ( horizontal scaling ).

Designing an application to be horizontally scalable, immediately changes the way things work.

As an example, most of the backend developers make race condition mistakes in scalable applications - *including myself. *In a scalable application, data can be read or modified by multiple servers. A typical example:

Server A reads the data { foo: 1 }
Server B reads the data { foo: 1 }
Server A modifies the data and writes back: { foo: 1, bar: 2 }
Server B modifies the data and writes back: { foo: 1, baz: 2 }

The result can be either { foo: 1, bar: 2 } or { foo: 1, baz: 2 } depending on which server writes back the data last. So, both servers are in a race condition!

This was just an example, but there are a lot of things to consider when developing a horizontally scalable application.

Struggle 3: Security

Remember, a public server is accessible to everyone on the internet.

And, there are a lot of bad actors out there 🥷.

Bad actors can craft special requests to extract information from a vulnerable server.

Go check out https://owasp.org/www-project-top-ten/ for what kind of sorcery those bad actors do to your servers.

Even legitimate users should be considered bad actors from a backend developer's perspective.

Legitimate users may abuse the service or send unexpected inputs to exploit the server's vulnerabilities. All user inputs should be sanitized to prevent unexpected inputs from legitimate users. Schema definitions, such as JSON Schema, are very helpful to sanitize user input.

Also, legitimate users are not allowed to do anything they want. The service needs to have a well-defined authorization system to prevent users from accessing forbidden resources.

The server might be vulnerable to a Denial of Service attack. Most DoS attacks can be prevented with rate limiting.

The list goes on, and the truth is no server can be 100% secure. Try to follow best practices as much as possible to secure your servers.

Struggle 4: Consistency

If a car is red, then it is red.

Other people should also tell you that car is red.

And, nobody should say that car isn't red.

Then tell me in the comments...
https://en.wikipedia.org/wiki/The_dress
...what is the color of this dress? Is it black & blue or white & gold? Whichever you choose, you would be surprised to see other people swear it is the other one!

You see, sometimes it is not very easy to come up with a single true answer to such a basic question.

In computer terms, this dress can be a document read from a cache, a slow replicate instance of a database, or an event-sourced database.

In all cases, the data might be obsolete. One server might read obsolete data while the other has access to a more recent version of the document.

Trade-off: Consistency and Performance

The problem with consistency is that retrieving the latest information may not be the optimum solution for most cases.

For example, if thousands of people try to access a popular tweet at the same time what do they see? The same tweet content, except the read counts, are probably way different from each other.

This is the result of a design decision. The engineers at Twitter decided to trade off between performance and consistency at the expense of showing obsolete read counts. This is a pretty good deal because the read counts are not a critical part of the tweets.

More About Consistency

Well, sometimes inconsistencies happen not because of design decisions but because of the way things work in software engineering.

Remember the previous example about the race condition? Well, how do you handle that? You might use locks but that can be costly ( in terms of time ). Some systems use optimistic locking to get better results. Some other systems use event sourcing and evade the problem completely.

Then there is the problem with client and backend consistency. The client database should be consistent with the actual data on the backend. Here is a nice article if you want to read more about consistency: https://medium.com/ssense-tech/handling-eventual-consistency-with-distributed-system-9235687ea5b3

Struggle 5: Performance

I think this one is pretty obvious. Everyone wants to develop blazingly fast backend applications.

But, that is not an easy task. From the language and framework selection to the algorithms used and the overall design of the system, almost everything has an impact on the performance.

I would say, the best course of action is:

Use a performance testing tool such as k6
Don't waste time ultra-optimizing the application if it meets the criteria

It is that simple...

...to give advice from a blog post 😅

In reality, measuring the application performance is somewhat complicated. Maybe you can easily measure the end-to-end performance of your endpoints etc.

But detecting the actual bottleneck in your application is hard without observability tools.

In RESTful backend applications, a for loop or a basic algorithm in the code is rarely the bottleneck. Optimizing the database queries, network configurations, or API design usually have greater benefits.

Summary

The struggle is real for the backend developers. Share your struggles in the comments and show others they are not alone!

I hope you enjoyed this post, subscribe for more like this.

Reduce Network Usage - With This 1 Simple Trick!

mkadirtan — Mon, 27 Mar 2023 04:15:00 +0000

Photo by Nik

Making efficient use of the network is essential.

Efficient applications work faster and smoother, even in low network conditions.

Efficiency can be achieved in two stages:

Design time
Runtime

You might not want to mess with the design part if the application is already designed and actively running.

Then, there is this approach with application development: you should not optimize early.

Runtime optimizations can reduce network usage to a desired level. If that is the case, optimizing the design can be considered an early optimization.

Design Time Optimizations

Design time optimizations for network usage relate to the overall design of how the application interacts with network resources.

For example, using GraphQL can reduce network usage for many applications. The reason is, GraphQL allows applications to fetch only the required amount of data and nothing else.

Some applications access the backend via BFF - *Backend for Frontend. *This can also help reduce network usage from the application point of view. The BFF can aggregate data from multiple servers and serve it to the application through a single API call.

These are some of the optimizations you can consider to reduce network usage in the design stage.

Going beyond the REST, and creating optimized API endpoints
Keeping request/response schemas as little as possible
Using efficient data structures - such as protocol buffers

Runtime Optimizations

Runtime optimizations relate to the smartness of the applications.

For example, a smart application shouldn't request the same resource twice. This can be achieved by implementing caching strategies

Caching is one of the most popular solutions to reduce network usage and network latency as well.

Despite its popularity, there is no ready-to-go solution for caching. Applications should use the correct caching strategies depending on the use case. In fact, caching is one of the hardest things in software development. Remember the famous quote:

There are only two hard things in computer science: cache invalidation and naming things. - Phil Karlton

With the increasing popularity of reactive programming, there are some clever tricks to reduce the number of network calls.

For example, imagine the application has a search box that shows the results in real-time. Instead of sending search requests after every time a letter is typed, the applications use a **debounce **operator. Debounce operator sends a search request after the user stops typing.

The Simple Trick: Compression

Wait, did you make me read the article just to let me know about compression?

Don't get frustrated, I have a good reason to do so! Besides, I talk about other things, too. Bear with me 🧸

You might be using compression wrong.

Compression is very simple to use because there are already well-known algorithms you can use out of the box.

The problem is compressing the encrypted data.

You should never compress the encrypted data, because you simply can't. The compressed data is hardly smaller than the original and the applications waste CPU cycles for compression 😮.

Instead, you should always encrypt the compressed data.

How to Tell If My Application Make It Right?

Simply, toggle the compression on / off and compare the payload sizes. If the payload sizes are very close, then your application probably encrypts first.

Payload Comparison: Compress First vs. Encrypt First

To make comparison easier, I created a small example repository.

The example uses aes-256-cbc as the encryption method and brotli as the compression algorithm. You can also check the example in GitHub.

[      resource ] http://jsonplaceholder.typicode.com/albums?userId=1
[      original ] 816
[  encryptFirst ] 746
[ compressFirst ] 244
[  % difference ] 67.29 reduction


[      resource ] http://jsonplaceholder.typicode.com/albums
[      original ] 9333
[  encryptFirst ] 7472
[ compressFirst ] 1723
[  % difference ] 76.94 reduction


[      resource ] http://jsonplaceholder.typicode.com/photos
[      original ] 1071472
[  encryptFirst ] 820717
[ compressFirst ] 98447
[  % difference ] 88.00 reduction

Why Compression Doesn't Work After Encryption?

The reason is simple. Compression algorithms try to represent the same data with fewer bytes.

They first try to identify repeating patterns or some kind of order in the original data. If the original data contains the word lorem ipsum 5 times, the compressed data replaces all recurring occurrences with references to the first occurence.

The responsibility of encryption algorithms is to break recognizable patterns in the original data. They scrumble the data so that it can't be understood by external actors. They create a high entropy representation of the original data, in cryptography terms.

Essentially, an encrypted data loses its recognizable patterns and it becomes harder to compress.

A real life equivalent could be a shopping list.

Egg
Egg
Egg
Egg
Egg
Milk

You can easily remember this list easily, because it comes down to:

5 x Egg
Milk

But that is not possible with the following list:

Egg
Milk
Bread
Apples
Lemons
Chocolate

Even though there are same amount of items in both lists, the second list can't be compressed. That is what encryption does to compression.

FeathersJS vs NestJS - Compared in 3 Key Areas

mkadirtan — Mon, 13 Mar 2023 07:05:58 +0000

Cover photo by Mateusz Wacławek

FeathersJS released its 5th major version, a.k.a Dove recently, and I've been watching the framework for some time. It is an excellent time to compare two backend framework giants, FeathersJS and NestJS. These are not your "yet another javascript framework" type of framework. They pave the way to backend development in the Node.js environment.

In my opinion, Node.js provides a very powerful backend software development environment. A typical backend application accepts requests, executes queries on the database, and writes some files to disk. All of these tasks can be handled asynchronously in Node.js, meaning the server can handle many requests at the same time. Even though you can achieve the same or better results in other languages, it is easier to write asynchronous code in Javascript.

The struggle in the Node.js world is standardization. You have too many options to choose from, due to the large number of npm packages and the community size. You can find new javascript framework releases every other week, or someone in the community sharing their way of building applications. Don't get me wrong, I'm happy to be in such an active community but this is a double-edged sword.

FeathersJS and NestJS both provide a structure for writing backend applications with their techniques. Both of them are capable of creating the same applications however their style differs a lot.

In this post, I will be comparing FeathersJS and NestJS from a developer experience perspective on key areas.

Application Structure

Application Structure - FeathersJS

To create a new FeathersJS application, execute this in your terminal: npm create feathers

In the application creation process, FeathersJS CLI allows for many customizations such as:

Use TypeScript or JavaScript
Use KoaJS or Express,
Will you build a REST application, Real-time application or all off them
Which package manager to use npm, yarn, pnpm
What is your preferred schema definition format TypeBox or JSON Schema
Which databases will you connect to SQLite, MongoDB, PostgreSQL, MySQL/MariaDB, MicrosoftSQL
Select authentication mechanisms Email + Password, Google, Facebook, Twitter, Github and Auth0

feathers-app/
├── config/
│   ├── custom-environment-variables.json
│   ├── default.json
│   └── test.json
├── knexfile.ts
├── migrations/
│   ├── 20230205130353_user.ts
│   └── 20230205130403_authentication.ts
├── package-lock.json
├── package.json
├── public/
│   └── index.html
├── readme.md
├── src/
│   ├── app.ts
│   ├── authentication.ts
│   ├── channels.ts
│   ├── client.ts
│   ├── configuration.ts
│   ├── declarations.ts
│   ├── hooks/
│   │   └── log-error.ts
│   ├── index.ts
│   ├── logger.ts
│   ├── services/
│   │   ├── index.ts
│   │   └── users/
│   │       ├── users.class.ts
│   │       ├── users.schema.ts
│   │       ├── users.shared.ts
│   │       └── users.ts
│   ├── sqlite.ts
│   └── validators.ts
├── test/
│   ├── app.test.ts
│   ├── client.test.ts
│   └── services/
│       └── users/
│           └── users.test.ts
└── tsconfig.json

FeathersJS application folder structure, automatically generated by CLI
FeathersJS application folder structure allows developers to easily decide where to put new files. It is well-structured and easily recognizable.

FeathersJS's preferred style of writing applications revolves around the idea of services. If you want to introduce new functionality in your application, you are most likely going to create a new service in FeathersJS.

Other than that, core functionalities such as authentication, routing, logging, and validation are well-defined in FeathersJS. You are very likely to use existing solutions provided by the framework with little configuration.

One thing that makes FeathersJS special is, it can generate its client code automatically. This is a unique feature I've never heard before - correct me if I am wrong on this.

Another special feature of FeathersJS is that it has the concept of channels. Which allows clients or other servers running your code to get notified about certain events. It is almost an in-app message broker on the server side. I'm not sure about the scalability of channels though! This is a very neat feature considering FeathersJS calls itself: The API and Real-time
Application Framework.

Least but not least, you can replace almost all 3rd party npm packages in FeathersJS to your taste. You might want to use another validation library or logging library, BUT you will never want to worry about your HTTP server library. FeathersJS HTTP server works fast and its performance is not dependent on the underlying HTTP server, read more about this here: Lightning Fast Routing

Application Structure - NestJS

To create a new NestJS application, execute this on your terminal: nest new my-project

NestJS doesn't provide many customizations through CLI but it has guides for customizations such as switching HTTP adapters.

nest-app/
├── README.md
├── nest-cli.json
├── package-lock.json
├── package.json
├── src/
│   ├── app.controller.spec.ts
│   ├── app.controller.ts
│   ├── app.module.ts
│   ├── app.service.ts
│   ├── main.ts
│   └── user/
│       ├── dto/
│       │   ├── create-user.dto.ts
│       │   └── update-user.dto.ts
│       ├── entities/
│       │   └── user.entity.ts
│       ├── user.controller.spec.ts
│       ├── user.controller.ts
│       ├── user.module.ts
│       ├── user.service.spec.ts
│       └── user.service.ts
├── test/
│   ├── app.e2e-spec.ts
│   └── jest-e2e.json
├── tsconfig.build.json
└── tsconfig.json

NestJS application folder structure, automatically generated by CLI
NestJS has a very modular project structure which is also reflected in its folder structure.

NestJS's preferred style of writing applications revolves around the idea of modules. Modules contain providers and controllers, they can import other modules or export their providers, and they are configurable, read more about it in the previous post: Best Way to Create Dynamic Modules in NestJS.

The business logic of a NestJS application usually resides in services. A service can use other services via dependency injection.

Implementation details of the NestJS framework are mostly hidden from the developers. NestJS exposes most of its functionality via Typescript decorators. If you are into code aesthetics you can prefer this style of coding, and read more about it in the previous post: Custom Decorators in NestJS

Since NestJS doesn't allow much customization it is easy for other NestJS developers to adapt your project easily.

A unique approach NestJS brings to backend application development is using reactive programming for most things. You can see Observables being used in HTTP requests, events, commands anything you name. This might be an innovative approach but in my experience, observables cause a performance drop in NestJS applications.

Similar to FeathersJS, core functionalities are well-defined and you can find resources for whatever you want to do in a NestJS application. NestJS can be considered a little more mature compared to FeathersJS.

NestJS is also customizable but due to the way adapters are written, sometimes using a different package can cause a loss of functionality. For example, it is known that you lose functionality by switching from Express Adapter to Fastify Adapter, but this is a minor inconvenience for most developers.

Last but not least, NestJS CLI is capable of managing a monorepo project structure. Which is very helpful if you are doing microservices with NestJS.

Customization Options

Customization Options - FeathersJS

FeathersJS is intentionally made to be very customizable. There are two reasons for that.

Firstly, if you are already developing your backend application in ExpressJS, you can just switch ExpressJS with FeathersJS and your project will work just fine. From there on, you can make the full switch bit by bit. This allows an easier migration path for projects that use ExpressJS.

Secondly, FeathersJS doesn't want to have opinions about how you implement your application. Rather, it aims to lay out best practices and its own implementations for them. It has good solutions that work well, and you can use them whenever you want to.

Customization Options - NestJS

NestJS is intentionally made to be less customizable.

NestJS aims to be the framework for enterprise applications. Enterprises don't like custom solutions. Custom solutions are costly to enterprise because it requires the knowledge of the person who implemented them. Developers can come and go, the project shouldn't be affected by this.

Also, we shouldn't forget NestJS is heavily inspired by AngularJS and it is also one of the less customizable frameworks for frontend.

BUT, this doesn't mean you can't customize your project or every other NestJS developer can immediately start working on existing NestJS projects. The reality is you can customize, but you shouldn't do it. Even if you do leave tracks of the NestJS railway, you will probably go back to the track for using some other functionality to work. Let me make it clear with a simple example:

You can opt out of the class-validator library in NestJS and use AJV for validation. It works without causing you problems but now you can't use automatic OpenAPI generation in NestJS.

Community and Documentation

Community and Documentation - FeathersJS

FeathersJS has a small, helpful, and welcoming community. You can join the community in Discord. One thing very noticeable on the FeathersJS website is the Ecosystem page where community-driven FeathersJS packages are promoted!

FeathersJS documentation walks you through everything you need in the framework. It is simple and clear. There are a few amounts of blog posts or online courses for FeathersJS, but I think numbers will go up after the latest release. David Luecke and other core maintainers are putting a lot of effort into the framework for some time, and I hope they get more recognition in the Node.js ecosystem.

Community and Documentation - NestJS

NestJS has a large, helpful, and welcoming community. You can join the community in Discord. NestJS has official online courses that can be purchased on its website.

I don't know how popular is their course but documentation on their website can get you through most of the things. To solve some problems you might need help from StackOverflow or GitHub issues but other than that, I think documentation and examples are enough. Can't skip here without mentioning NestJS Hero to Zero online course by Ariel Weinberger, which I've completed and found helpful.

I haven't had time to review the new Developer Tools by NestJS, but it looks like a very helpful tool. It is a paid tool by NestJS but at a low price. I think it would be much better if they released it for free at least initially.

Summary

You can build applications of any size and functionality whichever you choose. To choose between FeathersJS and NestJS means choosing between two different code styles. In my opinion, the development process in FeathersJS feels more fitting ( natural ) to the Node.js environment, but, I also understand the reason why NestJS is preferred by enterprise applications.

Mad respect to both David Luecke and Kamil Mysliwiec and all the other contributors, and maintainers of both projects for creating two of the strongest backend frameworks for Node.js.

If you have experience in either of the frameworks, I would like to know what you think, please share your experiences and opinions in the comment section.

I hope you learned something new, have a good one!

Scalable Websocket Server Implemented by ChatGPT

mkadirtan — Wed, 01 Feb 2023 07:30:00 +0000

Cover photo by possessedphotography

In the previous post Why Websockets are Hard to Scale we've talked about the problems with scaling websockets and some of the existing solutions as well. The post mentioned using a load balancing technique called consistent hashing, which is a very elegant solution to this problem. I promised you for a post about how to implement scalable websocket server with consistent hashing.

Well, the day has come, take your coffee and follow along. Special thanks to ChatGPT, almost all of the code you will find in this post is written by ChatGPT. I only made some adjustments, so the code actually works.

The plan is to use code generated by ChatGPT, and do as little modifications as possible on it. If you've read the previous post I'm sure you have an outline of what we will do. But to remind you again here are steps for our implementation:

Create a websocket server
Create a hashring with server addresses, update when necessary
Retrieve list of servers, and keep it updated for all servers
Redirect clients to correct servers
Extra: Create a client that can redirect itself

New favourite IDE unlocked: The Prompter

I was reluctant to test out the ChatGPT but it turns out to be very helpful, intelligent enough to give me code blocks that I can work on but still dumb enough to take my job ^^. Whether we like it or not, it is already here. As with all other technologies if you embrace it sooner than later, you can use it for your advantage. At least that is what I realized with my experience.

ChatGPT can be challenging to work with at times, but with practice and by using more specific prompts, it is possible to unlock its full potential. I recommend you to have a look at awesome-chatgpt-prompts by my dear colleague, Fatih Kadir Akın, for inspiration on how to effectively communicate with ChatGPT.

How to Better Use ChatGPT for Code Generation

Since ChatGPT will not create a fully completed project for us, each implementation step covers a single concept. Therefore we can get a working code block for each step and glue them together!

Hashring Implementation

I've started with the hashring, and asked ChatGPT to create me a hashring implementaiton in TypeScript, with support for virtual nodes. The first output from ChatGPT seemed okay but it used a > comparison for strings. Also, the hash algorithm didn't create random and even results. First, I asked for fixing the bug with > comparison. Then, I wanted it to use a hash function with better distribution.

import { createHash } from 'crypto';

class HashRing {
  private nodes: string[];
  private ring: { [key: string]: string };
  private replicas: number;

  constructor(nodes: string[], replicas: number) {
    this.nodes = nodes;
    this.replicas = replicas;
    this.ring = {};

    // Create a hash for each node and add it to the ring
    for (const node of nodes) {
      for (let i = 0; i < replicas; i++) {
        const hash = createHash('sha1')
          .update(node + ':' + i)
          .digest('hex');
        this.ring[hash] = node;
      }
    }

    // Sort the keys in the ring to ensure that they are in clockwise order
    this.sortedKeys = Object.keys(this.ring).sort((a, b) =>
      a.localeCompare(b, undefined, { numeric: true })
    );
  }

  // Get the node responsible for a given key
  getNode(key: string): string {
    const hash = createHash('sha1')
      .update(key)
      .digest('hex');
    const keys = this.sortedKeys;

    // Find the first node with a position greater than the hash
    let index = keys.findIndex((k) => k.localeCompare(hash, undefined, { numeric: true }) > 0);

    // If no such node is found, the key belongs on the first node
    if (index === -1) {
      index = 0;
    }

    return this.ring[keys[index]];
  }
}

With that complete, I copied the code into hashring.ts and exported the class. Whenever the server list is updated, this class will be recreated. Then we can iterate through all the connected sockets and send them a redirect message if they are not supposed to be on this server.

Full conversation with hashring implementation: https://sharegpt.com/c/kxhBEp6

Websocket Server Implementation

Next up, I requested ChatGPT to create a Websocket server. It immediately created a Hello World example using ws library.

import * as WebSocket from 'ws';

const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', (ws: WebSocket) => {
  ws.on('message', (message: string) => {
    console.log(`Received message => ${message}`);
  });

  ws.send('Hello! Message From Server');
});

ChatGPT has a tendency for not using default imports, but it is easy to fix. With the basic server setup, I requested ChatGPT to add feature for redirecting clients based on hashring algorithm.

import * as crypto from 'crypto';

const serverList = ['server1', 'server2', 'server3'];

function getServer(clientIp: string) {
  const hash = crypto.createHash('md5').update(clientIp).digest('hex');
  const index = parseInt(hash, 16) % serverList.length;
  return serverList[index];
}

const clientIp = '192.168.0.1';
const server = getServer(clientIp);
console.log(`Redirecting client to ${server}`);

But my request was a little unclear, so the output had the general idea but it was missing server and client interaction. So, I wanted ChatGPT to merge two outputs. After a few prompts it created a working example.

import * as WebSocket from 'ws';
import * as crypto from 'crypto';

const serverList = ['server1', 'server2', 'server3'];

function getServer(clientIp: string) {
  const hash = crypto.createHash('md5').update(clientIp).digest('hex');
  const index = parseInt(hash, 16) % serverList.length;
  return serverList[index];
}

const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', (ws: WebSocket) => {
  const clientIp = ws.upgradeReq.connection.remoteAddress;
  const server = getServer(clientIp);
  console.log(`Redirecting client ${clientIp} to ${server}`);

  ws.send(`You have been redirected to ${server}`);

  ws.on('message', (message: string) => {
    console.log(`Received message from ${clientIp} => ${message}`);
  });
});

The example was looking OK, but sending a plain text message to clients is not very flexible. So, I asked the ChatGPT to use a more managable message body. Also, it was sending redirect message whether the client was on correct server or not, so I wanted ChatGPT to fix that.

import * as WebSocket from 'ws';
import * as crypto from 'crypto';

const serverList = ['server1', 'server2', 'server3'];

function getServer(clientIp: string) {
  const hash = crypto.createHash('md5').update(clientIp).digest('hex');
  const index = parseInt(hash, 16) % serverList.length;
  return serverList[index];
}

const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', (ws: WebSocket) => {
  const clientIp = ws.upgradeReq.connection.remoteAddress;
  const correctServer = getServer(clientIp);
  console.log(`Client ${clientIp} should be connected to ${correctServer}`);

  if (ws.upgradeReq.headers.host !== correctServer) {
    console.log(`Redirecting client ${clientIp} to ${correctServer}`);

    const message = {
      type: 'redirect',
      server: correctServer,
    };
    ws.send(JSON.stringify(message));

    ws.on('message', () => {});
  } else {
    console.log(`Client ${clientIp} is already connected to ${correctServer}`);

    ws.on('message', (message: string) => {
      console.log(`Received message from ${clientIp} => ${message}`);
    });
  }
});

Voila! This looks great but there are still more work to do. For example, the server list in this example is static, and we need to manually replace getServer function with the getNode method from Hashring. One amazing side note, I asked the ChatGPT if it can create a client side example that can interact with this server. And it did, it is a very intelligent tool that will amaze me for a long time.

Full conversation with websocket server and websocket client implementation: https://sharegpt.com/c/pIc7amA

import * as WebSocket from 'ws';

let ws = new WebSocket('ws://localhost:8080');

ws.on('open', () => {
  console.log('Connected to WebSocket server');
});

ws.on('message', (data: string) => {
  const message = JSON.parse(data);
  if (message.type === 'redirect') {
    console.log(`Received redirect message. Disconnecting from current server and connecting to ${message.server}`);
    ws.close();
    ws = new WebSocket(`ws://${message.server}:8080`);
  } else {
    console.log(`Received message => ${data}`);
  }
});

ws.on('close', () => {
  console.log('Disconnected from WebSocket server');
});

Another important thing to note: Code examples from ChatGPT are not flawless, and I don't think they were meant to be. Sometimes they are easily noticable by IDEs or humans, but sometimes ChatGPT does something very unusual and doesn't work in any way. In that case, you can always ask it to fix its own code, and to my surprise again, it does a good job at it, too!

Implementing Service Registry

To create a hashring, we need addresses of all the available servers. This might sound simple, but it is really difficult to implement such things on the servers. You have to consider failure scenarios and update notifications etc. That is out of scope of this post, but as a simpler solution I was ready to use a 3rd party service registry solution. The problem is, I've never used a service registry before.

At first, I asked ChatGPT to create a service registry implementation in TypeScript. It created a solution using Redis, but the code looked too complicated to me and I didn't want to use it. Instead I've found myself having a conversation with ChatGPT about which Service Registry Tools are there, what are their differences etc.

**Me: **can you compare eureka, zookeeper and consul

**ChatGPT: **Sure!

Eureka, Zookeeper, and Consul are all tools that can be used for service discovery in a distributed environment.

Eureka is a REST-based service that is primarily used in the Java ecosystem for locating services for the purpose of load balancing and failover of middle-tier servers.

Apache Zookeeper is a distributed coordination service that enables distributed applications to achieve high availability. Zookeeper helps to coordinate distributed applications by providing a central place for them to store and access shared data.

Consul is a distributed, highly available, and data center aware tool that can be used for service discovery, configuration, and orchestration. It is written in the Go programming language and provides a HTTP API for interacting with it.

In summary, Eureka is primarily used in the Java ecosystem, Zookeeper is a distributed coordination service, and Consul is a tool that can be used for service discovery, configuration, and orchestration.

Then I asked about simple examples using each one of the tools. In the end, Consul seemed like a good solution for this purpose and as an added bonus it was written in Go, so I gave it a try.

Consul implementation from ChatGPT didn't work. Even though I asked ChatGPT to fix the code, something was not right. I didn't want to debug and fix it but I was wanting to use as much code from ChatGPT. Problem was much likely due to breaking changes from npm package ( ChatGPT doesn't have up-to-date information on everything ).

So, what did I do? I went back to square one and asked for a Redis implementation, but this time I asked for Service Discovery instead of Service Registry. Appearantly, I was asking for something slightly different - related SO post.

import Redis from 'ioredis';

const redis = new Redis({ host: '127.0.0.1' });
const updateInterval = 5; // in seconds
const heartbeatInterval = 10; // in seconds

const serviceList: Set<string> = new Set();
const heartbeatIntervals: { [instance: string]: NodeJS.Timeout } = {};

async function registerServiceInstance(instance: string) {
  await redis.sadd('service-name', instance);
  await redis.set(instance, 'alive', 'EX', heartbeatInterval * 2);
  heartbeatIntervals[instance] = setInterval(() => {
    redis.set(instance, 'alive', 'EX', heartbeatInterval * 2);
  }, heartbeatInterval * 1000);
}

async function deregisterServiceInstance(instance: string) {
  await redis.srem('service-name', instance);
  await redis.del(instance);
  clearInterval(heartbeatIntervals[instance]);
  delete heartbeatIntervals[instance];
}

async function removeStaleServiceInstances() {
  const instances = await redis.smembers('service-name');
  for (const instance of instances) {
    const ttl = await redis.ttl(instance);
    if (ttl === -2 || ttl === -1) {
      await redis.srem('service-name', instance);
    }
  }
}

async function updateServiceList() {
  const instances = await redis.smembers('service-name');
  serviceList.clear();
  for (const instance of instances) {
    serviceList.add(instance);
  }
}

setInterval(removeStaleServiceInstances, updateInterval * 1000);
setInterval(updateServiceList, updateInterval * 1000);

In addition to raw service discovery implementation, I also asked for automatic update and removing stale services. And it did a great job at creating them, too.

Full conversation with service discovery implementation: https://sharegpt.com/c/bGUAItM

Putting it All Together: Scalable Websocket Server

So far we've implemented:

Hashring, for determining which server a user belongs to,
Service Discovery to keep list of available servers,
Websocket Server for clients to connect,
Websocket API for re-routing clients when necessary,
Websocket Client to connect our servers

with the help of ChatGPT. We could of course implement these ourselves, but there is nothing wrong with getting help and speeding up the process. As far as you know what you are asking for and you can verify the code works as intended, ChatGPT only speeds up our development times. Also, it is very fun to work with.

Now we have all the pieces in our hand, we can just glue them together! Github repository with final project and ChatGPT conversations: https://github.com/nooptoday/chatgpt-scalable-websockets

Results

You can clone the repository and test it for yourself! Here is a terminal output from running instances:

node1              | [node1] - [client_size] -> [1884]
node2              | [node2] - [client_size] -> [2237]
node3              | [node3] - [client_size] -> [1879]

6000 connections are sent to node1 initially, and clients are redirected to other nodes. In an ideal world, we would expect to see something like:

node1              | [node1] - [client_size] -> [2000]
node2              | [node2] - [client_size] -> [2000]
node3              | [node3] - [client_size] -> [2000]

You can play with number of virtual nodes, which hash function to use or which parameter from client to hash and see how the results change.

If you have any questions about the implementation details you can ask here in the comments or create an issue in the GitHub repository. If you are asking, why there is a need for implementing such a solution, you can read previous post that led to this implementation: Why Websockets are Hard to Scale

That is it for this post, I hope you enjoyed and learned something new, let me know what you think in the comments!

How to Trace Websocket Events in NestJS - [Case Study]

mkadirtan — Mon, 02 Jan 2023 05:45:00 +0000

Cover Photo by Enrico Mantegazza

In NestJS, HTTP requests are traced by req.id parameter. You can write your custom id generator, or use default id generated by NestJS or Express or Fastify. However, there is no such concept of request id, or request tracing when it comes to Websockets / Socket.IO.

Though NestJS allows use of interceptors, filters or guards in Gateways, one feature I've felt missing is request id. Without request id, you can't trace websocket events and that is not very good for observability.

In this post, I will explain how to trace websocket events in NestJS. For this, we will create a custom WebSocketAdapter. In doing so, we will dive deep into source code of NestJS and solve some challenges!

What is a WebSocketAdapter?

NestJS makes use of Adapter Pattern to abstract underlying libraries from your code. For example NestJS doesn't care if you are using Fastify or Express as an HTTP library. If you want to use another library, you just need to implement an adapter defined by NestJS.

There are various websocket libraries in Node.js, and also there is Socket.IO, which makes things easier for developers. In this post, we will modify IoAdapter, from the existing official NestJS package: @nestjs/platform-socket.io.

Socket.IO is a bidirectional communication protocol, than can work over HTTP or Websockets. We will use it as an example websocket library in this post, but actual details of the Socket.IO protocol is out of scope for this post. I'm planning to publish an article about how Socket.IO works, if you don't want to miss out, subscribe to Noop Today!

How to Write a WebSocketAdapter in NestJS

To create a custom WebSocketAdapter in NestJS, you need to implement WebSocketAdapter interface from @nestjs/common.

// https://github.com/nestjs/nest/blob/master/packages/common/interfaces/websockets/web-socket-adapter.interface.ts

export interface WebSocketAdapter<TServer = any, TClient = any, TOptions = any> {
    create(port: number, options?: TOptions): TServer;
    bindClientConnect(server: TServer, callback: Function): any;
    bindClientDisconnect?(client: TClient, callback: Function): any;
    bindMessageHandlers(client: TClient, handlers: WsMessageHandler[], transform: (data: any) => Observable<any>): any;
    close(server: TServer): any;
}

In a typical Node.js application involving websockets / socket.io, you probably have the same functionality in a different way. Since we are using NestJS as our framework, lets see how we should structure our code.

A typical socket.io server in Node.js

const express = require('express');
const app = express();
const http = require('http');
const server = http.createServer(app);
const { Server } = require("socket.io");

// create in WebSocketAdapter
const io = new Server(server);

// bindClientConnect in WebSocketAdapter
io.on('connection', (socket) => {
  console.log('handleConnection');

  // bindClientDisconnect in WebSocketAdapter
  socket.on('disconnect', () => {
    console.log('handleDisconnect');
  })

  // bindMessageHandlers in WebSocketAdapter
  socket.on('foo', (data, callback) => {
    console.log('handleFoo');
    callback('OK');
  })
});

server.listen(3000, () => {
  console.log('listening on *:3000');
});

// close in WebSocketAdapter
setTimeout(() => { io.close() }, 10000);

NestJS provides an AbstractWsAdapter class to make things easier for us. So instead of this:

import { WebSocketAdapter } from '@nestjs/common';

export class MyWebSocketAdapter implements WebSocketAdapter {}

We can do this:

import { AbstractWsAdapter } from '@nestjs/websockets';

export class MyWebsocketAdapter extends AbstractWsAdapter {}

The difference is that, AbstractWsAdapter provides default implementations for some methods, but you still need to implement create and bindMessageHandlers methods.

We will act smart and use existing code from the official package, and make modifications only in required parts.

Use Existing IoAdapter from @nestjs/platform-socket.io

This is the IoAdapter from NestJS official packages, that acts as a bridge between NestJS and Socket.IO.

// https://github.com/nestjs/nest/blob/master/packages/platform-socket.io/adapters/io-adapter.ts
import { isFunction, isNil } from '@nestjs/common/utils/shared.utils';
import {
  AbstractWsAdapter,
  MessageMappingProperties,
} from '@nestjs/websockets';
import { DISCONNECT_EVENT } from '@nestjs/websockets/constants';
import { fromEvent, Observable } from 'rxjs';
import { filter, first, map, mergeMap, share, takeUntil } from 'rxjs/operators';
import { Server, ServerOptions, Socket } from 'socket.io';

export class IoAdapter extends AbstractWsAdapter {
  public create(
    port: number,
    options?: ServerOptions & { namespace?: string; server?: any },
  ): Server {
    if (!options) {
      return this.createIOServer(port);
    }
    const { namespace, server, ...opt } = options;
    return server && isFunction(server.of)
      ? server.of(namespace)
      : namespace
      ? this.createIOServer(port, opt).of(namespace)
      : this.createIOServer(port, opt);
  }

  public createIOServer(port: number, options?: any): any {
    if (this.httpServer && port === 0) {
      return new Server(this.httpServer, options);
    }
    return new Server(port, options);
  }

  public bindMessageHandlers(
    socket: Socket,
    handlers: MessageMappingProperties[],
    transform: (data: any) => Observable<any>,
  ) {
    const disconnect$ = fromEvent(socket, DISCONNECT_EVENT).pipe(
      share(),
      first(),
    );

    handlers.forEach(({ message, callback }) => {
      const source$ = fromEvent(socket, message).pipe(
        mergeMap((payload: any) => {
          const { data, ack } = this.mapPayload(payload);
          return transform(callback(data, ack)).pipe(
            filter((response: any) => !isNil(response)),
            map((response: any) => [response, ack]),
          );
        }),
        takeUntil(disconnect$),
      );
      source$.subscribe(([response, ack]) => {
        if (response.event) {
          return socket.emit(response.event, response.data);
        }
        isFunction(ack) && ack(response);
      });
    });
  }

  public mapPayload(payload: unknown): { data: any; ack?: Function } {
    if (!Array.isArray(payload)) {
      if (isFunction(payload)) {
        return { data: undefined, ack: payload as Function };
      }
      return { data: payload };
    }
    const lastElement = payload[payload.length - 1];
    const isAck = isFunction(lastElement);
    if (isAck) {
      const size = payload.length - 1;
      return {
        data: size === 1 ? payload[0] : payload.slice(0, size),
        ack: lastElement,
      };
    }
    return { data: payload };
  }
}

Let's see what does all the methods do:

create method is responsible for creating the socket.io server, we don't need to modify here.
createIoServer is an helper method for create
bindMessageHandlers is responsible for delivering socket.io messages to our handlers. We will modify this for sending extra arguments to our handlers.
mapPayload parses payload from socket.io to { ack, data }, we don't need to modify here.

So, we just need to focus on bindMessageHandlers.

Modifying The bindMessageHandlers

public bindMessageHandlers(
  socket: Socket,
  handlers: MessageMappingProperties[],
  transform: (data: any) => Observable<any>,
) {
  const disconnect$ = fromEvent(socket, DISCONNECT_EVENT).pipe(
    share(),
    first(),
  );

  handlers.forEach(({ message, callback }) => {
    const source$ = fromEvent(socket, message).pipe(
      mergeMap((payload: any) => {
        const { data, ack } = this.mapPayload(payload);
        return transform(callback(data, ack)).pipe(
          filter((response: any) => !isNil(response)),
          map((response: any) => [response, ack]),
        );
      }),
      takeUntil(disconnect$),
    );
    source$.subscribe(([response, ack]) => {
      if (response.event) {
        return socket.emit(response.event, response.data);
      }
      isFunction(ack) && ack(response);
    });
  });
}

First, lets understand what is handlers in this. It has the type: MessageMappingProperties:

export interface MessageMappingProperties {
    message: any;
    methodName: string;
    callback: (...args: any[]) => Observable<any> | Promise<any> | any;
}

In socket.io terms: socket.on(message, callback), message will match the event name, and callback will be the actual handler function.

So, in order to pass parameters to our handler methods, we must pass parameters to the **callback**.

Lets take a closer look at code with additional commentary:

// message --> eventName
// callback --> eventHandler
handlers.forEach(({ message, callback }) => {
    // RxJS equivelant for --> socket.on(message)
    const source$ = fromEvent(socket, message).pipe(
        // payload is socket.io payload
        mergeMap((payload: any) => {
            const { data, ack } = this.mapPayload(payload);
            // transform, transforms our callback handler to observable
            // callback function is called with TWO parameters
            return transform(callback(data, ack)).pipe(
                filter((response: any) => !isNil(response)),
                // If callback returns any response, wrap it with ack
                map((response: any) => [response, ack]),
            );
        }),
        takeUntil(disconnect$),
    );
    source$.subscribe(([response, ack]) => {
        // If you return { event: 'foo', data: 'bar' } from handler
        // See: https://docs.nestjs.com/websockets/gateways#multiple-responses
        if (response.event) {
            return socket.emit(response.event, response.data);
        }
        // If client accepts response, send response
        isFunction(ack) && ack(response);
    });
});

A Little Problem in NestJS

If you've ever used IoAdapter in your project, you might realize even though the adapter passes two arguments to the callback function, your handler methods don't receive them in full. Let me explain:

Say you have a message handler:

class MySocketGateway {
  @SubscribeMessage('foo')
  fooHandler(argument1, argument2, argument3){
    console.log({
      argument1, // Client
      argument2, // Body
      argument3, // undefined
    })
  }
}

If you go ahead and try something like this, you will see that 1st argument is Socket / Client object, 2nd argument is body BUT 3rd argument is undefined. Two questions come to mind:

Where did 1st argument came from?
Where did my ack function disappear?

Lets go with the first question, if we dive deep into underlying NestJS code, we can find the exact place where adapter.bindMessageHandlers is called.

// https://github.com/nestjs/nest/blob/21bd8c37364a2a2591e3de9bfb88d32d09431438/packages/websockets/web-sockets-controller.ts#L147

public subscribeMessages<T = any>(
    subscribersMap: MessageMappingProperties[],
    client: T,
    instance: NestGateway,
) {
    const adapter = this.config.getIoAdapter();
    const handlers = subscribersMap.map(({ callback, message }) => ({
      message,
      callback: callback.bind(instance, client),
    }));
    adapter.bindMessageHandlers(client, handlers, data =>
      fromPromise(this.pickResult(data)).pipe(mergeAll()),
    );
}

If you look closely, callback is bound with two parameters. bind method has one required argument for this, and rest of the arguments are supplied as arguments to the function - *callback. *More info about this in mozilla docs. So, our 1st argument is fixed by NestJS to be client object.

How about ack function, why does it disapper?

This was very hard for me to debug but I've found why does that happen, and how you can fix it!

The problem is not about the ack function. I've tried sending different parameters, or sending more than two parameters to callback function but only the first parameter ends up in handler, and rest is gone.

There is a helper class [WsContextCreator](https://github.com/nestjs/nest/blob/aa3ad07c1023b71edda6b6ea53374787d3712231/packages/websockets/context/ws-context-creator.ts#L56) in @nestjs/websockets, that is responsible for attaching Interceptors, Guards, Pipes and ExceptionHandlers to handlers, AND managing parameters sent to handler methods!

That helper class is responsible for disappearing parameters! The reason it makes other parameters disappear is related to this use case:

class MyWebsocketGateway {
    @SubscribeMessage('foo')
    handleFoo(client: Client, body){
        console.log({ body });
    }

    @SubscribeMessage('bar')
    handleBar(@MessageBody() body){
        console.log({ body })
    }
}

If you want to decorate your handler parameters with @MessageBody or @ConnectedSocket, the WsContextCreator assigns those parameters for you. You can even do experiments like this:

class MyWebsocketGateway {
    @SubscribeMessage('foo')
    handleFoo(arg1, arg2, arg3, @MessageBody() body){
        console.log({ arg1, arg2, arg3 }) // All undefined
        console.log({ body })
    }
}

I won't go into line by line details of how does this happen, but I will provide you a conceptual explanation and if you want to investigate more, you can always look at source code of @nestjs/websockets for a good exercise.

The key point is WsContextCreator extracts data from initial arguments to the callback function, rearranges them and sends those arguments to your handler function. During the extraction process, WsContextCreator looks up metadata of the handler function:

// https://github.com/nestjs/nest/blob/aa3ad07c1023b71edda6b6ea53374787d3712231/packages/websockets/context/ws-context-creator.ts#L163

const metadata = this.contextUtils.reflectCallbackMetadata<TMetadata>(
    instance,
    methodName,
    PARAM_ARGS_METADATA,
) || DEFAULT_CALLBACK_METADATA;

If your function doesn't have PARAM_ARGS_METADATA, NestJS assigns default callback metadata. Guess what, DEFAULT_CALLBACK_METADATA assigns only two parameters to our handler parameters - client and payload.

// https://github.com/nestjs/nest/blob/master/packages/websockets/context/ws-metadata-constants.ts

import { WsParamtype } from '../enums/ws-paramtype.enum';

export const DEFAULT_CALLBACK_METADATA = {
  [`${WsParamtype.PAYLOAD}:1`]: { index: 1, data: undefined, pipes: [] },
  [`${WsParamtype.SOCKET}:0`]: { index: 0, data: undefined, pipes: [] },
};

Solution for Providing Additional Parameters to Handlers

NestJS exports an undocumented helper function called assignCustomParameterMetadata, which allows us to override DEFAULT_CALLBACK_METADATA and use our own metadata.

// https://github.com/nestjs/nest/blob/5aeb40b/packages/common/utils/assign-custom-metadata.util.ts#L9

export function assignCustomParameterMetadata(
  args: Record<number, RouteParamMetadata>,
  paramtype: number | string,
  index: number,
  factory: CustomParamFactory,
  data?: ParamData,
  ...pipes: (Type<PipeTransform> | PipeTransform)[]
) {
  return {
    ...args,
    [`${paramtype}${CUSTOM_ROUTE_AGRS_METADATA}:${index}`]: {
      index,
      factory,
      data,
      pipes,
    },
  };
}

The function is not self-explanatory, but I think it will be much more clear after example below. Important thing is "where should we use this function?".

This function is meant to modify PARAM_ARGS_METADATA, and normally that metadata is defined by decorators such as @ConnectedSocket or @MessageBody. So, lets comply with the conventions and create ourselves a new parameter decorator: @Ack.

Creating the @ack Decorator

If you are not familiar with the concept of decorators, or decorators in NestJS, you can read my previous article: Using Custom Decorators in NestJS.

import { PARAM_ARGS_METADATA } from '@nestjs/websockets/constants';

export function Ack(): ParameterDecorator {
// index is the index of parameter we decorated
// It is not related to getArgByIndex below!
    return function(target, key, index) {
        // Get existing metadata of the handler
        const args = Reflect.getMetadata(PARAM_ARGS_METADATA, target.constructor, key) || {};
        // Extend with new metadata
        const meta = assignCustomParameterMetadata(args, 'Ack', index, (data, input: ExecutionContext) => {
            // This allows NestJS to extract required parameter from initial arguments supplied to 'callback' function
            // Index here needs to match index of the callback parameters
            // 0 --> Client
            // 1 --> Payload from IoAdapter
            // 2 --> Ack from IoAdapter
            // 0 is always client, but rest of the parameters depend on the underlying adapter.
            return input.getArgByIndex<Function>(2);
        });
        Reflect.defineMetadata(PARAM_ARGS_METADATA, meta, target.constructor, key);
    };
}

Now we can reach our ack function from the handler as follows:

class MyWebSocketGateway {
    @SubscribeMessage('foo')
    fooHandler(@MessageBody() body, @Ack() ack){
        ack('foo_response');
    }
}

Lets Move On With RequestId

That really was a case study, isn't it? Lets add a request id to our handler parameters in case we want to trace our requests.

First we need to modify our adapter, if you remember from above, the adapter supplies arguments to the callback function. We can create a request id in our adapter and supply it to the callback.

  // You can make your own implementation for this.
private createRequestId(){
  return crypto.randomUUID();
}

public bindMessageHandlers(
  socket: Socket,
  handlers: MessageMappingProperties[],
  transform: (data: any) => Observable<any>,
) {
    const disconnect$ = fromEvent(socket, DISCONNECT_EVENT).pipe(
      share(),
      first(),
    );

    handlers.forEach(({ message, callback }) => {
      const source$ = fromEvent(socket, message).pipe(
        mergeMap((payload: any) => {
          const { data, ack } = this.mapPayload(payload);
          // <-- Modified Section Start
          const requestId = this.createRequestId();
          return transform(callback(data, ack, requestId))
          // Modified Section End -->
          .pipe(
            filter((response: any) => !isNil(response)),
            map((response: any) => [response, ack]),
          );
        }),
        takeUntil(disconnect$),
      );
      source$.subscribe(([response, ack]) => {
        if (response.event) {
          return socket.emit(response.event, response.data);
        }
        isFunction(ack) && ack(response);
      });
    });
}

That is all the modification our adapter needs. Now we can create another decorator: @RequestId

import { PARAM_ARGS_METADATA } from '@nestjs/websockets/constants';

export function RequestId(): ParameterDecorator {
    return function(target, key, index) {
        const args = Reflect.getMetadata(PARAM_ARGS_METADATA, target.constructor, key) || {};
        const meta = assignCustomParameterMetadata(args, 'RequestId', index, (data, input: ExecutionContext) => {
            return input.getArgByIndex<string>(3);
        });
        Reflect.defineMetadata(PARAM_ARGS_METADATA, meta, target.constructor, key);
    };
}

That is exactly the same decorator with @Ack with only difference being return input.getArgByIndex(3);. Now our handler function looks like this:

class MyWebSocketGateway {
    @SubscribeMessage('foo')
    fooHandler(@MessageBody() body, @Ack() ack, @RequestId() requestId){
        console.log('Received request with id: ', requestId);
        ack('foo_response');
    }
}

Next Steps

If you don't want to deal with all of these, I'm currently working on an npm package that has better developer ergonomics compared to official @nestjs/platform-socket.io package. I'm aware that decorating every parameter in handler functions can be ugly and tiring to eyes. I believe there are more beautiful solutions to this problem. I'm trying to figure out which solution would result in better developer experience.

I would like to hear your opinions about this. Whether you suggest a usage example, or you face other problems with official package, please let me know what you think in the comments.

Also, if you don't want to miss out on articles about NestJS and programming in general subscribe to Noop Today. I hope you learned something new today, see you in the upcoming posts!

Here is the repo that contains TraceableIoAdapter with example code: https://github.com/nooptoday/nestjs-trace-websocket-events

Why Websockets are Hard To Scale?

mkadirtan — Thu, 22 Dec 2022 06:02:34 +0000

Cover photo by fabio

EDIT: Second part of the series is released Scalable Websocket Server Implemented by ChatGPT Check it out, it has a fully working scalable websocket server repository!

Websockets provide an important feature: bidirectional communication. Which allows servers to push events to clients, without the need of a client request.

The bidirectional nature of websockets is both a grace and a curse! Even though it provides a great ton of use case for websockets, it makes implementing a scalable websocket server a lot harder compared to HTTP servers.

Shameless self promotion: I think websockets are an important part of the web, and they need more recognition among software development world. I am planning to publish more posts about the websockets, if you don't want to miss out you can check out https://nooptoday.com/ and subscribe to my mailing list!

What Makes Websockets Unique?

Websocket is an application layer protocol, just like HTTP which is another application layer protocol. Both protocols are implemented over TCP connection. But they have different characteristics and they represent two different countries in the communications world - *if that makes sense :) *

HTTP carries the flag for request-response based communication model, and Websocket carries the flag for bidirectional communication model.

Side Note: In an attempt to draw a clearer picture of Websocket, you will see a HTTP vs Websocket comparison throughout the post. But that doesn't mean they are competing protocols, instead they both have their use cases.

Characteristics of Websocket:

Bidirectional communication
Long lived TCP connection
Stateful protocol

Characteristics of HTTP:

Request response based communication
Short lived TCP connection
Stateless protocol

Stateful vs. Stateless Protocols

I'm sure you've seen some of the posts about creating stateless, and endlessly scalable backend servers. They tell you to use JWT tokens for stateless authentication, and use lambda functions in your stateless application etc.

What is this state they are talking about and why it is so important when it comes to scaling server applications?

State is all the information your application has to remember to function correctly. For example, your application should remember logged in users. 99% of the applications do this ( source: trust me ), and it is called session management.

Okay, then state is a great thing! Why do people hate it, and always try to make stateless applications?

You need to store your state in somewhere, and that somewhere is typically the memory of server. But memory of your application server is not reachable from other servers, and the problem begins.

Imagine a scenario:

User A makes a request to Server 1. Server 1 authenticates User A, and saves its Session A, to the memory.
User A makes second request to Server 2. Server 2 searches saved sessions but it can't find Session A, because it is stored inside Server 1.

In order for your server to become scalable you need to manage the state outside of your application. For example you can save sessions to a Redis instance. This makes application state available to all the servers via Redis, and Server 2 can read Session A from the Redis.

Stateful Websocket: Opening a Websocket connection is like a wedding between the client and the server: the connection stays open until one of the parties close it ( or cheat on it, due to network conditions of course ).

Stateless HTTP: On the other hand, HTTP is a heartbreaker, it wants to end everything as fast as possible. Once a HTTP connection is opened, client sends a request and as soon as server responds, the connection is closed.

Okay, I will stop with the jokes now, but remember Websocket connections are typically long lived, whereas HTTP connections are meant to end asap. The moment you introduce Websockets into your application, it becomes stateful.

In Case You Wonder

Even though both HTTP and Websocket are built on top of TCP, one can be stateles, while the other one is stateful. For simplicity, I didn't want to confuse you with details about TCP. But keep in mind, even in HTTP, underlying TCP connection can be long lived. This is out of scope for this post, but you can learn more about it here

Can't I Just Use a Redis Instance to Store Sockets?

In the previous example with sessions, the solution was simple. Use an external service to store sessions, so every other server can read sessions from there ( Redis Instance ).

Websockets are a different case, because your state is not only the data about socket, inevitably you are storing connections in your server. Every websocket connection is bound to a single server, and there is no way for other servers to send data to that connection.

Now, comes the second problem, you must have a way for other servers to send message to that websocket connection. For that, you need to have a way to send messages between servers. Luckily, that is already a thing called message broker. You can even use Redis pub / sub mechanism to send messages between your servers.

Let's summarize what have we discussed so far:

Websocket connections are stateful
A websocket server automatically becomes a stateful application
In order for stateful applications to scale, you need to have an external state storage ( example: Redis )
Websocket connections are bound to a single server
Servers need to connect to a message broker to send message to websockets in other servers

Is that it? Adding a Redis instance to my stack solves all the scaling problems with Websockets?

Unfortunately, no. Well, there is another issue with scalable websocket architectures: Load Balancing

Load Balancing Websockets

Load balancing is a technique to ensure, all of your servers share somewhat equal amount of load. In a plain HTTP server, this can be implemented with simple algorithms like Round Robin. But that is not ideal for a Websocket server.

Imagine you have an auto scaling server group. That means, as the load increases new instances are deployed and as the load decreases some instances are closed.

Since HTTP requests are short lived, the load balances somewhat evenly across all instances even though servers are added / removed.

Websocket connections are long lived ( persistent ), which means new servers will not take the load off from old servers. Because, old servers are still persisting their websocket connections. As an example, say Server 1, has 1000 open websocket connections. Ideally, when a new server Server 2 is added, you want to move 500 websocket connections from Server 1, to Server 2. But that is not possible with traditional load balancers.

You can drop all websocket connections, and expect clients to reconnect. Then you can have 500 / 500 websocket connection distribution on your servers, but that is a bad solution because:

Servers will be bombarded with reconnection requests, and server load will fluctuate greatly
If servers are scaled frequently, clients will reconnect frequently and it can have a negative effect on user experience
It is not an elegant solution - I know you guys care about this!

The most elegant solution for this problem is called: Consistent Hashing

Load Balancing Algorithm: Consistent Hashing

There are various load balancing algorithms out there, but consistent hashing is just from another world.

The basic idea behind load balancing with consistent hashing is that:

Hash the incoming connection with some property, lets say userId => hashValue
You can then use hashValue to determine which server this user should connect to

This assumes that your hash function evenly distributes userId to hashValue.

BUT, there is always a but, isn't there... Now you still have the problem when you add / remove servers. And the solution is to drop connections when new servers are added or removed.

Wait, what! You just said that was a bad idea? How is that a solution, now?

The beauty of this solution is that, with consistent hashing you don't have to drop all the connections, but you should just drop only some of the connections. Actually, you drop exactly how many connections you need to drop. Let me explain with a scenario:

Initially, Server 1 has 1000 connections
Server 2 is added
As soon as Server 2 is added, Server 1 runs a rebalancing algorithm
Rebalance algorithm detects which websocket connections are needed to drop, and if our hash function detects roughly 500 connections that need to go to Server 2
Server 1, emits a reconnect message to those 500 clients, and they connect to Server 2

Here is a great video by ByteByteGo that explains the concept visually.

A Much Simpler And Efficient Solution

Discord manages a lot of Websocket connections. How did they solve the problem with load balancing?

If you investigate the developer docs about how to establish a websocket connection, here is how they do it:

Send a HTTP GET request to /gateway endpoint, receive available Websocket server urls.
Connect to Websocket server.

The magic behind this solution is, you can control which server new clients should connect. If you add new server, you can direct all the new connections to new server. If you want to move 500 connections from Server 1 to Server 2, simply drop 500 connections from Server 1, and supply Server 2 address from /gateway endpoint.

/gateway endpoint needs to know load distributions of all the servers, and make decisions based on that. It can simply return url of the server with minimum load.

This solution works and much simpler compared to consistent hashing. But, consistent hashing method doesn't need to know about load distribution of all the servers, and it doesn't require a HTTP request before hand. Therefore, clients can connect faster but that is generally not an important consideration. Also, implementing a consistent hashing algorithm can be tricky. That is why, I am planning to create a follow up post about Implementing Consistent Hashing for Load Balancing Websockets.

I hope you learned something new from this post, please let me know what you think in the comments. You can subscribe to mailing list if you don't want to miss out on new posts!

Best Way to Create Dynamic Modules in NestJS

mkadirtan — Wed, 14 Dec 2022 07:00:00 +0000

Creating dynamic modules in NestJS can be complex. Use this method and you will never be afraid of creating dynamic modules again!

Cover Photo by Westwind Air Service on Unsplash

NestJS module system is very helpful. They allow us to organize our code, and they help us define module boundaries. Within @Module you can define everything about your module. From the NestJS docs:

import { Module, Global } from '@nestjs/common';
import { CatsController } from './cats.controller';
import { CatsService } from './cats.service';
import { CommonModule } from '../common/common.module';

@Global()
@Module({
  imports: [CommonModule],
  controllers: [CatsController],
  providers: [CatsService],
  exports: [CatsService],
})
export class CatsModule {}

https://docs.nestjs.com/modules#global-modules

But things get complicated when you want to configure your module dynamically. This is typically required by database modules but there are many other cases that require you to create dynamic module in NestJS.

As a convention dynamic modules in NestJS have static methods such as forRoot, forRootAsync, forFeature In this post you will learn how to create a dynamic module in NestJS with all the benefits but with least complexity!

NestJS Official Docs are Too Complex

Here is a dynamic module example from the docs:

import { Module } from '@nestjs/common';
import { ConfigService } from './config.service';
import {
  ConfigurableModuleClass,
  ASYNC_OPTIONS_TYPE,
  OPTIONS_TYPE,
} from './config.module-definition';

@Module({
  providers: [ConfigService],
  exports: [ConfigService],
})
export class ConfigModule extends ConfigurableModuleClass {
  static register(options: typeof OPTIONS_TYPE): DynamicModule {
    return {
      // your custom logic here
      ...super.register(options),
    };
  }

  static registerAsync(options: typeof ASYNC_OPTIONS_TYPE): DynamicModule {
    return {
      // your custom logic here
      ...super.registerAsync(options),
    };
  }
}

https://docs.nestjs.com/fundamentals/dynamic-modules#extending-auto-generated-methods

I know I've picked the most bloated example but still, creating a dynamic module as documented in NestJS docs, doesn't look simple. There is a good reason for that. On one hand NestJS tries to provide a simple API for using module system, but on the other hand the API must provide enough access to satisfy custom needs of developers. I think they did a great job at designing their API, but this is the reason examples from official docs are complex.

@golevelup Team To The Rescue

@golevelup team has some great packages to use along your NestJS project. We will use @golevelup/nestjs-modules for this post. We will use defaults provided by their package, in exchange our dynamic modules will be much simpler and easier to maintain.

I assume you've already spin up a NestJS project. We need to install @golevelup/nestjs-modules package to our project:

npm install @golevelup/nestjs-modules

What Will We Build

For the sake of providing a good use case, lets create a serializer module that can use alternative strategies. Create the following files:

# Inside src folder
/-> serde
/--> serde.module.ts
/--> serde.service.ts
/--> json.provider.ts
/--> msgpack.provider.ts
/--> constants.ts
/--> interfaces.ts

This is how we will continue:

Create a configurable dynamic module SerdeModule
Inject JsonProvider and MsgpackProvider to SerdeService
Define SerdeModuleOptions
Expose selected strategy from SerdeService

Creating Configurable Dynamic Module

Create your module as usual:

// serde.module.ts
@Module({})
export class SerdeModule {}

Add providers to your module:

import { JsonProvider } from './json.provider';
import { MsgpackProvider } from './msgpack.provider';
import { SerdeService } from './serde.service';

@Module({
    providers: [
        JsonProvider,
        MsgpackProvider,
        SerdeService,
    ]
})
export class SerdeModule {}

One last thing, we will expose SerdeModule's functionality from SerdeService. Therefore it needs to be exported:

import { JsonProvider } from './json.provider';
import { MsgpackProvider } from './msgpack.provider';
import { SerdeService } from './serde.service';

@Module({
    providers: [
        JsonProvider,
        MsgpackProvider,
        SerdeService,
    ],
    exports: [SerdeService]
})
export class SerdeModule {}

So far so good, and there is nothing unusual. Now we will make SerdeModule configurable, specifically we want user to decide which serialization strategy they want to use.

We need to create an interface to define module options:

// interfaces.ts
export interface SerdeModuleOptions {
    strategy: 'json' | 'msgpack';
}

Lastly, we will need these options to be accessible within SerdeService. If you remember from the NestJS docs, module options are injected within providers. And @Inject decorator provides values via an InjectionToken. Injection Token acts like a unique id of the value you want to access. It is defined as follows:

declare type InjectionToken = string | symbol | Type;

export interface Type<T = any> extends Function {
    new (...args: any[]): T;
}

Type is basically a class reference. Since we defined our module options as an interface, we will define a string as Injection Token:

// constants.ts
export const SERDE_MODULE_OPTIONS_TOKEN = 'SERDE_MODULE_OPTIONS_TOKEN';

Finally we can bring them all together:

import { JsonProvider } from './json.provider';
import { MsgpackProvider } from './msgpack.provider';
import { SerdeService } from './serde.service';

import { createConfigurableDynamicRootModule } from '@golevelup/nestjs-modules';
import { SERDE_MODULE_OPTIONS_TOKEN } from './constants';
import { SerdeModuleOptions } from './interfaces';


@Module({
    providers: [
        JsonProvider,
        MsgpackProvider,
        SerdeService,
    ],
    exports: [SerdeService]
})
export class SerdeModule extends createConfigurableDynamicRootModule<SerdeModule, SerdeModuleOptions>(SERDE_MODULE_OPTIONS_TOKEN) {}

That is all! We've successfully created a dynamic module. Lets put it into use, we can import it within AppModule:

// app.module.ts
import { SerdeModule } from './serde.module';

@Module({
    imports: [
        SerdeModule.forRoot(SerdeModule, { strategy: 'json' })
    ]
})

Notice we've never defined a forRoot method on our class. This method is automatically created by @golevelup/nestjs-modules and it is type safe, Hurray! There is also the forRootAsync counterpart:

// app.module.ts
import { SerdeModule } from './serde.module';
import { ConfigModule, ConfigService } from '@nestjs/config';


@Module({
    imports: [
        SerdeModule.forRootAsync(SerdeModule, {
            imports: [ConfigModule],
            inject: [ConfigService],
            useFactory: (configService: ConfigService) => {
                return {
                    strategy: configService.get('SERDE_STRATEGY')
                }
            }
        })
    ]
})

Accessing Module Options

To make use of provided options, we need to inject it into SerdeService

import { SERDE_MODULE_OPTIONS_TOKEN } from './constants';
import { SerdeModuleOptions } from './interfaces';

@Injectable()
export class SerdeService {
    constructor(
        @Inject(SERDE_MODULE_OPTIONS_TOKEN)
        moduleOptions: SerdeModuleOptions
    ){
        console.log({ moduleOptions });
    }
}

// console output: { moduleOptions: { strategy: 'json' } }

We will apply strategy pattern for this example. If you want to learn more about strategy pattern, I recommend you to read https://betterprogramming.pub/design-patterns-using-the-strategy-pattern-in-javascript-3c12af58fd8a written by Carlos Caballero. Basically we will switch between JsonProvider and MsgpackProvider depending on the moduleOptions.strategy.

First inject the providers into SerdeService

import { SERDE_MODULE_OPTIONS_TOKEN } from './constants';
import { SerdeModuleOptions } from './interfaces';

import { JsonProvider } from './json.provider';
import { MsgpackProvider } from './msgpack.provider';

@Injectable()
export class SerdeService {
    private readonly _strategy;

    constructor(
        @Inject(SERDE_MODULE_OPTIONS_TOKEN)
        moduleOptions: SerdeModuleOptions,
        private readonly jsonProvider: JsonProvider,
        private readonly msgpackProvider: MsgpackProvider,
    ){
        switch(moduleOptions.strategy) {
            case 'json':
                this._strategy = jsonProvider;
                break;
            case 'msgpack':
                this._strategy = msgpackProvider;
                break;
        }
    }
}

Now, we can expose our API to outside world:

import { SERDE_MODULE_OPTIONS_TOKEN } from './constants';
import { SerdeModuleOptions } from './interfaces';

import { JsonProvider } from './json.provider';
import { MsgpackProvider } from './msgpack.provider';

@Injectable()
export class SerdeService {
    private readonly _strategy;

    constructor(
        @Inject(SERDE_MODULE_OPTIONS_TOKEN)
        moduleOptions: SerdeModuleOptions,
        private readonly jsonProvider: JsonProvider,
        private readonly msgpackProvider: MsgpackProvider,
    ){
        switch(moduleOptions.strategy) {
            case 'json':
                this._strategy = jsonProvider;
                break;
            case 'msgpack':
                this._strategy = msgpackProvider;
                break;
        }
    }

    public serialize(data) {
        return this._strategy.serialize(data);
    }

    public parse(data) {
        return this._strategy.parse(data);
    }
}

I leave implementing actual providers to you. If you want to learn more about Strategy Pattern, I am planning to write a detailed post about it. Tell me in the comments if you are interested!

We created a dynamic module in NestJS with an example use case. I hope you've learned something new, let me know what you think in the comments!

DEV Community: mkadirtan

State of Mind Right Before 2025

The Mental Aspect

The Technical Aspect

Rust: A Promising Start but Not My Type

Go: Breath of Fresh Air

Boot.dev

Master's

A Small Visit to Systems Programming: Zig, Tigerbeetle and OSTEP

The Current Aspect

The Future Aspect

What It Means to be a Good Developer?

What does a Developer Has, Other People Don't?

What Should We Do With This Power?

So, What Is a Good Developer

Introducing feed-rs: Fastest Feed Parser Built With Rust & NAPI-RS

@nooptoday/feed-rs - npm

The Benchmarks?

What Would Marco Polo Think About the WebSockets?

Letters

Proving the Authenticity of A Letter

More About Letters

Delivering Messages in A Reliable Way

The Need for Speed in Information Exchange

How did The Yam Postal System Worked?

Marco Polo's Thoughts About The WebSockets and The Yam

Summary

Lecture Notes: NLP with Deep Learning - 1

Meaning of a Word

Word Embedding

Word2Vec Algorithm

Results: Analogy Example

Summary

Top 5 Struggles of Backend Developers

Struggle 1: Crashing Servers!

Struggle 2: Scalability

Struggle 3: Security

Struggle 4: Consistency

Trade-off: Consistency and Performance

More About Consistency

Struggle 5: Performance

Summary

Reduce Network Usage - With This 1 Simple Trick!

Design Time Optimizations

Runtime Optimizations

The Simple Trick: Compression

How to Tell If My Application Make It Right?

Payload Comparison: Compress First vs. Encrypt First

Why Compression Doesn't Work After Encryption?

Further Reading

FeathersJS vs NestJS - Compared in 3 Key Areas

Application Structure

Application Structure - FeathersJS

Application Structure - NestJS

Customization Options

Customization Options - FeathersJS

Customization Options - NestJS

Community and Documentation

Community and Documentation - FeathersJS

Community and Documentation - NestJS

Summary

Scalable Websocket Server Implemented by ChatGPT

New favourite IDE unlocked: The Prompter

How to Better Use ChatGPT for Code Generation

Hashring Implementation

Websocket Server Implementation

Implementing Service Registry

Putting it All Together: Scalable Websocket Server

Results

How to Trace Websocket Events in NestJS - [Case Study]

What is a WebSocketAdapter?

How to Write a WebSocketAdapter in NestJS

Use Existing IoAdapter from @nestjs/platform-socket.io

Modifying The bindMessageHandlers

A Little Problem in NestJS

How about ack function, why does it disapper?

Solution for Providing Additional Parameters to Handlers

Creating the @ack Decorator

Lets Move On With RequestId

Next Steps