DEV Community: Raymond Ottun

Deployment Patterns in Kubernetes

Raymond Ottun — Tue, 24 Oct 2023 14:08:05 +0000

Deployment Patterns

In this post, I will discuss different deployment patterns that you can use to deploy your application. I will also discuss how you can implement these deployment patterns in Kubernetes.

Recreate

With this deployment pattern, you deploy a new version of your application and delete the existing version of the application. This is the simplest deployment pattern, but it can result in downtime for your application as shown in the following diagram.

)

Ramped

With this deployment pattern, you deploy a new version of your application alongside the existing version of the application. Once the new version is ready, you gradually shift traffic from the existing version to the new version. This is the default deployment strategy in Kubernetes.

Canary

With this deployment pattern, you deploy a new version of your application alongside the existing version of the application. Once the new version is ready, you shift a small percentage of traffic from the existing version to the new version. If the new version performs well, you continue shifting traffic until all traffic is shifted to the new version. If the new version performs poorly, you stop shifting traffic and continue to use the existing version.

Blue/Green

With this deployment pattern, you deploy a new version of your application alongside the existing version of the application. Once the new version is ready, you switch traffic from the existing version to the new version.

A/B Testing

With this deployment pattern, you can test a new version of your application by deploying it to a subset of users alongside the existing version of the application.

Shadow

With this deployment pattern, you can test a new version of your application by deploying it alongside the existing version of the application. However, instead of sending client traffic to the new version, you send a copy of the traffic to the new version. This allows you to test the new version without impacting the existing version.

Hopefully, this post has given you a better understanding of different deployment patterns that you can use to deploy your application.

Decorating The Fetch API

Raymond Ottun — Thu, 12 Oct 2023 17:19:16 +0000

Like most full stack javascript developers, I have come to love the web Fetch API. It is a simple and elegant way to make http requests but the Fetch API lacks some features (and rightly so) that are essential for making http requests in a production environment. Here are some of those features:

In this post, I will show how to use the decorator pattern to enhance the Fetch API and add some of these features without modifying the Fetch API itself.

What is a decorator?

A decorator is a function that takes another function and extends the behavior of the latter function without explicitly modifying it. They key point is that a decorator function returns a modified version of the original function.

Logging decorator

The simplest decorator to implement is the logging decorator. It simply logs the url and the response of the http request. Here is the code:

type Fetch = (...args: any) => Promise<Response>;

interface Logger {
    log: (message: string) => void;
    info: (message: string) => void;
    error: (message: string) => void;
    warn: (message: string) => void;
}

export const withLogger = (fetch: (...args: any) => Promise<Response>, logger: Logger = console): Fetch => {
    return async (...args) => {
        const [input] = args;
        const response = await fetch(...args);
        if (typeof input === "string") {
            logger.info(`fetching ${input} and got ${response.status}`);
        }
        else if (input instanceof URL) {
            logger.info(`fetching ${input} and got ${response.status}`);
        }
        else {
            logger.info(`fetching ${input.url} and got ${response.status}`);
        }
        return response;
    }
}

Now we can use the withLogger decorator to log the url and the response of the http request.

// This behaves exactly like the fetch api
const fetchWithLogger = withLogger(fetch);
// This will log the url and the response of the http request
fetchWithLogger("https://jsonplaceholder.typicode.com/todos/1");

Retry decorator

A more useful decorator is the retries decorator. It retries the http request if it fails. Here is the code:

interface RetryOptions {
    retryCount: number
    retryDelay?: number
    retryOn?: number[]
}

export const withRetry = (fetch: Fetch, options: RetryOptions) => {
    const { retryCount = 1, retryDelay = 1000, retryOn = [500] } = options;
    let response: Response;
    return async (...args: any): Promise<Response> => {
        let retry = 0;
        while (retry < retryCount) {
            response = await fetch(...args);
            if (retryOn.includes(response.status)) {
                retry++;
                await new Promise((resolve) => setTimeout(resolve, retryDelay));
            }
            else {
                return response;
            }
        }
        return response;
    }
}

Now we can use the withRetry decorator to retry the http request if it fails.

// This behaves exactly like the fetch api
const fetchWithRetry = withRetry(fetch, { retryCount: 3 });
// This will retry the http request if it fails
fetchWithRetry("https://jsonplaceholder.typicode.com/todos/1");

Chaining decorators

One of the advantages of using a decorator is that they can be chained together to even further extend the behavior of a function. This is called composition. Here is an example of how to use the withLogger and withRetry decorators together.

const fetchWithRetryAndLogger = withLogger(withRetry(fetch, { retryCount: 3 }));
// This will retry the http request if it fails and log the url and the response of the http request
fetchWithRetryAndLogger("https://jsonplaceholder.typicode.com/todos/1");

This github repository contains the full code for the decorators discussed in this post.

Conclusion

