IN 1995, WHEN I WAS IN MY SECOND YEAR IN COLLEGE, I was introduced to UNIX network programming. In C, you could create sockets to open TCP connections to servers and code the servers that accepted these connections. I remember the excitement I felt the fi rst time I created a TCP server: I could accept connections and receive and send messages on them.
If I wanted my server to accept many concurrent connections, the common solution was to use threads, and soon I had created my fi rst multi-threaded TCP server. This server accessed a shared data structure, which needed to synchronize the access to all the client threads that had been spawned. Getting the synchronization fi ne-grained (to maximize resources and time) and right (to avoid deadlocks) proved to be more diffi cult than anticipated.
A couple of years later, I entered the working world to become a consultant, programming and leading teams of programmers to implement various client projects. At fi rst I continued to work within the UNIX world, but soon I was diverted to Java and all its enterprise fl avors and fi nally landed on the fertile plains of web development, using scripting languages like PHP and Ruby. Doing web development, I slowly became familiar with JavaScript and the event-driven programming model, never realizing it would later connect me back to the world of UNIX.
Fast-forwarding to early 2010, a good friend of mine talked to me about Node.js. It was fast, he said, and you can program it in JavaScript. It transported the event-driven browser programming into the UNIX network programming world.
Curious, I went to take a look at the API documents and was immediately hooked. The ease with which you could create highly scalable servers without using threads and mix-and-match client and server code made me take a deep dive into Node’s source code and surrounding modules. Node.js connected the ease of a scripting language with all the power of UNIX network programming, and I felt like I was fi nally home.