DEV Community: Frangeris Peguero

Stale cache, the holy grail of performance

Frangeris Peguero — Tue, 29 Oct 2024 21:09:13 +0000

Cache on APIs is a must-have feature for any service that aims to scale. It's a way to reduce the load on your servers and improve the response time for your users by serving the same content multiple times, getting the same result without having to process the request again.

The issue is that... implementing cache systems is hard, tricky and can cause a lot of headaches when it comes to invalidating the cache, purging and keeping the cache fresh with the latest data.

In this article we will explore the concept of stale cache, test different scenarios with examples and see how CDN providers like Bunny CDN can help us to keep the cache fresh without having to purge it with every new request.

Let's start by breaking down the pieces.

⌛️ Response time

When you make a request to an API, the response time is what it takes for the server to process the request and send a response back.

This time period can typically vary depending on multiple factors from its composition like the server's load, the network latency and the complexity of the request:

Network latency: the time it takes for the request to travel from the client to the server.
DNS lookup time: what it takes for the client to resolve the server's domain name to an IP address.
Connections and SSL Handshakes: a set of ticks and checks that the server needs to do before sending the response.

And when the requests finally arrive, then in the server side we have:

Processing time: what it takes for the server to process the request and send back the response.
Response size: this affects the time it takes to transfer the data over the network.

As the processing time in the server is something we can control by optimizing the code, the other factors are out of our control. Despite that we can reduce the time it takes to process the request by using a cache system.

There are others factors like "cold-start" time on serverless implementations that also increase the time it takes to process the request, but this is out of the scope of this article.

Now, how the cache system works?

A client requests information to a server, the server processes the request and sends back the response body, http status code and headers. Two of these headers are key to understand how the cache system works:

Cache-Control: Dictates the mechanism to control for whom, how and until when the response can be cached.
ETag: Is a unique identifier for the response state.

Currently, the HTTP/2 RFC Specification defines how the Cache-Control header should work telling the client (or intermediary caches like CDNs) how to behave. It also inherits the same directives from the HTTP/1.1 specification with some extra improvements.

In the other hand, the ETag is used like an index key: if the value hasn't change, the cache can be used; if not, a new fresh response is needed. It solves the problem of seeing if the data has changed or not, but it can't solve the problem of keeping the cache fresh with the latest data. This is where the concept of stale cache comes in.

Stale cache

By working with this concept the cache is served by an intermediary to the client even if it's expired while the server is still processing the request in the background to get the latest data. When the server gets the latest data, it updates the cache with the new data and serves it fresh to the client on the next request.

The Cache-Control header can be extended with the functionality described above. This is done via the directive stale-while-revalidate that tells the client (or intermediary) to serve the stale cache while revalidate in the background.

The directive can receive a value in seconds. This value is the time during the stale cache can be served while the server is processing the request to get the latest data; for instance, a header with this directive can look like this:

Cache-Control: max-age=604800, stale-while-revalidate=86400

Which translates to: "serve the cache for 7 days, but if the cache is expired then serve the stale cache for 1 day while the server is processing the request to get the latest data".

This level of customization is then used by CDNs to keep the cache fresh without having to purge it every time a new request is made. It basically always returns the cache but, when a new version is available, it updates the cache and serves that new version to any new request. Simply like magic.

🔒 `private` / `public` directives

The Cache-Control header can also support "some kind" of privacy level. The difference between having those values is that the public value will be interpreted as if they were allowed to store the response in a shared cache, while the private one is intended to be stored only in the client's (local caches or browsers).

Basically the public directive is used when the response is the same for all users, while the private directive is used when the response doesn't need to be saved as cache by a CDN.

Having understood the concept of stale cache, let's see how we can implement this on a real-world scenario.

⚡️ Some testings

Let's test this concept with a simple API that returns a random number that will be deployed on us-east-2 zone on AWS API Gateway.

Making a GET request to the endpoint /random will return a random number between 1 and 100 due to the cold-start time of serverless functions. The first request will take a little longer to respond, but the next requests will be faster.

This example shows some of the factors explained at the beginning of the article, subsequent requests can take between 200ms and 450ms of response time depending of the lambda invoke response, even with some of tracing being cached like DNS Lookup, TCP Handshake, SSL Handshake, this is pretty normal as the origin of the request is from South America and edge locations are not configured.

So, how can we improve this response time? Let's add a cache system to the API.

Let's introduce bunny.net 🐇

Bunny is a global content delivery platform that help us to delivers cached content faster. In this example, we will use Bunny to cache the responses of the API, see how the cache system works and how the stale cache can be implemented. They have a lot of features and capabilities, but for this example we will focus on CDN.

