How to Build a Node.js API (Part Two)

Diario del capitán, fecha estelar d614.y37/AB

Hi everyone (again)!

In my previous blog entry, I wrote the first part of our guide to create APIs using Node.js.

In this part, I'll give a quick introduction to express.js in order to understand how the Processes engine is organised (and the rationale behind). This is a pure technical javascript post, so be warned! ⚠️

Disclaimer: the source code examples are, in most of the cases, a simplification of the real code for easier legibility and to avoid compromising our client's code.

Are you ready to learn how express.js works? Let's dive into it!

How to Improve Self-Confidence when Writing Code

Diario del capitán, fecha estelar d598.y37/AB

One of the most frightening parts of being a developer is the recurring feeling that the solution that you are building is not going to work as intended, it is going to scale poorly or some of your coworkers will dislike working on top of it.

To give the best of yourself as a developer, you need to learn how to move away from these toxic feelings.

How to Build a Node.js API (Part One)

Diario del capitán, fecha estelar d593.y37/AB

Hi everyone!

I want to share with you how I built a Node.js API for one of our biggest clients, where I will describe some patterns and javascript conventions I've used. I will make it easy to export these ideas elsewhere so they can be useful for your projects.

I will break down this guide into several parts. My goal with this series posts is to make it easy to understand the rationale behind my decisions regarding code structure and conventions.

Disclaimer: the source code examples are, in most of the cases, a simplification of the real code for easier legibility and to avoid compromising our client's code.

The Importance of a Step Back to Find Quick Wins

Diario del capitán, fecha estelar d576.y37/AB

This week, I want to highlight the importance of taking a step back to analyse the applications we develop for our clients.

Being a consultancy means that all of our projects are for third parties (clients) who hire us for our expertise in Ruby on Rails or because they need more manpower and thus need extra people to increase their development pace.

Our clients always tend to prioritise new features. They feel that advancing equals building new features, but we need to advise them to take other factors into consideration.

Estás a un paso de conocer a tu mejor socio.

Contrátanos