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.

Testing new frameworks & languages: how to separate the grain from the chaff

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

Technology is evolving very fast. Every 6 months you have a new cool framework, language or technology popping up on your Twitter timeline and RSS feeds. It seems that you need to be always riding the wave to be a successful developer.

At MarsBased, we take very seriously the decision of the technologies we use in our projects. We are a laser-focused specialised company, so we can't afford to use new technologies just because they're trending on Reddit

With this post, we want to share our internal process to decide what technologies we add to our tech stack.

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

Hablemos