With an account already created, we can create a new "pull zone". This is the layer that sits in front of the API and act as intermediary caching everything being requested. Given the name xxxxxxx.b-cdn.net a domain will be created and we also need to add the "Origin URL" that is the api endpoint we want to cache.

While creating the pull zone, they provide the options to check "in what zones" we want to store the cached data, so the content is served from the closest region instead of traveling all the way to the origin. We will select all the zones available so the cache is everywhere 🤯.

With the pull zone created, is ready to be used as proxy for the API. Now let's move back the the endpoint code to make the header customization so bunny know what to do with our origin responses.

We can start making requests to the new domain pull zone domain, so anything requested to the CDN will be forwarded behind scenes to API but caching the response.

// instead of
GET https://api.example.com/random

// use the pull zone domain
GET https://mynewpullzone.b-cdn.net/random

By default our cache control header is set to no-cache, so every time we hit the pull zone URL provided it will make a request to the origin, so lets change that behavior by just adding max-age directive to the header.

"Cache-Control": `public, max-age=86400`,

This will tell the CDN to cache the response for 1 day, so the next requests will be served from the cache instead of making a request to the origin. And by enabling the previous regions zones, the request will be served from the closest edge location to the client getting a lightning fast response.

🔥 18ms of response time, that's a huge improvement from the previous 200ms - 450ms, and this is just the beginning.

The CDN-Cache header returned in the request tell us if the request was served by the CDN cache or not, in case the value is MISS, the request was made to the origin, if the value is HIT, the request was served from the cache.

There are other features that can be implemented. Bunny provide features like "Query String Sorting" that, when enabled the query parameters will be automatically sorted into a consistent order before checking the cache. For example, this will treat /random?width=200&height=100 and /random?height=100&width=200 as the same path.

But, there is still something missing. With this implementation the cached response will need to be updated when the expiration time is reached so the stale cache can be used, but even after the revalidate time is expired the CDN will hit a request to the origin to update the cache. This is not the best approach, so let's see how we can improve this.

Bunny supports an option that can be enabled from the dash panel inside the pull zone cache options: the "Stale Cache", which basically "allows you to temporarily serve stale files from the CDN cache, while updating resources in the background". We have two available options here:

While Origin Offline: Which will serve the stale cache while the origin is offline and down.
While Updating: The one we are interested in, this will serve the stale cache and behind scenes update the cache with the latest data, so we always get the fresh data blazing fast thanks to their edge locations.

Wrapping up

Implementing a cache system is crucial for improving the performance and scalability of your API services. By leveraging the concept of stale cache and using CDNs like Bunny.net, you can significantly reduce response times and server load. The Cache-Control header, with directives like stale-while-revalidate, allows you to serve stale content while fetching fresh data in the background, ensuring that your users always get the best possible experience. Remember, while Bunny.net is used in this example, these caching principles can be applied with any CDN provider that supports similar capabilities.

Happy caching! 🍻

Upgradeable smart contracts

Frangeris Peguero — Mon, 31 Jul 2023 15:09:19 +0000

The basis

This series assumes you have a basic understanding of the smart contracts development and the Ethereum or EVM compatible blockchains and that you also have a local development setup already working. If you are not familiar with these topics, please read the Introduction to smart contracts to start.

One of the most popular implementations of smart contracts today is the ERC20 token standard. It is a set of rules that defines how a token contract should behave. It is a standard that allows different applications to interact with the token knowing how it works. For example, a wallet application can display the balance of a token, or a decentralized exchange can trade it. The standard creates and endless possibilities of functionalities that can be built on top of it.

We are going to focus in creating a payments gateway by using the ERC20 standard as the basis for our tokens. This will allow us to share the implementation with other applications that support the standard interface as the popular stable coins: USDC, USDT, DAI.

"The immutable problem"

The pure concept of smart contracts is that they are immutable. Once a contract is deployed, it cannot be changed. This is a great feature because it allows us to trust the code that is running in the blockchain. We can be sure that the code will not change and that it will behave as expected. This means that if we want to add new features or fix something broken inside the contracts, we need to deploy a new contract and migrate the state to the new one; this is not a problem for a new contract, but it is a big problem for an existing one with a lot of users interacting with it.

That's why the concept of "upgradeable contracts" was created. The idea is to have a contract that can be upgraded without losing the state. This is a very complex topic and there are many different approaches to it. We are going to use the OpenZeppelin Upgrades library to create our upgradeable contracts.

How the proxy pattern works?

The secret behinds a proxy consists in a contract that provides a fallback function that delegates all calls to another contract using the EVM instruction delegatecall, which is a low-level function that allows calling another contract using the current contract storage and context. This means that the contract being called can access the storage of the contract that is calling it. This is the key to the proxy pattern.

