
## What is LoRaWAN?

**LoRaWAN** (Long Range Wide Area Network) is a low-power, wide-area networking protocol designed for wireless battery-operated devices in regional, national, or global networks. It's built on top of the **LoRa** (Long Range) radio modulation technique, creating a complete ecosystem for Internet of Things (IoT) connectivity.

Think of it as the postal service for IoT devices – it's not the fastest way to send data, but it's reliable, reaches far distances, and doesn't require much power from your devices.

## Why LoRaWAN Matters

### The IoT Connectivity Challenge

Traditional connectivity options like WiFi, Bluetooth, and cellular networks fall short for many IoT applications:

- **WiFi**: Short range, high power consumption
- **Bluetooth**: Very short range, limited scalability  
- **Cellular (4G/5G)**: High power consumption, expensive data plans
- **Zigbee/Z-Wave**: Limited range, complex mesh networking

### The LoRaWAN Solution

LoRaWAN fills the gap by providing:

```
📡 Long Range: 2-15 km in rural areas, 2-5 km in urban areas
🔋 Low Power: Devices can run 2-10 years on a single battery
💰 Low Cost: Minimal infrastructure and device costs
🌐 Wide Coverage: Single gateway can serve thousands of devices
🔒 Secure: End-to-end encryption and authentication
```

## How LoRaWAN Works

### Network Architecture

LoRaWAN uses a **star-of-stars** topology:

![LoRaWAN Network Architecture](https://www.researchgate.net/publication/341298152/figure/fig1/AS:890182974836736@1589247568628/LoRaWAN-network-architecture.ppm)
*Photo by <a href="https://unsplash.com/@jorgedevs?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Jorge Ramirez</a> on <a href="https://unsplash.com/photos/a-cell-phone-tower-in-a-park-with-a-lake-in-the-background-0vmMg1r7FRU?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Unsplash</a>*

### Key Components

1. **End Devices (Nodes)**
   - Battery-powered sensors, meters, trackers
   - Send small amounts of data periodically
   - Examples: Temperature sensors, water meters, GPS trackers

2. **Gateways**
   - Act as transparent bridges
   - Connect to internet via WiFi, Ethernet, or cellular
   - Can handle thousands of devices simultaneously

3. **Network Server**
   - Manages device authentication and data routing
   - Handles network optimization (data rates, power levels)
   - Examples: The Things Network (TTN), ChirpStack, AWS IoT Core

4. **Application Server**
   - Your business logic and data processing
   - Receives decoded sensor data
   - Sends commands back to devices

## Technical Deep Dive

### LoRa Modulation

LoRa uses **Chirp Spread Spectrum** modulation:

- **Spreading Factor (SF)**: 7-12 (higher = longer range, lower data rate)
- **Bandwidth**: 125 kHz, 250 kHz, 500 kHz
- **Data Rates**: 0.3 kbps to 50 kbps
- **Frequency Bands**: 
  - EU868: 863-870 MHz
  - US915: 902-928 MHz  
  - AS923: 915-928 MHz

### Device Classes

**Class A (All devices support this)**
- Lowest power consumption
- Device initiates communication
- Two receive windows after each uplink
- Perfect for: Sensors, meters, simple monitoring

**Class B (Optional)**
- Scheduled receive windows
- Synchronized beacon from gateway
- More predictable downlink timing
- Perfect for: Actuators with timing requirements

**Class C (Optional)**
- Always listening (except when transmitting)
- Highest power consumption
- Immediate downlink capability
- Perfect for: Mains-powered devices, critical applications

## Advantages and Limitations

### Advantages ✅

- **Extreme Low Power**: Years of battery life
- **Long Range**: Kilometers without repeaters  
- **Low Cost**: Cheap devices and infrastructure
- **Scalable**: Thousands of devices per gateway
- **Standardized**: Open protocol with ecosystem
- **Secure**: AES-128 encryption built-in

### Limitations ❌

- **Low Data Rate**: Not suitable for high-bandwidth applications
- **Duty Cycle**: Limited transmission time (1% in EU, varies by region)
- **Latency**: Not real-time, seconds to minutes delays
- **Downlink Limited**: Few opportunities to send commands to devices
- **No Mesh**: Devices can't relay data for each other

## When to Choose LoRaWAN

### Perfect for:
- **Sensor Networks**: Temperature, humidity, air quality
- **Utility Metering**: Water, gas, electricity meters
- **Asset Tracking**: Low-frequency location updates
- **Environmental Monitoring**: Weather stations, soil sensors
- **Smart Agriculture**: Irrigation, livestock monitoring
- **Industrial Monitoring**: Tank levels, equipment status

### Not suitable for:
- **Real-time Control**: Traffic lights, emergency systems
- **High-bandwidth Data**: Video, audio, large files
- **Frequent Updates**: Applications needing constant data
- **Interactive Applications**: Chat, gaming, web browsing

Introduction to LoRaWAN


## Introduction

I wrote this post to share my experience with **Git worktrees**, one of the most powerful yet underutilized features in modern development workflows. With tools like Claude Code bringing them into the spotlight, it's time to understand why worktrees are becoming essential for efficient development.

The biggest advantage of Git worktrees is that you can focus on building features without worrying about branch switching overhead or losing context. **You can work on multiple branches simultaneously, each in its own directory**.

But in real-world applications, developers face frustrating scenarios like having to stash uncommitted changes just to check another branch, dealing with build artifacts when switching contexts, or losing their place when jumping between features. All this context switching ends up polluting the pure development flow, making the process harder to maintain and less productive.

I originally discovered this approach while working on complex projects that required frequent branch switching, and the productivity gains were immediately apparent.

## Implementation

Modern development tools have solved similar workflow challenges using parallel processing patterns. After experiencing the pain of traditional Git workflows, I researched various approaches to branch management.

Unfortunately, most developers stick with single-worktree workflows that don't leverage Git's full potential, so I decided to implement a comprehensive worktree-based approach.

**That's how my modern Git workflow was born.**

See more:
- [Git Documentation: git-worktree](https://git-scm.com/docs/git-worktree)
- [Pro Git Book: Advanced Git](https://git-scm.com/book/en/v2)

## How it works

### What Are Git Worktrees?

Git worktrees allow you to have multiple working directories associated with a single Git repository. Instead of constantly switching branches and dealing with uncommitted changes, you can check out different branches in separate directories simultaneously.

Think of it this way: traditionally, you have one working directory per repository. With worktrees, you can have multiple working directories, each with different branches checked out, all sharing the same Git history and objects.

```bash
# Create a worktree for an existing branch
git worktree add ../feature-auth feature/authentication

# Create a worktree with a new branch  
git worktree add ../hotfix-login -b hotfix/login-bug

# Create a worktree from a remote branch
git worktree add ../feature-new origin/feature/new-feature
```

### Parallel Development Workflow

The `worktree add` command is used to create different development contexts as "isolated environments". Each worktree maintains its own working state while sharing the same Git repository.

Information flows between worktrees when you push commits or update branches. Progress moves to different contexts when navigating between directories.

```bash
# Main development in your primary worktree
cd ~/projects/myapp
git checkout main

# Create a worktree for your feature
git worktree add ../myapp-feature -b feature/user-dashboard

# Work on the feature
cd ../myapp-feature
# ... develop feature ...

# Meanwhile, an urgent bug report comes in
# Create another worktree for the hotfix
cd ~/projects/myapp  
git worktree add ../myapp-hotfix -b hotfix/critical-bug

# Fix the bug in isolation
cd ../myapp-hotfix
# ... fix bug and push ...

# Return to feature development without losing context
cd ../myapp-feature
# Your work is exactly as you left it
```

`git worktree list` is a method that shows all active worktrees. It's used to track your parallel development environments.

### Advanced Worktree Management

Worktree cleanup works very similar to how resource management functions in system administration. When worktrees are no longer needed, you remove them properly to maintain a clean development environment.

You can manage multiple worktree lifecycles using structured commands. If directories are deleted manually, Git tracking needs to be cleaned up.

```bash
# List active worktrees
git worktree list

# Remove worktree properly
git worktree remove ../feature-auth

# Clean up deleted worktrees  
git worktree prune

# Move worktree to new location
git worktree move ../old-path ../new-path
```

## Advanced Techniques

### Bare Repository Workflow

For the ultimate worktree experience, start with a bare repository:

```bash
# Clone as bare repository
git clone --bare git@github.com:user/repo.git project.git
cd project.git

# Create worktrees for different purposes
git worktree add ../main main
git worktree add ../develop develop  
git worktree add ../feature-a feature/feature-a
```

This approach treats all branches equally, with no "primary" working directory.

### Integration with Modern Tools

**Claude Code and Worktrees**:
- Isolated experiments for testing AI-generated code changes
- Safe exploration of different approaches without affecting main work
- Quick comparisons between AI suggestions and current implementation
- Parallel development of multiple features simultaneously

**IDE Support**:
- VS Code extensions like "Git Worktrees" provide GUI management
- JetBrains IDEs have built-in worktree support in recent versions
- Vim/Neovim plugins for worktree management and navigation

### Best Practices

**Directory Organization**:
```
projects/
├── myapp.git/          # Bare repository
├── myapp-main/         # Main branch worktree
├── myapp-develop/      # Development branch
├── myapp-feature-x/    # Feature branches
└── myapp-hotfix-y/     # Hotfixes
```

**Naming Conventions**:
- Use consistent prefixes: `project-branch-name`
- Include issue numbers: `myapp-issue-123`
- Indicate purpose: `myapp-experiment-new-api`

## Wrap up

Git worktrees represent a paradigm shift in how we think about repository management. Instead of fighting with branch switching and context loss, we can embrace parallel development workflows that match how we actually work.

The workflow outlined here is continuously evolving as tools like Claude Code promote worktree usage, and I have ideas to improve developer adoption.

However, if you have any suggestions about implementing worktrees in your development process, please don't hesitate to contact me and let me know about it!

**Remember: The future of Git workflows is parallel, not sequential. Worktrees make that future available today.**

Links:
- [Git Worktrees Documentation](https://git-scm.com/docs/git-worktree)
- [Pro Git Book](https://git-scm.com/book)

Git Worktrees: Guide to Parallel Development


## Introduction

I wrote this post to share insights on transforming code reviews from bureaucratic checkboxes into **powerful catalysts for team growth and software quality**. Based on research from leading practitioners like Adrienne Braganza Tacke and Saša Jurić, this guide will revolutionize how you approach code reviews.

Code reviews are one of the most powerful practices in software development, yet they're often done poorly or treated as a mere formality. The biggest advantage of effective code reviews is that **they serve dual purposes**: catching defects while simultaneously building stronger, more knowledgeable teams.

But in real-world applications, many teams struggle with review processes that either rubber-stamp changes or get bogged down in nitpicks. All this ineffective reviewing ends up polluting what should be a collaborative learning experience, making the process harder to sustain and less valuable to the team.

## Understanding Code Reviews: More Than Just Bug Catching

At its core, a code review is **a process that software developers use to inspect each other's code and to make sure it passes a set of agreed-upon standards**. Think of it as double-checking your work before it goes live—like proofreading an important email or having someone review a document before publication.

### The Two Pillars of Effective Code Reviews

**1. Better Applications**
- Catch defects before they reach production
- Ensure code quality and maintainability  
- Verify security practices and performance considerations

**2. Knowledge Sharing & Team Building**
- Break down knowledge silos across the codebase
- Transfer context, nuance, and historical decisions
- Build collective ownership of the code

Remember: **Writing code is only 5-10% of a developer's time. Reading, comprehending, and understanding code in the context of the bigger system is where we spend most of our effort.**

## Implementation

Web frameworks have solved similar collaboration challenges using structured patterns. After researching various approaches to code review improvement, I found that most teams hadn't systematically addressed the core issues.

Unfortunately, the few solutions I found didn't meet the comprehensive needs of modern development teams, so I decided to compile the most effective practices from industry leaders.

**That's how this complete guide was born.**

See more:
- [Conventional Comments](https://conventionalcomments.org/)
- [Looks Good to Me: Constructive Code Reviews](https://www.manning.com/books/looks-good-to-me)

## How it works

### The Small PR Revolution

The single most impactful change you can make is **keeping pull requests small and well-organized**.

Large PRs cause reviewers to either rubber-stamp with "LGTM" without proper review or focus only on nitpicks because they can't see the forest for the trees.

**Target**: Reviewable in 5-20 minutes
**Structure**: Organize commits to tell a story incrementally  
**Content**: Each commit should be understandable on a single screen

Instead of one massive commit that "adds user authentication," break it down:

```js
// First commit: Update database schema for user table
// Second commit: Add basic user model and validation  
// Third commit: Implement authentication endpoints (happy path)
// Fourth commit: Add error handling and edge cases
// Fifth commit: Update tests and documentation
```

### Mastering Communication

The `suggestion` comment type is used to provide alternative approaches, while the `issue` type indicates blocking problems. Each comment type has a specific purpose and expected response.

Information flows between author and reviewer when using structured feedback. Progress moves to the next review cycle when calling `resolve`.

```js
// suggestion: Consider using a Map here instead of nested loops 
// for O(n) vs O(n²) performance, especially since we expect 
// this dataset to grow significantly.

// issue: This validation needs to handle null values before 
// the method can be safely called.

// praise: This is an excellent solution to a tricky problem!
```

`resolve` is a method that concludes discussion threads. It's used to iterate through the review feedback cycle.

### AI Enhancement Integration

AI integration works very similar to how middleware functions in web frameworks like Express. When AI tools are configured, they run automated checks first, then human reviewers focus on higher-level concerns while AI handles the routine tasks.

You can chain different AI and human review stages using structured pipelines. If automated tools flag issues, they're handled before human review begins.

```js
// Code Commit → AI Pre-Analysis → Automated Checks → Human Review → AI Summary → Merge

module.exports = new ReviewPipeline()
   .aiPreAnalysis(securityScan, performanceCheck)
   .humanReview(architectureReview, businessLogicCheck) 
   .aiSummary(documentationUpdate, changelogGeneration)
   .catch(errorHandler)
   .merge();
```

## Advanced Techniques

### Where AI Excels Today

**Automated Tasks**:
- Summarizing PR changes and writing descriptive titles
- Catching common security vulnerabilities and anti-patterns
- Enforcing consistent formatting and style guidelines
- Identifying potential performance issues
- Suggesting alternative implementations

**Documentation Support**:
- Generating comprehensive PR descriptions
- Creating inline code comments for complex logic
- Updating README files and technical documentation

### Current AI Limitations (2025)

**What AI Can't Do Yet**:
- Understand team dynamics and interpersonal context
- Grasp project-specific requirements and constraints
- Make nuanced architectural decisions
- Provide mentoring and knowledge transfer
- Understand the business context behind technical decisions

### Building Review Culture

**For Authors: Be Your Own First Reviewer**

Before submitting your PR, ask yourself:
- Is the title descriptive and clear?
- Have I provided enough context in the description?
- Would someone unfamiliar with this change understand the "why"?

**For Reviewers: Share the Responsibility**

Remember: You're just as responsible for bugs that slip through as the author is. Instead of thinking "the developer made a mistake," think "how did I miss that?"

## Wrap up

The future of code reviews isn't about choosing between human reviewers and AI tools—it's about leveraging both strategically. The package of practices outlined here is continuously evolving, and I have ideas to improve team adoption.

However, if you have any suggestions about implementing these practices in your team, please don't hesitate to contact me and let me know about it!

**Remember: Great code reviews aren't just about catching bugs—they're about building better software and stronger teams.**

Links:
- [Conventional Comments](https://conventionalcomments.org/)
- [Looks Good to Me: Constructive Code Reviews](https://www.manning.com/books/looks-good-to-me)

Guide to Effective Code Reviews: From Human Expertise to AI Enhancement


## TL;DR

- Use RFCs to create and refine technical proposals, this will improve not only your documentation but your decision making.
- Use ADRs to record a history of your technical decisions to improve the knowledge transfer in your team.
- It's recommended to implement templates to generate this documents: [Documented Software Decisions](https://github.com/emanuelcasco/document-software-decision-template).

## Introduction

Over a project life-cycle, **a great deal of time is spent in making decisions**, for example: how to design the solution to integrate a new service to our system, data migration from a legacy database, which third-party service use, and so on. The lack of a documentation process that follows the project growth can result in long-term problems, coming back your steps to recall why did you take a decision is usually a complicated task.

The passage of the time and the team rotation without documentation that enables the knowledge transfer results in the lost of lessons learned and valuable experiences. Citing the first lesson of History: **"Those who cannot remember the past are condemned to repeat it."**.

However, as I mentioned before this is a common problem in software development, therefore, there are a lot of possible solutions for it depending of your needs. In this post, I'm going to focus in two particular tools that have helped me in the past:

1. RFC to generate and iterate proposals.
1. ADR to record decisions.

## Request for Comments (RFC) to generate and iterate proposals

RFC usage is as old as the same Internet, or even more because [this tool was used to make decisions in the design of the WWW [World Wide Web](https://www.rfc-editor.org/rfc-index.html), besides, the use of this tool has increased over the last years guided by Open Source projects like [React](https://github.com/reactjs/rfcs) and [Rust](https://github.com/rust-lang/rfcs).

Basically, a RFC (Request for Comments) document **is a written technical proposal intended to encourage the iteration of a solution based on exhaustive analysis and peers feedback**. The objective is to come up the best possible solution for a problem and mitigate the risk of complications at the development, definitely, we are talking about **making better decisions**.

### Life-cycle

1. **Proposal**: Change proposal document is presented.
2. **Iteration**: The proposal is iterated based on feedback to find issues or improvements. At this moment, is possible that we find out the solution is inviable, in that case, the RFC should be marked as ""deprecated.
3. **Implementation**: When the proposal has matured enough then we can close the document and implement the solution.
4. **Maintaining**: Once implemented, the solution may require some modification, in that case you can either modify the original document or update set it as "deprecated" and reference it from a new RFC document with the change proposal.

👉 *It is not recommended to modify an already implemented RFC as doing it will reduce its value as "history".*

### Examples

- [Notion RFC](https://www.notion.so/RFC-Template-Title-8df1bd0d24b0440486fe133eecdf4a5e).
- [RFC Template | Emanuel Casco](https://github.com/emanuelcasco/document-software-decision-template/blob/main/rfc/template.md).

## Architectural Decision Records (ADRs) to record decisions

An Architectural Decision  is _software design related decision that could imply either functional as non-functional requirements and has a **significant** impact over our system architecture."*_

An Architectural Decision Records (ADR) is a document that **record an Architectural Decision**, with its context and consequences. Usually, an ADR is the last step of a full decision making process that included a RFC document creation, but this is not always true.

Some ADR benefits are:

- **Improve knowledge transfer** (onboardings or rotations), as the people joining the team can read the last team decision and infer how it works, and so on.
- **Improve alignment between members**. Unilateral decisions risk is mitigated as all impactful decisions are consensual.

### When to create an ADR?

To ask this question I like to make reference to the following post from Spotify Engineering blog:

As  Josef Blake from Spotify mention in [this post](https://engineering.atspotify.com/2020/04/14/when-should-i-write-an-architecture-decision-record/): _"always you made a significant decision that impacts how engineers write software."_

What is a "significant decision" is something your team has to decide and depends on the context. There is no golden rule but it is more a construction based on your and your team experience. However, keep in mind the following topics:

- All RFC document must has an ADR.
- If your team take any "significant" in a meeting, it must be reflected in your ADRs.

Following links include RFC examples and tools:

- [ADR Tools | Nat Pryce](https://github.com/npryce/adr-tools).
- [ADR | GitHub](https://adr.github.io/).
- [ADR Examples | Joel Parker Henderson](https://github.com/npryce/adr-tools).
- [ADR Template | Emanuel Casco](https://github.com/emanuelcasco/document-software-decision-template/blob/main/adr/template.md).

## Last considerations

The adoption of these tools in your team could not be easy, documentation process are often a conflict point in the engineering teams. My first advice would be: be patient. **It is necessary, for this process to work, that your team get involved in it**.

### First Steps

- **KISS** (Keep It Stupid Simple), **it is important to keep the documentation methodology as simple as possible in order to succeed.**
- **The process must adapt your team, not the other way around**.
- **Take the first step.**. Once the tools and the platform your team is going to use to write the documents, it is a good idea to create the first documents as a reference for the rest of the team. You could even write a document recording that you decided to write documents using RFC and ADR.
- Also **is a good idea to create templates for your documents**, or an script to generate them. The [following link](https://github.com/emanuelcasco/document-software-decision-template) includes some documents templates.

### Graphic guide of when and how to document

![Diagram Flow to document](/assets/blog/document-with-rfc-and-adr/image01.png)

## Conclusions

That's all for now! Hopefully this post has been helpful to you, below you will find a list with useful resources in case you are interested in continuing reading about these topics:

- [Templates | Emanuel Casco](https://github.com/emanuelcasco/document-software-decision-template).
- [When should I write an ADR? | Spotify Engineering Blog](~https://engineering.atspotify.com/2020/04/14/when-should-i-write-an-architecture-decision-record/~).
- [ADR Tools | Nat Pryce](https://github.com/npryce/adr-tools).
- [ADR | GitHub](https://adr.github.io/).
- [ADR Examples | Joel Parker Henderson](https://github.com/npryce/adr-tools).


Document your technical decisions using RFC and ADR


## Introduction

This article presents a **collection of good practices working with [Azure Functions](https://docs.microsoft.com/en-us/azure/azure-functions/) in Node.js**. Recommendations have been extracted and adapted from Azure documentation and personal experiences.

Although this post will focus on Node.js, good practices presented on it can be useful for any language.

This post was originally published on Medium, you can find it here: [Improve your Azure Functions with this best practices](https://medium.com/@emanuelcasco/improve-your-azure-functions-with-this-best-practices-da8fd0123318).

## TL;DR

- Avoid long running functions.
- Avoid cross-functions communication.
- Share and manage connections.
- Keep functions pure.
- Use an infrastructure orchestrator.
- Write defensive functions.
- Avoid code pollution.

## Avoid long running functions

A function can become large due many dependencies or heavy processing operations. This result in unexpected timeouts and unfinished procedures.
To prevent this, you can:

- Avoid large dependencies whenever possible.
- Refactor large functions into smaller pieces of code that work together and return responses fast.
- Respect the "single responsibility principle", each function should have a single responsibility over a single part of the functionality provided by the software.

![Refactor large functions into smaller pieces of code that work together and return responses fast.](/assets/blog/improve-your-azure-functions-with-this-best-practices/image01.png)

For example, imagine you have a HTTP trigger function. HTTP requests usually need a quick response, thus you can pass the HTTP trigger payload into a queue and process it with a queue trigger function

## Avoid cross-functions communication

Azure Functions are not built to manage communication between functions. **Prefer Azure Queue Storage for cross-function communication**. Queue storage gives you asynchronous message queueing for communication between functions.

![Prefer Azure Queue Storage for cross-function communication](/assets/blog/improve-your-azure-functions-with-this-best-practices/image02.png)

If you need build topologies with complex routing you can use [Service Bus](https://azure.microsoft.com/en-us/services/service-bus/) which helps you to deliver messages to multiple subscribers and filter them before processing. In the other hand, [Events Hubs](https://azure.microsoft.com/en-us/services/event-hubs/) are useful to support high volume communications.

## Share and manage connections

**Creating and destroying instances of a shareable object can hurt performance.** Here are some guidelines to follow when manage connections:

- Reuse client instances rather than creating new ones with each function invocation.
- Create a singleton client and reuse it for every function invocation.
- Maintain this singleton pure.

```js
// DO NOT ❌
// myFunction.js
const Redis = require('redis');
module.exports = function (ctx, input) {
   const redis = new Redis(config);
   ...
};

// DO ✅
// myFunction.js
const Redis = require('redis');
const redis = new Redis(config); // re-utiliced by Azure
module.exports = function (ctx, input) { ... };

// CONSIDER 👍
// redisWrapper.js
const Redis = require('redis');
let redis;​
const instanceService = config => redis || new Redis(config);
module.exports = config => instanceService(config);
// myFunction.js
const redis = require('redisWrapper');
module.exports = function (ctx, input) { ... };
```

If you want to know more, please visit [Manage connections in Azure Functions](https://docs.microsoft.com/en-us/azure/azure-functions/manage-connections).

## Keep functions pure

A pure function has two main characteristics:

- Is **stateless**, produces no side effects.
- Is **deterministic**, given the same input, will always return the same output.

**Azure Functions runs in stateless compute containers that are event-triggered**, ephemeral (may last for one invocation), and fully managed by the cloud provider. So it is not recommend storing state within the application itself. Associate any needed state information with your data and store it an external datastore like DocumentDB or Azure SQL.

## Use an infrastructure orchestrator

**Serverless still requires infrastructure management**. Managing serverless infrastructure requires discipline to ensure it can be effectively maintained.

To manage your infrastructure, and keep it documented, it is recommended to use an infrastructure orchestrator. Infrastructure as code is a way of managing your devices and servers. This is done through machine-readable definition files.
Basically, you write down how you want your infrastructure to look like and what code should be run on that infrastructure. A highly recommended tool is [Terraform](https://www.terraform.io/).

## Write defensive functions

**Assume your functions could throw an exception at any time**. They should be able to continue from a previous fail point in the next execution. If you are using a queue to communicate, consider a re-queue strategy in order to not lose information.

Azure will retry to process a failed function input when you pass an error with the `context.done` method. Retries number and time window between them are defined in your `host.js` file.

Also, you can implement a custom [exponential backoff strategy](https://en.wikipedia.org/wiki/Exponential_backoff) to re-queue your messages after an increasing range time. This is especially useful to dispel possible inconveniences caused by high traffic.

**Validate your inputs!** You can implement [Object Schema Validation](https://json-schema.org/understanding-json-schema/reference/object.html) in your functions before processing inputs. There are great tools out there but I recommend:

- [Joi](https://github.com/sideway/joi), the most widely adopted package for object schema validation. It has a great api and excellent documentation.
- [Ajv](https://ajv.js.org/).

Meet the **Meet the Dead Letter Queue (DLQ)**. Azure Service Bus stores messages in the queues until processed, but there are several reasons for such undelivered messages, like exceeding MaxDeliveryCount, exceeding TimeToLive, errors while processing subscription rules, etc.
What happens with undelivered messages? They are sent to an DLQ.

If you want to access the undelivered message from the Topic then, the syntax of reading the Dead Letter Queue will be:

`TopicName/Subscriptions/SubscriptionName/$DeadLetterQueue`

## Avoid code pollution

Serverless architectures biggest benefit is you can focus on implement your business logic. Problems begin when you have to **deal with common technical concerns outside your business logic**. For example: input parsing and validation, output serialization, error handling, and more.

All this necessary code ends up polluting your business logic, making it harder to read and maintain. [Azure Middleware Engine](https://www.npmjs.com/package/azure-middleware) helps developers to **divide the problem in smaller pieces**, isolating logic into “steps”, keeping your code clean, readable and easy to maintain.

If you are interested, I wrote a post about this tool, you can find it here: [Implement middleware pattern in Azure Functions](/en/blog/azure-functions-middlewares).

Example:

```js
const ChainedFunction = new MiddlewareHandler()
  .use((context, input) => {
    asyncFunction(input).then((res) => {
      context.log.info('Im called first');
      context.next();
    });
  })
  .use((context) => {
    context.log.info('Im called second');
    context.done(null, { status: 200 });
  })
  .catch((err, context, input) => {
    context.log.error(`Something went wrong. Error: ${err}`);
    context.done(err, { status: 500 });
  });

module.exports = ChainedFunction.listen();
```

## Wrap up

So, we conclude here. This good practices helped me and my team improve productivity, code quality and functions performance. I hope them benefit you and your team also. Let me know if it were useful to you, and if not you can share your experience with us in the comments.

Useful links:

- [Azure Functions Middleware](https://www.npmjs.com/package/azure-middleware).


I'm Emanuel Casco

Blog.