The decorator pattern is a simple and elegant way to extend the behavior of a function without explicitly modifying it. It is a powerful tool in the hands of a developer and can be used to solve a lot of problems. In this post, I have shown how to use the decorator pattern to enhance the Fetch API and add some features that are essential for making http requests in a production environment.

References

Let’s prototype a GraphQL API with Zero code

Raymond Ottun — Tue, 07 Jul 2020 10:28:12 +0000

Your Profile : Frontend developer

Problem : Your company is developing a Trello clone to augment its existing product line

Features

Develop a new Trello-like schema functionality
Use existing user base as members for the functionality

Technical

A GraphQL API with schema agreed with the backend developers
Use whatever frontend you fancy

Blockers

The backend API is not ready yet but you want to crack on with the UI bits
You can get a small dump of existing user data as a JSON file

Solution: You want to mock the schema with minimal potential changes to your UI code in the future. graphql-sample can help solve that problem. graphql-sample is a GraphQL sample data server that can generate mock data for a given schema and a simple CRUD API with zero code.

We shall use graphql-sample to aid us in prototyping the API before backend API is ready.

Here is the agreed entity relationship as agreed in the tech sessions with the stake holders

Lets create a folder called trello

mkdir trello
cd trello

and create a file called schema.graphql in the trello folder

touch schema.graphql

Let’s load the users information first. graphql-sample auto loads any CSV and JSON files in the same directory and can then be referenced from the schema.

Let's copy the users.json file into the trello folder. A sample user looks like

{
    "UserId": 1,
    "FirstName": "Luís",
    "LastName": "Gonçalves",
    "Email": "luisg@embraer.com.br"
}

and we can easily map that to our GraphQL schema like this

type Member @datasource(name: "users") {
  userid: Int @unique @named(as: "UserId")
  name: String @named(as: "FirstName")
  email: String @named(as: "Email")
}

Let’s test our new schema by Firing up graphql-sample in the trello folder. This will start a server on localhost on port 8080

npx graphql-sample

now visit http://localhost:8080/graphql to see the playground or you can use http://localhost:8080/graphql in your application code to make direct POST requests.

Now we can run an initial query to fetch some users


query sampleMembers {
findMembers(limit: 2) {
   name
   email
 }
}

and we should see some user data already coming through

Now onto modelling our Board and attaching it to our members


type Member @datasource(name: "users") {
  userid: Int @unique @named(as: "UserId")
  name: String @named(as: "FirstName")
  email: String @named(as: "Email")

  # create a relationship between a member and their boards
  boards: [Board] @relation
}

type Board {
  id: ID
  name: String @named(as: "lorem_word")

  # create a relationship between a board and it's owner
  owner: Member @relation
}

Now we can query boards and see it's owner

query someBoards {
 findBoards(limit: 3) {
    name
    owner {
      name
    }
  }
}

or query a member and retrieve the boards they have created

query myBoards {
  findMembers(where: {email:{eq:"luisg@embraer.com.br"}}) {
    boards {
      name
    }
  } 
}

Now lets create some board memberships. Since boards can have members who are not owners

type Member @datasource(name: "users") {
  userid: Int @unique @named(as: "UserId")
  name: String @named(as: "FirstName")
  email: String @named(as: "Email")

  boards: [Board] @relation
  memberships: [BoardMembership] @relation
}

type Board {
  id: ID
  name: String @named(as: "lorem_word")
  owner: Member @relation
  members: [BoardMembership] @relation
}

type BoardMembership {
  id: ID
  board: Board @relation
  member: Member @relation
  created_at: String @named(as: "date_recent")
}

Now we can query board memberships

query myBoards {
  findMembers(where: { email:{ eq: "luisg@embraer.com.br" }}) 
 {
    boards {
      name
    }

    memberships {
      board {
        name
      }
    }
  } 
}

and we can continue to build up the API as we build UI.

see the full schema here

graphql-sample generates a full CRUD API, so you can create new boards like this

mutation {
  createBoards(data: [
    {
      id: 1020,
      name: "Sample Board",
      limitations: [
        {
          id: 2,
          type:board
          status: warn
          disableAt: 233
          warnAt: 400
        }
      ]
    }
  ]) {
    boards {
      name
      limitations {
        status
      }
    }
  }
}

Wonderful, now as a frontend developer, you can now carry on developing your UI before the backend APIs are ready.A simple modification might be required to the schema/operations before you go into production but that should be minor.

Hope this was a useful exercise.

[Disclaimer] I am the author of graphql-sample

NodeJS or GoLang for backend API

Raymond Ottun — Wed, 01 Jul 2020 17:57:05 +0000

When starting a new project as a polygot developer, why would you choose NodeJS over Golang or vice-versa for your backend/API dev? I have been struggling with this question for a while now especially when the difference is speed is much of a concern when choosing a language.