Here is an example of how delegatecall works:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.17;

// NOTE: Deploy this contract first
contract B {
    // NOTE: storage layout must be the same as contract A
    uint public num;
    address public sender;
    uint public value;

    function setVars(uint _num) public payable {
        num = _num;
        sender = msg.sender;
        value = msg.value;
    }
}

contract A {
    uint public num;
    address public sender;
    uint public value;

    function setVars(address _contract, uint _num) public payable {
        // A's storage is update, B state is not modified.
        (bool success, bytes memory data) = _contract.delegatecall(
            abi.encodeWithSignature("setVars(uint256)", _num)
        );
    }
}

In short words, the proxy contract is the one that DApps interact with while using the logic of other contract in the proxy context. This means that the proxy contract will be the one that is deployed and the one that users will interact with, while the logic contract will be the one that is upgraded.

More technical documentation can be found on the Solidity docs.

When working with upgradeable contracts using OpenZeppelin Upgrades, there are a few minor caveats to keep in mind when writing your Solidity code.

It’s worth mentioning that these restrictions have their roots in how the Ethereum VM works, and apply to all projects that work with upgradeable contracts, not just OpenZeppelin Upgrades.

Some of the caveats of using the proxy pattern are:

Initializers: Contructors are not allowed in upgradeable contracts and we need to use the initialize function from the Initializable contract instead. This function is called only once when the contract is deployed for the first time. This means that we need to use the initializer modifier inside the initialize function.
Extending from upgradeable contracts libraries: Following the same logic, we need to use the initializer modifier when extending from upgradeable contract libraries.
Initial values and fields declarations: We need to be careful when declaring fields in our contracts, because the initial values are not set when the contract is deployed. This means that we need to set the initial values in the initialize function.
Initialization of implemented contracts: As constructors are disabled when working with upgradeability, while extending from a contract, we call the function that "initialize" instead of calling the parent via super.
Not selfdestruct or delegatecall implemented: These functions are not supported in upgradeable contracts to avoid breaking the proxy pattern or opening a door to security issues.

More detailed information can be found in the OpenZeppelin Upgrades documentation.

The implementation

To give the ability of upgradeability to our "Gateway" (in case something goes wrong or needs to be changed), we need to use the proxy pattern. So let's start by creating and deploying a Gateway.sol contract:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.18;

import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";

contract Gateway is Initializable, OwnableUpgradeable {
  uint private fee;

  function initialize(uint _fee) public initializer {
    fee = _fee;
    __Ownable_init();
  }

  function getFee() public view returns (uint) {
    return fee;
  }
}

This contract is very simple, it has a fee variable that can be set by the owner of the contract. This is the contract that we are going to be upgrading.

To deploy it we need to use the deployProxy function from the @openzeppelin/hardhat-upgrades plugin. This function will deploy the proxy contract and initialize it with the initialize function from the Gateway contract.

To keep things simple and visible (in case you cant deploy), we will use Sepolia testnet blockchain and Hardhat as development environment, so to configure hardhat to use sepolia we need to add the following configuration to the hardhat.config.js file:

  networks: {
    sepolia: {
      url: 'https://rpc.sepolia.org/',

      // private key of the account that will deploy the contracts (owner)
      accounts: [process.env.ACCOUNT_PRIVATE_KEY!],
    },
  },

Then we can tell Hardhat to run the deployment script while specifying the network to use:

npx hardhat run scripts/deploy.js --network sepolia

You should be able to see the same transaction on Sepolia Block Explorer. Now let's take a look at the transactions details (lookup your wallet address in etherscan), 3 contracts were created:

TransparentUpgradeableProxy: This is the proxy contract that will be used to interact with the Gateway contract, see it here.
ProxyAdmin: This contract is used to manage the proxy contracts (admin / upgrades), see it here.
Gateway: This is the logic contract that will be used by TransparentUpgradeableProxy, see it here.

Note that Gateway contract code is not available as the others: only the bytecode is shown. This is because it was deployed by the proxy; to be able to see the real code you can verify and publish it via hardhat.

Any future interaction with the Gateway contract will be done via the TransparentUpgradeableProxy contract, so let's try to interact with it. To do so, let's use hardhat console to interact with the blockchain:

npx hardhat console --network sepolia

Why specify the network? Because we need to tell Hardhat which network to use to interact with the blockchain. In this case we are using the sepolia network and we will also use ethersjs to interact with the deployed contract.

frang @ ~/Code/posts-examples/payments-gateway (master)
 →  npx hardhat console --network sepolia
