Hey, I'm Marco and welcome to my newsletter!
As a software engineer, I created this newsletter to share my first-hand knowledge of the development world. Each topic we will explore will provide valuable insights, with the goal of inspiring and helping all of you on your journey.
In this inaugural post, we will dive into my transition from Rails to Node.js, a decision that not only shaped my career but also opened up new possibilities.
1) 💼 Rails and my first job
As I approached the final stage of my undergraduate studies, I was faced with the decision of whether to undertake an internal project with a professor or to gain practical experience in a company. Given my desire to dive straight into the world of work, I chose the option of working in a company. This decision involved juggling job responsibilities and preparing for the last two exams needed to complete my academic coursework-a challenging but crucial period for my career.
Thanks to my advisor, I was put in touch with a startup focused on the travel industry, where I began my career path. Technology stack included Rails for the backend and React for the frontend.
My previous experience had been mostly in Java, learned during my first years of university, Visual Basic and Pascal from high school. With Rails, it was love at first sight: a clean, easy-to-read syntax devoid of the verbiage of Java.
I continued to work for the company as I was graduating. Toward the end of this period the startup closed and, faced with this circumstance, I made the decision to switch to Node.js. Why?
2) 🚀 Transition to Node.js
The shift to Node.js marked a significant juncture in my professional journey, driven by two primary factors that had become pivotal in my evolving approach to development.
1) 🔍 Greater Understanding of How Things Work
After years of using Rails, I grew increasingly tired of its all-encompassing nature. Rails handled everything on its own-from test frameworks, authentication, router controllers, variable environment management, log, caching, cookies, using convention-over-configuration philosophy. While Rails has undeniably simplified the development process, it has obscured vital details that I believe are essential for deeper understanding. For some this level of abstraction might be greatly appreciated, but for me it lacked the granularity I desired. I found greater satisfaction in setting everything up independently according to my preferences, that way I understood all those details that Rails inevitably hid.
With Node.js, particularly leveraging the Koa.js library, I have created an all-in-one template who I use in each projects, it includes carefully curated configuration:
Testing framework: Vitest, I'm currently exploring the native test runner added on the core on v20.
HTTP Calls: Handled via Axios.
Mock HTTP Calls: Utilizing the axios-mock-adapter library.
Authentication: Employing JWT with a dedicated library jsonwebtoken.
Router-Controller structure: Organized with a file containing routes pointing to controller methods in another directory.
Environment Variable Management: Initially handled with dotenv, but with Node.js v20 they are now supported natively using --env-file option at server startup.
Logger: A file exporting a wrapper for console.log, adding crucial information that I find invaluable, especially during debugging.
Caching: Leveraging the memoizee library for relatively stable structures, or Redis with a dedicated process for more dynamic scenarios.
Environments: Managed through different scripts in the package.json file, each catering to a specific environment.
Database: Utilizing Postgres with a dedicated communication library.
Deploy: Heroku, less then 5 minutes to complete the configuration.
If you're intrigued by my startup template or curious about how I optimize costs and configuration with Heroku, feel free to express your interest in the comments below.
This custom configuration gives me the flexibility and control I want.
With this configuration, I have implemented a wide range of projects and architectures. Specifically:
Keep reading with a 7-day free trial
Subscribe to Implementing to keep reading this post and get 7 days of free access to the full post archives.