I'm building a Functions app API for a project at work. This API needs to communicate with another product's API and so is moving OAuth tokens back and forth. 

In my infinite wisdom, I thought these would be best placed into the HTTP headers of the requests (and obviously the Bearer token has to be in HTTP requests to the API's).

It has taken me two full days to get the headers appearing in the client Javascript...

### Adding Response Headers

Azure functions in nodejs expose a response object in the context of the function:

`context.res`

This res object contains various information about the response to be sent to the client, generally most importantly the HTTP status code, the response data body and finally the response headers.

```javascript
context.res.status = 200; //Everything worked!
context.res.body = {
  id: 1,
  name: 'Adam',
  age: 59
};
context.res.headers = {};
```

By default, the headers object is instantiated but has no properties in it.

Because this is a simple POJO, adding key: value pairs into the headers object is trivial.

```javascript
context.res.headers = {
  'authorization': access_token,
  'refresh_token': refresh_token,
  'expires_in': expires_in,
  'token_expiry': token_expiry
};
```

Running the function will show these headers in the Network tab of your developer tools and if you're like me, you'll be lulled into a false sense of success thinking that this is all there is to it.

### Actually Accessing the Values in the Client App

I made dozens of HTTP requests to the function endpoints while figuring this out and being completely lost as to why the headers weren't available to me in the response object returned to the client.

In my case, I am using the axios library to handle my HTTP requests. By default, axios returns a headers object directly on the main response object:

```typescript
const response: AxiosResponse<any> = await axios.get(endpoint);
const headers = response.headers;
```

The thing was, this headers object did not contain any of my custom headers. All I could access was the default headers returned by HTTP requests.

### The Secret Sauce

After spending hours scratching my head and swearing at the screen, I found it! 

Reading through page after page trying to understand what would hide a header eventually led me to try to explicitly define the expected headers. This is where I found the extra secret sauce header I needed to include:

```javascript
'Access-Control-Expose-Headers': 'authorization, refresh_token, expires_in, token_expiry',
```

The `Access-Control-Expose-Headers` header is a sneaky, infrequently discussed header that can be added to any response object. It tells the client to open up access to a specific set of pre-defined headers as defined by the server. 

This makes perfect sense for security purposes to make sure only the expected headers are received and actually accepted, but wow it took a long time for me to find it.

Now when I made the HTTP request to my Azure Functions nodejs API, the `response.headers` object magically contained all the headers and the values I'd assigned. Perfection!

### In Conclusion

In conclusion, if you need to send custom HTTP headers from an Azure Function in nodejs, the `Access-Control-Expose-Headers` is your best friend.

Just tell it which headers you are sending back from your server and they'll magically appear in the POJO response data.

Adding custom headers to the response object of of an Azure Function written in Node sounds simple. Turns out it may not be as simple as it sounds.

Adding Custom HTTP Headers to an Azure Function Response in Nodejs

### What is an HTTP Interceptor?

Every HTTP transaction that occurs between the client and server of web applications has a request and a response.

The client requests something or sends something to the server. The server processes this and responds with a response.

HTTP Interceptors allow the client application to modify either (or both) the content of the request and response. For those familiar with Nodejs, the HTTP interceptor is not too dissimilar from Express middleware in that it acts as a middle-man to the requests.

### Common Uses

The most common use I come across in general development is to add JWT access tokens into the outgoing request headers for a server to validate with. Generally, this will mean accessing the JWT from wherever it is being stored (hopefully not local storage) and appending a new header value with the correct name for the server to accept, validate and continue with the request.

The other common use I have implemented is to add additional data into the response object. Generally, this will be a piece of information that is required for all responses to be processed by the client, but not actually data that needs to make the trip to and from the server. This could be a local user Id or email address, or some other display-only data.

### Adding the Interceptor

Assuming you already have an Angular app spun up, adding the interceptor itself is relatively trivial.

In my projects, I either create a new provider in a servers/providers folder or a separate folder just for the interceptor:

~/angular-app/src/app/services/http-interceptor.service.ts

or

~/angular-app/src/app/interceptors/http.interceptor.ts

But either way, the file needs to be a provider file as per Angular providers.

The implementation of this file at a base level is very simple. The service class must implement HttpInterceptor from the "@angular/common/http" part of the Angular framework. This brings in the requirement to have a function definition of intercept() which handles the request modification:

```typescript
import { Injectable } from '@angular/core';
import { HttpInterceptor, HttpRequest, HttpHandler, HttpEvent } from "@angular/common/http";

@Injectable({
  providedIn: 'root'
})
export class HttpInterceptorService implements HttpInterceptor {
  constrcutor() { }
  
  intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> { 
    let headers = request.headers.append('Content-Type', 'application/json');
    const requestClone = request.clone({
            headers
          });
    return next.handle(requestClone);
  }
}
```

In the above example, we're simply adding the Content-Type header to all outgoing requests.

The real magic is the request.clone() function. As it says, it creates a new copy of the outgoing request and allows us to modify it before using it as the outgoing request information.

In addition to the above file, in order for the interceptor to fire correctly, the Angular module needs to be updated to tell the app the interceptor exists. So, in the app.module.ts file you will need to add an additional provider:

```typescript
import { AppComponent } from './app.component';
import { HttpClientModule, HTTP_INTERCEPTORS } from '@angular/common/http';
import { HttpInterceptorService } from './services/http-interceptor.service';

@NgModule({
  declarations: [AppComponent],
  entryComponents: [],
  imports: [...],
  providers: [
    ...,
    { provide: HTTP_INTERCEPTORS, useClass: HttpInterceptorService, multi: true }
  ],
  bootstrap: [AppComponent]
})
export class AppModule { }
```

That's all there is to it. The logic of the intercept function should do all the work required to modify the request.

An HTTP interceptor is a piece of logic that is able to attach to a HTTP request or response. This logic can then modify the data being transferred.

How to setup an Angular HTTP Interceptor

![React-Stock-Image](/assets/react-face-code.jpg "React Code")

### Create a React App

The first thing we'll need to add HTTP interceptors to is an app...

Using the instruction on the Create-React-App site, [create a React app with Typescript](https://create-react-app.dev/docs/getting-started#creating-a-typescript-app).

### Add Axios to the App

For those unfamiliar with [Axios](https://github.com/axios/axios), it is an npm package for making HTTP requests.

After the app has finished setting up, in a terminal add Axios to the app:

`npm i axios`

### Configure the HTTP Interceptors

It is trivial to actually configure the interceptors in your React app.

In the index.tsx file of your React app add the following:

```typescript
import axios from "axios";

// Configure outbound request interceptor logic
axios.interceptors.request.use(request => {
  return request;
}, error => Promise.reject(error));

// Configure incoming response interceptor logic
axios.interceptors.response.use(response => {
  return response;
}, error => Promise.reject(error));
```

These two use() calls on the request and response objects in the Axios interceptors does the magic to modify the outgoing request and the incoming response data. 

In the anonymous arrow function, it is possible to configure any custom logic required for your app.

Commonly, this will be adding auth token headers along with setting/retrieving other headers or local storage values.

A how-to for adding HTTP interceptors to a Create-React-App app with the Axios npm library to check and modify request and response headers for all HTTP requests

HTTP Interceptors in a Create-React-App with Axios

![http methods explained for frontend developers](/assets/pexels-pixabay-356043.jpg "http methods explained for frontend developers")

Frontend developers will inevitably need to make HTTP requests frequently when building out the client-side of a full-stack app. Having a solid understanding of these methods and how to build the requests is essential in being a top-shelf frontend developer.

### The HTTP Methods

There are four main HTTP methods that a good frontend developer will know like the back of their hand:

1. GET
2. POST
3. PUT
4. DELETE

### HTTP Get

The GET method is fairly self-explanatory - use it when the app needs to retrieve information from the API. GET requests can have parameters added that will allow the API to filter the data returned based upon the parameter value. 

The parameters can be added to the API URL as query string parameters or added to the overall requests in a params object, depending on the HTTP helper package you may be using.

### HTTP Post

The POST method is used when the client app needs to send data to the API for the purpose of a completely new entry being created in the database. Examples of this would be when a new user creates an account in your app and then when that user creates their first entity in the app.

The data that is sent to the API is sent via a 'body' object that is added as an argument to the HTTP request. The format of this body object can be different depending on what the API is configured to accept, but generally, it will either be a plain Javascript object or the JSON stringification of that same object.

### HTTP Put

The PUT method is used to update an existing database entry. It is similar to the POST in that the HTTP request sends a body argument that is the object of data to be used to update the existing record. 

An example of this would be the same user above going to the settings section of your app and updating their username and email address. These two values are then sent to the API along with a unique ID to find the record and the API then updates the existing record with the new username and email address.

### HTTP Delete

Again, similarly to the GET requests, the DELETE request is fairly self-explanatory. The DELETE Method is used to remove an entry from the application database. Generally, the delete action performed by the API is more complicated than simply deleting an entry as foreign key mappings need to be maintained or deleted accordingly to ensure data integrity is retained. From the frontend, however, it is not likely you'll need to worry with more than sending the correct ID of the main data entity to be deleted. 

The HTTP DELETE request also accepts a body object, but it specifically requires that this object has a data property that contains the information about the entity to delete.

Frontend developers will inevitably need to make HTTP requests frequently when building out the client side of a full stack app. Having a solid understanding of these methods and how to build the requests is essential in being a top shelf frontend developer.

HTTP Methods Explained for Frontend Developers

## W﻿hat is Web Server Caching?

Web server caching is the storage of frequently accessed data in a secondary, temporary location to reduce the overall load on a web server. Caching allows data to be served directly from memory which can be faster and more efficient than making multiple connections to the actual database.

## W﻿hy use Caching?

T﻿he basic premise is that a user makes a request from a web app that interacts with an API and a database. The first time the user makes the request, the data retrieved by the API is inserted into a cache store. Each time the user then makes the same request again, the API retrieves the data from the cache store instead of executing the full logic of connecting to the database, retrieving the required data and applying any additional business logic. This reduces the load on the web server and database.

F﻿or heavily used apps, caching can have many benefits beyond performance. Reducing the data egress of the app will reduce costs (depending on the app architecture), and reduce compute power required by the web server (again reducing costs).

T﻿he type of data that might be cached could be: 

* The product catalogue on an e-commerce store The products offered remain static mostly, only the stock availability will change and would need to be handled separately.
* Database query results. Frequently executed database queries could be cached if the result set is static, perhaps if the values for a dropdown are fed from a data table.
* User Sessions. Caching is used to help manage user session data, such as login information, shopping cart contents or persisting user-defined settings for an app.

## H﻿ow to Configure Web Server Caching

T﻿here are a few different ways that a cache store can be configured. In today's technology environment, there is a multitude of Cache-as-a-service providers that can greatly reduce the complexity of implementing a caching system.

T﻿wo of the more popular cache store technologies are [Redis](https://redis.io/) and [MemCached](https://memcached.org/). Both of these technologies are supported by the main cloud providers:

* Amazon ElastiCache: A fully managed in-memory data store service offered by Amazon Web Services (AWS). Amazon ElastiCache supports both Redis and Memcached, and offers features such as backup and restore, automatic failover, and data encryption.
* Google Cloud Memorystore: A fully managed Redis service offered by Google Cloud. Google Cloud Memorystore provides a highly available and scalable Redis instance that is easy to set up and use.
* Microsoft Azure Cache for Redis: A fully managed Redis service offered by Microsoft Azure. Azure Cache for Redis provides high-performance and low-latency caching for web applications, and supports advanced features such as Redis clustering and data persistence.

### A﻿ NodeJs Example Cache Configuration

\*﻿This assumes you have a functional knowledge of NodeJs and Express.

A﻿fter setting up a Redis instance with a cloud provider of your choice, we need to configure our nodeJs Express app:

```typescript
// Import the required npm packages 
import express from 'express';
import { createClient } from 'redis';

// Create the app and redis client
const app = express();
const client = createClient({
  host: '<URL TO THE CLOUD REDIS INSTANCE>',
  port: 6379 // Default Redispor. Change as requierd.
});
// Connection and Error event listeners for the Redis instance
client.on('connect', function() {
  console.log('Redis client connected');
});

client.on('error', function (err) {
  console.log('Something went wrong ' + err);
});

// Middleware to check cache first
const checkCache = (req, res, next) => {
  const { id } = req.params;

  client.get(id, (err, data) => {
    if (err) throw err;

    if (data !== null) {
      res.send(JSON.parse(data));
    } else {
      next();
    }
  });
};

// API endpoint with caching
app.get('/product/:id', checkCache, (req, res) => {
  const { id } = req.params;

  // Query database for product with given ID
  const product = { id, name: "Example Product", price: 9.99 };

  // Store product in cache for next request
  client.set(id, JSON.stringify(product), {TTL: 3600 });

  res.send(product);
});

app.listen(3000, () => console.log('Server running on port 3000'));

```

I﻿n this express app the Redis library is imported and used to create a connection to the cloud Redis instance.

T﻿hen, a middleware is set up that checks the Redis store for an object using the given id. If the Redis store does contain the required data for the given id, then the actual endpoint logic is bypassed and the data is returned immediately to the user/client.

I﻿n the actual endpoint/product/:id, the product is retrieved from the 'database' and put into the cache. This will only execute if the data does not exist in the Redis cache store.

I﻿n this example, the cache entry has a 'time-to-live' value. This basically puts an expiration date on the data in the Redis store. When this expiration is reached, the data is automatically removed. The next request to the API for that product id will need to be retrieved from the database and put into the cache store again.

Web server caching is the storage of frequently accessed data in a secondary, temporary location to reduce the overall load on a web server. Caching allows data to be served directly from memory which can be faster and more efficient than making multiple connections to the actual database.

Adding Custom HTTP Headers to an Azure Function Response in Nodejs

How to setup an Angular HTTP Interceptor

HTTP Interceptors in a Create-React-App with Axios

HTTP Methods Explained for Frontend Developers

What is Server Caching and When to Use Caching