Welcome to Node.js v14.18.1.
Type ".help" for more information.
> const proxy = await ethers.getContractFactory("Gateway")
undefined
> const gateway = await proxy.attach("0xe7197e1D5F60eE3745a828a4CeaDAA0FBfFF886D")
undefined
> (await gateway.getFee()).toString()
'1'
>

As you can see, we are able to interact with the Gateway contract via the TransparentUpgradeableProxy contract, but what if we want to upgrade the Gateway contract? Let's add support to allow the owner to change the fee by creating GatewayV2.sol:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.18;

import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";

contract GatewayV2 is Initializable, OwnableUpgradeable {
    uint private fee;

    function initialize(uint _fee) public initializer {
        fee = _fee;
        __Ownable_init();
    }

    function getFee() public view returns (uint) {
        return fee;
    }

    function setFee(uint _fee) public onlyOwner {
        fee = _fee;
    }
}

The new contract should be exactly the same as the previous one, but with the addition of the setFee function, now let's deploy it:

The difference between upgrade script and the previous one is that we are using the upgradeProxy function instead of deployProxy, this function will upgrade the Gateway contract to the new GatewayV2 contract.

frang @ ~/Code/posts-examples/payments-gateway (master)
 →  PROXY_ADDRESS=0xe7197e1D5F60eE3745a828a4CeaDAA0FBfFF886D npx hardhat run scripts/upgrade.js --network sepolia
Upgrading...
Upgraded: 0xe7197e1D5F60eE3745a828a4CeaDAA0FBfFF886D

The contract was upgraded, but how can we verify that? Let's try to interact with the contract again BUT this time we will use the GatewayV2 contract instead of the Gateway contract while using the same contract address:

frang @ ~/Code/posts-examples/payments-gateway (master)
 →  npx hardhat console --network sepolia
Welcome to Node.js v14.18.1.
Type ".help" for more information.
> const proxy = await ethers.getContractFactory("GatewayV2")
undefined
> const gateway = await proxy.attach("0xe7197e1D5F60eE3745a828a4CeaDAA0FBfFF886D")
undefined
> (await gateway.getFee()).toString()
'1'
> await gateway.setFee([2])
{
  hash: '0x699ad32e17ca56537d69c60ff4727526f031f53ca46775dad535d37300055cda',
  ...
}
> (await gateway.getFee()).toString()
'2'

The contract now has the setFee function, so we can change the fee, but how can we truly verify that the contract was upgraded? Every transaction is written in the blockchain, taking a look at the transaction details on Sepolia Block Explorer, you should be able to see the Upgraded event. This event is emitted when the Gateway contract was upgraded to the GatewayV2 contract.

And that's it, we have the first contract for the payments gateway that can be upgraded, but what if we want to add more features to the contract? We can do that by creating a new contract that have the same interface as previous contracts, then just add the new features, deploy it and upgrade the proxy contract to the new contract; this way we can add new features without breaking the existing ones.
With the upgradeable part covered, let's move to the next part.

Ensuring secure values by private keys in AWS (KMS, SSM, Secrets Manager)

Frangeris Peguero — Wed, 19 Apr 2023 15:10:26 +0000

Ensuring secure values by private keys in AWS (KMS, SSM, Secrets Manager)

Private keys, access credentials, and sensitive information such as passwords or any kind of confidential data are essential in application's logic when interacting with other services or even databases. Storing those values can be risky if proper security measures are not in place.

In this post we will dig into one way to accomplish secure access to sensitive information in AWS environments. For simplicity we will be using:

A ready to use AWS account.
Serverless Framework - to delegate the CloudFormation creation and deployment.

This implementation focuses on the use of specifics services and functionalities provided by AWS services. Implementations will vary depending on the provider (Azure, GCP).

Let's start by creating a basic AWS Lambda

This function will try to access our "secure" and use it. By using npx command we get access to serverless executable. I recommend you select the basic settings to keep it simple, but don't forget there are options for different types of uses cases, even different languages options in case Node.js is not your language.

Some operations used on the lambda function will require some permissions later. Due to this, it's recommended to include and enable those permissions before the IAM role of the lambda gets created. Here are the permissions we need the lambda to have:



provider:
  # ...
  iam:
    role:
      statements:
        - Effect: Allow
          Action:
            - "s3:*"
          Resource: "*"
        - Effect: Allow
          Action:
            - "cloudwatch:*"
            - "logs:*"
          Resource: "*"
        - Effect: Allow
          Action:
            - "ssm:GetParameter"
            - "ssm:GetParametersByPath"
          Resource: "*"
        - Effect: Allow
          Action:
            - "secretsmanager:GetSecretValue"
          Resource: "*"
        - Effect: Allow
          Action:
            - "kms:Decrypt"
          Resource: "*"

Then, with your aws account already set up, let's deploy it.



npx sls deploy

🎉 After a correct deployment, the code should have been created successfully and be ready to use. Now we need to configure the most important part: security.

Security

Permissions will be managed via IAM policies with the objective of only allow the lambda to get and decrypt the secured value. Plus, the approach used will be based on: prevent IAM entities from accessing the KMS key and allow the root user account to manage it (also preventing the root user account from losing access to the KMS key).

This "protection" layer of our sensitive value is based on the composition of two AWS services: Key Management Service is the one responsible for creating the private key which will be used to encrypt our value, then Secret Manager or System Manager: Parameters Store allow us to accomplish the same functionality but they differ on some caveats, since the chosen one will be used for saving the secured encrypted value. Here is a quick graphic representation of the implementation:

Now lets translate these concepts into code. The first thing we need after having the lambda functional and usable is to create the key used to encrypt our precious value...

So lets create the key using the "root" account and give it access to lambda just for "kms:Decrypt", not other operations!

Please notice how we control and specify that only a specific ARN can call this value by: kms:CallerArn: !Sub arn:aws:lambda:region:${AWS::AccountId}:function:myfunction



resources:
    MyPrivateKey:
      Type: AWS::KMS::Key
      Properties:
        Description: "My KMS private key"
        KeyUsage: ENCRYPT_DECRYPT
        KeyPolicy:
          Version: "2012-10-17"
          Id: "my-key-1"
          Statement:
            - Sid: "Enable root user permissions"
              Effect: "Allow"
              Principal:
                AWS: !Sub arn:aws:iam::${AWS::AccountId}:root
              Action: "kms:*"
              Resource: "*"
            - Sid: "Allow use of the key"
              Effect: "Allow"
              Principal:
                Service: lambda.amazonaws.com
              Action:
                - "kms:Decrypt"
              Resource: !Sub arn:aws:kms:region:${AWS::AccountId}:key/my-key-1
              Condition:
                StringEquals:
                  kms:CallerArn: !Sub arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:myfunction
    MyPrivateKeyAlias:
      Type: "AWS::KMS::Alias"
      Properties:
        AliasName: alias/myprivatekey
        TargetKeyId: !Ref MyPrivateKey
  Outputs:
    # we will need this value later
    MyKeyId:
      Value: !Ref MyPrivateKey
      Description: The ID of the KMS key used to encrypt

In this stage you should be able to have the lambda function and a secret key which both the root user and the lambda ARN can access and use it. Now, how about creating our encrypted values?

For simplicity I personally prefer AWS CLI to handle the process of encrypting and saving instead of creating another lambda script that would need to use AWS SDK, ending in the same result 🤷🏽

So first, we need to encrypt our secret using the previous key already created, so that even if someone is able to access the value, they will need our key to be able to see the content,

Some of the values used below are not exposed in the serverless deploy output, so those values are gotten via the stack output previously defined as part of serverless.yml:



npx sls info --verbose

--plaintext (data to be encrypted) is required to be base64 text or a blob from a plain text file



aws kms encrypt \
    --region <same region used by serverless> \
    --key-id <key id from output (MyPrivateKeyId)> \
    --plaintext "<base64 of value> or <fileb://path>" \
    --output text \
    --query CiphertextBlob

🎉 You should be able to get a base64 output from the command above with the encrypted value, now what next?

Store the values

We need to save those values inside a secure service, either a AWS System Manager (using Parameter Store) or a AWS Secret Manager creating directly a key/value. Why not try both?

For Parameter Store

For reusability use the previous encrypted output directly with the same command, getting as result:



aws ssm put-parameter \
  --name "my-parameter-name" \
  --type "SecureString" \
  --value "$(aws kms encrypt --region us-east-1 --key-id <key id> --plaintext "<value>" --output text --query CiphertextBlob | base64 --decode)" \
  --region us-east-1

If everything works, you should receive a json payload like this, which means it works, and that the value was created successfully 👏🏽

Access via AWS Systems Manager -> Parameter Store to see it.



{
  "Version": 1,
  "Tier": "Standard"
}

For Secrets Manager

Secret manager use the same approach as Parameter store, but with a different command, let's see:



aws secretsmanager create-secret --name "my-secret" --secret-string "my-secret-value"

Running this will create a new secret in AWS Secrets Manager with the name my-secret and a secret value of my-secret-value. If the command is successful, it will return a JSON object containing metadata about the newly created secret, including its Amazon Resource Name (ARN).
Let's encrypt and send it to secretsmanager as follow:



aws secretsmanager create-secret --name "my-secret" --secret-string "$(aws kms encrypt --region <region> --key-id alias/myprivatekey --plaintext "<value>" --output text --query CiphertextBlob)"  --region <region>

🥳 Getting the following payload means it works:



{
  "ARN": "arn:aws:secretsmanager:us-east-1:<account id>:secret:my-secret-j3MXy5",
  "Name": "my-secret",
  "VersionId": "<version id>"
}

Access via AWS Secrets Manager -> Secrets to see it.

Now with both scenarios covered, let's move on and try to access those values from code. Going back to the lambda function, we need to update the code to get and use the value as follow but before let's make sure we can retrieve and decrypt both saved values:

Check that you are able to decrypt the values, use the command below:



# Using system manager (parameter store)
aws kms decrypt \
    --ciphertext-blob fileb://<(aws ssm get-parameter --region <region> --name "my-parameter-name" --with-decryption --query Parameter.Value --output text | base64 --decode) \
    --key-id alias/myprivatekey \
    --output text \
    --query Plaintext | base64 --decode

# For secrets manager
aws kms decrypt \
    --ciphertext-blob fileb://<(aws secretsmanager get-secret-value --region <region> --secret-id "my-secret" --query SecretString --output text | base64 --decode) \
    --key-id alias/myprivatekey \
    --output text \
    --query Plaintext | base64 --decode

✨ You should be able to get you real value, in our case was my precious value (base64 encoded at start). Here is what the test code implementation could look like:

This should be the output from logs:



START RequestId: xxxxxxx Version: $LATEST
2023-04-15T21:51:48.684Z xxxxxxx INFO from parameters store: my precious value
2023-04-15T21:51:48.684Z xxxxxxx INFO from secrets manager: my precious value
END RequestId: xxxxxxx
REPORT RequestId: xxxxxxx Duration: 255.71 ms Billed Duration: 256 ms Memory Size: 1024 MB Max Memory Used: 97 MB Init Duration: 699.66 ms

All the code is available here if you want to test it.

Hope it helps, cheers 🍻

Reverse proxy cache using AWS CloudFront

Frangeris Peguero — Mon, 28 Nov 2022 16:00:43 +0000

How to implement a reverse proxy cache to any API using AWS CloudFront

A reverse proxy is the application that sits in front of back-end applications and forwards client (e.g. browser) requests to those applications. Reverse proxies help increase scalability, performance, resilience and security. The resources returned to the client appear as if they originated from the web server itself.

AWS CloudFront is a CDN service for high performance and security convenience that offers a lot of advantages including a global edge network with a low latency and high throughput network connectivity (the one that matter to us).

One typical example where we could be needing a reverse proxy cache mechanism is when building HTTP APIs (API Gateway v2) on AWS, this type of APIs are designed with minimal features so that they can be offered at lower price, lacking options as edge optimization, support for api keys, throttling and cache, more detailed comparison here; not having support for cache means processing time load will increase on backend side on origin servers, resulting in high latency on every request.

As it turns out, CloudFront solves this problem nicely.

For simplicity we will be using Serverless Framework v3 to handle AWS stack creation.

Start by creating a HTTP API (API Gateway v2)

A very basic serverless api deployment should be working and usable to be able to configure CloudFormation distribution on top of it.

If you don't have previous experience with serverless, follow this link on how to do it, just remember to select "HTTP API" as is the one that doesn't have cache support already built in.

Let's start by defining the type of api we need and some basic function to be able to exemplify:

# serverless.yml

provider:
  name: aws
  # ...
  httpApi:
    name: "myapi"
    cors: true

functions:
  hello:
    handler: src/handler.hello
    events:
      - httpApi:
          path: /
          method: get

Regarding to what data we will be returning, lets run a process that sleep for 5 seconds to simulate some background process that "take too long" to complete using the Timers API, something like this:

🎉 After a correct deployment, the api should be created successfully and ready to use.

Now that the API is live and usable, we can make request by just calling the endpoint provided:

curl --location --request GET 'https://644z4ooroe.execute-api.us-east-1.amazonaws.com/'

This will return the response we explicitly send back in our lambda, BUT, after 5 seconds:

If you notice the time taken to complete the request 5.21s is the time we setup to sleep, this time is also influenced by the spin up (known as freeze time) of lambdas, consecutive requests will decrease the time needed by the script to return data but only by a few ms.

So what happens if we cache this response not to wait those 5s of processing time?

Let's configure CloudFront as a reverse proxy

The process consists in creating a distribution using the API domain as origin, enabling the built-in cache inside the distribution and controlling the caching time by TTL.

Following the Amazon CloudFront resource type reference we will create the distribution directly from serverless template and connect it to the previous created API as our origin.

We need to create two resources to be able to create the distribution:

AWS::CloudFront::CachePolicy
AWS::CloudFront::Distribution

Inside the serverless.yml file (at the end), let's create a new section: resources where we can add resources that will be created for us inside AWS by the sls deploy command, those resources are:

resources:
  Resources:
    # https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-cachepolicy.html
    mycachepolicy:
      Type: AWS::CloudFront::CachePolicy
      Properties:
        CachePolicyConfig:
          Name: mycachepolicy
          # We can custom or TTL values below
          DefaultTTL: 86400
          MaxTTL: 86400
          MinTTL: 1
          ParametersInCacheKeyAndForwardedToOrigin:
            EnableAcceptEncodingGzip: true
            EnableAcceptEncodingBrotli: true
            CookiesConfig:
              CookieBehavior: none
            HeadersConfig:
              HeaderBehavior: none
            QueryStringsConfig:
              QueryStringBehavior: none

    # https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-distribution.html
    mydistribution:
      Type: AWS::CloudFront::Distribution
      Properties:
        DistributionConfig:
          Enabled: true
          Origins:
            # auto generated by serverless, also removed "http:" as is not allowed in domain name, is going to use the default API URL generated by AWS, if you have a custom api url, just replace it here
            - DomainName:
                !Select [1, !Split ["//", !GetAtt HttpApi.ApiEndpoint]]
              # this value should be moved to a custom global var instead of duplicating the same string below
              Id: mydistributiondomainid
              CustomOriginConfig:
                OriginProtocolPolicy: https-only
          DefaultCacheBehavior:
            CachePolicyId: !Ref mycachepolicy
            DefaultTTL: 300
            TargetOriginId: mydistributiondomainid
            ViewerProtocolPolicy: https-only
            # List of allowed method acceded by cache, only GET for our case
            AllowedMethods:
              - GET
              - HEAD
          # all means all edge locations (recommended)
          PriceClass: PriceClass_All

Dont forget to run the re-deploy to update the AWS stack with the new config, if everything works, we should be able to make request to the cloudfront URL and it will cache the responses from the origin.

⚡️ Here is the final requests, the first is to our origin, the second to cloudfront cache.

🤯 As we can see, the response time is absurd in comparison just by enabling a cache.

Remember the very first request (miss cloudfront) will have the same load time as the origin due to will populate the first time the cache.

All the code is available here if you want to test it.

Hope it helps, cheers 🍻

Reusable dynamic modal on Vue 3

Frangeris Peguero — Wed, 26 Oct 2022 17:37:02 +0000

Reusable dynamic modal on Vue 3

Most of the time on frontend development the best way to keep a consistent way of building components is trying to make them reusable every time we can, but sometimes the framework itself can make it a bit hard if we don’t have deep knowledge of its internal API, specifically the way it handles view instance and state component data.

What makes a good reusable modal?

✅ Dynamic views
✅ Customizable actions with callbacks (buttons)
✅ easy-peasy instantiation

For simplicity we will be using:

DaisyUI as component library (modal)
Pinia as state management vue store
Vue 3 with the composition API with typescript

Let’s start by defining a very basic modal template using daisy classes:



<!-- @/components/x-modal.vue -->

<template>
  <div>
    <div class="modal modal-open">
      <div class="modal-box relative">
        <label class="btn btn-sm btn-circle absolute right-2 top-2">✕</label>
        <h1>Hey, it works 👏🏽</h1>
      </div>
    </div>
  </div>
</template>

To be able to access it from anywhere and render any type of view, the modal needs to be accessible from any component that wants to use it, for this reason the modal component needs to be placed on the root parent view where all the views will be rendered, assuming Vue router is being used:



<template>
  <x-modal />
  <router-view />
</template>

<script lang="ts" setup>
  import XModal from "@/components/x-modal.vue";
</script>

👏🏽 You should be able to see our beautiful modal rendered!

Setup the store (state management)

As it's a reusable global modal, we need to keep global track if this modal is opened or closed and also have the ability to control it from any other component, maintaining a unique instance. This is where Pinia comes in.

Lets define a new store specifically to interact with the modal:



// @/store/modal.ts

import { markRaw } from "vue";
import { defineStore } from "pinia";

export type Modal = {
  isOpen: boolean,
  view: object,
  actions?: ModalAction[],
};

export type ModalAction = {
  label: string,
  callback: (props?: any) => void,
};

export const useModal = defineStore("modal", {
  state: (): Modal => ({
    isOpen: false,
    view: {},
    actions: [],
  }),
  actions: {
    open(view: object, actions?: ModalAction[]) {
      this.isOpen = true;
      this.actions = actions;
      // using markRaw to avoid over performance as reactive is not required
      this.view = markRaw(view);
    },
    close() {
      this.isOpen = false;
      this.view = {};
      this.actions = [];
    },
  },
});

export default useModal;

Now we have the store, lets connect it to our modal template so we can use its reactive references:



<template>
  <div>
    <!-- isOpen is reactive and taken from the store, define if it is rendered or not -->
    <div v-if="isOpen" class="modal modal-open">
      <div class="modal-box relative">
        <!-- @click handles the event to close the modal calling the action directly in store -->
        <label
          class="btn btn-sm btn-circle absolute right-2 top-2"
          @click="modal.close()"
          >✕</label
        >

        <!-- dynamic components, using model to share values payload -->
        <component :is="view" v-model="model"></component>

        <div class="modal-action">
          <!-- render all actions and pass the model payload as parameter -->
          <button
            v-for="action in actions"
            class="btn"
            @click="action.callback(model)"
          >
            {{ action.label }}
          </button>
        </div>
      </div>
    </div>
  </div>
</template>

<script lang="ts" setup>
  import { reactive } from "vue";
  import { storeToRefs } from "pinia";
  import { useModal } from "@/stores";

  const modal = useModal();

  // reactive container to save the payload returned by the mounted view
  const model = reactive({});

  // convert all state properties to reactive references to be used on view
  const { isOpen, view, actions } = storeToRefs(modal);
</script>

<component> is the way that vue handle dynamic components where :is receive the view that needs to be rendered, more info here.

It also support using the v-model directive to be able to share values dynamically, but how does this works?

Once we have the view mounted inside <component> we can make use of v-model to send and update reactive references emitting events from the view we are mounting. Internally from the view we want to render: emit a "update:modelValue" event that will update the reference passed via v-model back, eg:



<!-- MyViewToRender.vue -->
<script lang="ts" setup>
  import { watch } from "vue";

  // no need to import defineEmits
  const emit = defineEmits(["update:modelValue"]);

  // when someVar changes, it will update the reference passed via v-model
  watch(someVar, (value) => {
    emit("update:modelValue", value);
  });
</script>

Make use of the modal

To be able to control and populate data into the modal, we'll use the store defined as follow:



<template>
  <div>
    <button class="btn" @click="handleOnClickOpenModal">Open</button>
  </div>
</template>

<script lang="ts" setup>
  import useModal from "@/stores/modal";
  import MyViewToRender from "@/views/MyViewToRender.vue";

  const modal = useModal();
  function handleOnClickOpenModal() {
    modal.open(MyViewToRender, [
      {
        label: "Save",
        callback: (dataFromView) => {
          console.log(dataFromView);
          modal.close();
        },
      },
    ]);
  }
</script>

When a click event on the button occurs, it will call handleOnClickOpenModal which at the same time will call the open action from the store, which changes the isOpen variable from the state, and as the modal is observing this value it will render or not depending of the value as follow:

🎉 Hurra!!! you have made a reusable modal on top of composition API and pinia.

What if we want to pass a payload to our view?

Dependency injection is a programming technique / design pattern in which an object or function receives other objects or functions that it depends on.

Vue natively implements a mechanism to handle this pattern, this implementation is known as Provide / Inject, more info here. A parent component can serve as a dependency provider for all its descendants. Any component in the descendant tree, regardless of how deep it is, can inject dependencies provided by components up in its parent chain. The issue with this approach is that it only applies to direct descendants from parent (not parallel components) and as the modal view is not strictly a child of the component invoking it, it won't work as intended.

Another way is to add a field property to the state of the modal on pinia (payload) and pass any reactive references from there, and then receive that object from the view we render.

Hope it helps, cheers 🍻

DEV Community: Frangeris Peguero

Stale cache, the holy grail of performance

⌛️ Response time

Now, how the cache system works?

Stale cache

🔒 private / public directives

⚡️ Some testings

Let's introduce bunny.net 🐇

Wrapping up

Upgradeable smart contracts

The basis

"The immutable problem"

How the proxy pattern works?

The implementation

Ensuring secure values by private keys in AWS (KMS, SSM, Secrets Manager)

Ensuring secure values by private keys in AWS (KMS, SSM, Secrets Manager)

Let's start by creating a basic AWS Lambda

Security

Store the values

For Parameter Store

For Secrets Manager

Reverse proxy cache using AWS CloudFront

How to implement a reverse proxy cache to any API using AWS CloudFront

Start by creating a HTTP API (API Gateway v2)

Let's configure CloudFront as a reverse proxy

Reusable dynamic modal on Vue 3

Reusable dynamic modal on Vue 3

Setup the store (state management)

Make use of the modal

What if we want to pass a payload to our view?

🔒 `private` / `public` directives