DEV Community: manojlingala

[Boost]

manojlingala — Sun, 09 Mar 2025 10:36:56 +0000

Orchestrating Financial Transactions with AWS Step Functions

manojlingala for AWS Community Builders ・ Mar 9

Orchestrating Financial Transactions with AWS Step Functions

manojlingala — Sun, 09 Mar 2025 10:36:35 +0000

In today's fast-paced financial sector, automation and precise orchestration of transactions can significantly boost efficiency and reliability. AWS Step Functions provides a powerful solution for managing complex workflows by integrating multiple AWS services seamlessly. In this article, we'll explore a real-world financial scenario—loan application processing—and demonstrate how AWS Step Functions can orchestrate these processes efficiently using C#.

Scenario: Loan Application Processing

When a customer applies for a loan, various sequential steps must occur:

Application submission
Credit score verification
Risk assessment
Decision making
Notification

AWS Step Functions can orchestrate these steps with clear visualization and robust error handling.

Let's define our workflow:

Start

Verify Credit Score (AWS Lambda)
Perform Risk Assessment (AWS Lambda)
Decision Logic (AWS Lambda)
Notify Customer (AWS Lambda)

End

Implementing the Workflow with AWS Step Functions

Step 1: Define State Machine

{
  "StartAt": "VerifyCreditScore",
  "States": {
    "VerifyCreditScore": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:region:account-id:function:VerifyCreditScore",
      "Next": "RiskAssessment"
    },
    "RiskAssessment": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:region:account-id:function:RiskAssessment",
      "Next": "DecisionMaking"
    },
    "DecisionMaking": {
      "Type": "Choice",
      "Choices": [
        {
          "Variable": "$.riskLevel",
          "StringEquals": "Low",
          "Next": "ApproveLoan"
        },
        {
          "Variable": "$.riskLevel",
          "StringEquals": "High",
          "Next": "DeclineLoan"
        }
      ]
    },
    "ApproveLoan": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:region:account-id:function:NotifyApproval",
      "End": true
    },
    "DeclineLoan": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:region:account-id:function:NotifyDecline",
      "End": true
    }
  }
}

How Transitions Work Between Steps

Transitions between steps in AWS Step Functions occur through clearly defined "Next" parameters. Each state explicitly specifies the next state it should transition to upon completion:

Task States: Perform work using Lambda functions or other AWS services. Upon successful execution, they transition automatically to the next state defined by the "Next" parameter.

Choice States: Evaluate conditions to determine the next state. Choices are evaluated sequentially until a matching condition is found, then the workflow transitions to the corresponding state.

End States: If a state has "End": true, it signifies the termination of the workflow.

AWS Step Functions uses JSON paths to pass output data from one state as input to the next, enabling seamless data flow through the workflow.

C# Implementation (Lambda Functions)

1. Verify Credit Score

public class CreditCheck
{
    public async Task<CreditResponse> Handler(LoanRequest request)
    {
        // Simulate fetching credit score
        int creditScore = await GetCreditScoreAsync(request.CustomerId);
        return new CreditResponse { CreditScore = creditScore };
    }
}

2. Risk Assessment

public class RiskAssessment
{
    public RiskResponse Handler(CreditResponse creditResponse)
    {
        string riskLevel = creditResponse.CreditScore < 700 ? "Low" : "High";
        return new RiskResponse { RiskLevel = riskLevel };
    }
}

3. Notify Customer

Approval Notification

public class NotifyApproval
{
    public async Task Handler(LoanRequest request)
    {
        await EmailService.SendApprovalAsync(request.CustomerEmail);
    }
}

Decline Notification

public class NotifyDecline
{
    public async Task Handler(LoanRequest request)
    {
        await EmailService.SendDeclineAsync(request.CustomerEmail);
    }
}

Benefits

Visibility:
AWS Step Functions provides visual monitoring of each step, simplifying troubleshooting.

Reliability:
Automatic retries and error handling.

Scalability:
Easy integration with various AWS services.

Single Table Design in AWS DynamoDB

manojlingala — Sat, 27 Jul 2024 02:57:57 +0000

As a developer working with AWS DynamoDB, I recently learnt and implemented Single Table Design in my projects. Single Table Design is a powerful and efficient approach to data modeling that has transformed the way I structure and query data in DynamoDB.

In this article, I want to share my learning experience, demonstrate the concepts I've grasped, and showcase the benefits of Single Table Design through real-world examples.

Implementing Single Table Design

Let's explore how to implement Single Table Design using a real-world example of a blog application. We'll consider scenarios such as creating users, articles, comments, and likes.

Scenario 1: Creating a User
When creating a user, we store the user information in the table with the following structure:

{
  "pk": "USER#789",
  "sk": "PROFILE",
  "user_name": "John Doe",
  "email": "john.doe@example.com",
  "created_at": "2023-05-20"
}

The PK is set to USER#, uniquely identifying the user.
The SK is set to a constant value, such as PROFILE, to indicate that this item represents the user's profile information.

Scenario 2: Creating an Article
When a user creates an article, we store the article information in the table with the following structure:

{
  "pk": "USER#789",
  "sk": "ARTICLE#123",
  "title": "Introduction to Single Table Design",
  "content": "Single Table Design is a powerful technique in DynamoDB...",
  "created_at": "2023-05-20"
}

The PK is set to USER#, indicating the user who created the article.
The SK is set to ARTICLE#, uniquely identifying the article within the user's partition.

To query all articles created by a specific user, we can use the following query:

string userId = "789";
var request = new QueryRequest
{
    TableName = "BlogApplication",
    KeyConditionExpression = "pk = :user_id AND begins_with(sk, :article_prefix)",
    ExpressionAttributeValues = new Dictionary<string, AttributeValue>
    {
        {":user_id", new AttributeValue {S = $"USER#{userId}"}},
        {":article_prefix", new AttributeValue {S = "ARTICLE#"}}
    }
};

var response = await dynamoDbClient.QueryAsync(request);
var articles = response.Items;

Scenario 3: User Commenting on an Article
When a user comments on an article, we store the comment information in the table with the following structure:

{
  "pk": "USER#789",
  "sk": "INTERACTION#COMMENT#ARTICLE#123#456",
  "interaction_type": "COMMENT",
  "content": "Great article! Thanks for sharing.",
  "article_id": "ARTICLE#123",
  "created_at": "2023-05-21"
}

The PK is set to USER#, indicating the user who made the comment.
The SK is set to INTERACTION#COMMENT#ARTICLE##, uniquely identifying the comment within the user's partition and associating it with the article.

To query all comments made by a specific user, we can use the following query:

string userId = "789";
var request = new QueryRequest
{
    TableName = "BlogApplication",
    KeyConditionExpression = "pk = :user_id AND begins_with(sk, :comment_prefix)",
    ExpressionAttributeValues = new Dictionary<string, AttributeValue>
    {
        {":user_id", new AttributeValue {S = $"USER#{userId}"}},
        {":comment_prefix", new AttributeValue {S = "INTERACTION#COMMENT#"}}
    }
};

var response = await dynamoDbClient.QueryAsync(request);
var comments = response.Items;

Scenario 4: User Liking an Article
When a user likes an article, we store the like information in the table with the following structure:

{
  "pk": "USER#567",
  "sk": "INTERACTION#LIKE#ARTICLE#123",
  "interaction_type": "LIKE",
  "article_id": "ARTICLE#123",
  "created_at": "2023-05-20"
}

The PK is set to USER#, indicating the user who liked the article.
The SK is set to INTERACTION#LIKE#ARTICLE#, uniquely identifying the like within the user's partition and associating it with the article.

To query all articles liked by a specific user, we can use the following query:

string userId = "567";
var request = new QueryRequest
{
    TableName = "BlogApplication",
    KeyConditionExpression = "pk = :user_id AND begins_with(sk, :like_prefix)",
    ExpressionAttributeValues = new Dictionary<string, AttributeValue>
    {
        {":user_id", new AttributeValue {S = $"USER#{userId}"}},
        {":like_prefix", new AttributeValue {S = "INTERACTION#LIKE#"}}
    }
};

var response = await dynamoDbClient.QueryAsync(request);
var likedArticles = response.Items;

Simplified the Query Pattern through Mermaid visualization :

Cost Optimization

Single Table Design allows for cost optimization in DynamoDB by minimizing the need for expensive table scans and reducing the amount of data stored.

Efficient Querying:

By designing your PK and SK to support your querying patterns, you can retrieve related items using a single query. This eliminates the need for costly table scans and reduces the amount of throughput consumed.

Reduced Storage Costs:

Storing related entities in a single table can help reduce storage costs compared to storing them in separate tables. DynamoDB charges based on the amount of data stored, so minimizing data duplication across tables can lead to cost savings.

Throughput Optimization: With Single Table Design, you can leverage the PK and SK to distribute data evenly across partitions. This allows for efficient use of provisioned throughput and helps avoid hot partitions, which can lead to throttling and increased costs.

Conclusion :

Single Table Design is a powerful approach to data modeling in AWS DynamoDB. By storing related entities in a single table and leveraging the PK and SK for efficient querying, you can simplify your data management, improve performance, and optimize costs.

When implementing Single Table Design, consider your application's access patterns and design your PK and SK accordingly. Use a combination of PK and SK to uniquely identify items and support efficient querying based on your requirements.

By following the examples and scenarios discussed in this article, you can effectively implement Single Table Design in your DynamoDB applications and reap the benefits of simplified data management, efficient querying, and cost optimization.

Remember to carefully analyze your data access patterns and optimize your PK and SK design to ensure the best performance and cost-effectiveness for your specific use case.

Happy coding with DynamoDB and Single Table Design!

Understanding DynamoDB Write Capacity Units: PutItem vs UpdateItem

manojlingala — Sat, 02 Mar 2024 14:00:00 +0000

Introduction

DynamoDB is a fully managed NoSQL database service provided by Amazon Web Services (AWS). When using DynamoDB in provisioned capacity mode, you need to specify the required read and write capacity units when creating a table. Understanding how these capacity units work is key to designing cost-effective and high-performance DynamoDB applications.

In this article, we'll focus on write capacity units and how they relate to two critical write operations in DynamoDB - PutItem and UpdateItem. We'll look at how item size and data patterns affect capacity unit consumption, along with considerations around concurrency and network usage.

Write Capacity Units Overview

DynamoDB allocates throughput capacity in units of read and write capacity:

One write capacity unit allows one write per second for an item up to 1KB in size.
For items larger than 1KB, DynamoDB rounds up the size to the next 1KB increment. For example, writing a 2.5KB item will consume 3 write capacity units.
Write capacity is provisioned at the table level based on your expected peak needs.

PutItem vs UpdateItem

Now let's compare how PutItem and UpdateItem consume write capacity units:

PutItem:

Overwrites an entire item if it already exists, otherwise writes a new item.
Consumes capacity units based on the larger of the new item size or old item size (if overwritten).
Requires sending the full item data in the request.

UpdateItem:

Updates specific attributes of an existing item.
Consumes capacity units based on the larger of item size before and after the update.
Only modified attributes need to be sent in the request.

Example Scenario

Consider a Users table with attributes like UserID, Name, Email, Address. Each item is 1KB in size.

If we call PutItem to overwrite a user item, it will consume 1 write capacity unit since the item size is 1KB.

If we call UpdateItem to only change the Email attribute, it will still consume 1 write capacity unit because the larger item size before and after update is 1KB.

Key Differences

With UpdateItem, only changing data needs to be sent over the network compared to the full item with PutItem. This can improve efficiency and reduce costs.
PutItem risks overwriting other attributes updated concurrently by a different process, leading to lost updates. UpdateItem directly modifies specific attributes avoiding this issue.
UpdateItem provides atomic updates avoiding conflicts when incrementing/decrementing values or manipulating sets.

When to Use Each

Use PutItem when replacing the entire item, such as when data needs to be re-loaded periodically.
Use UpdateItem for targeted updates to specific attributes, especially if updates are frequent.
Combine both as needed - use PutItem less frequently to reload entire items, and use UpdateItem to modify portions of those items in between.

Concurrency Considerations

With increased concurrent access, the risk of lost updates or race conditions rises. Strategies to handle this:

Use conditional writes to fail an update if certain conditions are not met, implementing an optimistic locking approach.
Use DynamoDB Transactions to coordinate updates across multiple items atomically.
Structure items to isolate frequently updated attributes, minimizing item sizes being overwritten.
Implement business logic retries/backoff to handle update conflicts.

By understanding how PutItem and UpdateItem consume write capacity and addressing concurrent access patterns, you can optimize DynamoDB usage for efficiency, performance and cost-effectiveness.

Conclusion

DynamoDB write operations carry implications for throughput provisioning, network usage, data consistency, and application design. By considering how PutItem and UpdateItem differ in their consumption of write capacity units, you can choose the most appropriate operation for your data and access patterns.

Fast Reads Unleashed: Performance Analysis of AWS GraphQL, DynamoDB, and Redis Cache

manojlingala — Sat, 25 Mar 2023 08:27:30 +0000

In this article, we analyze read performance benchmark results for a selection of AWS services, such as GraphQL (with AppSync and Lambda), Redis Cache (using Amazon ElastiCache), and DynamoDB, in addition to their combined usage.

We focus on a real-world scenario involving a financial institution that handles 500,000 transactions per second for processing stock market data. This examination will help us to better understand the performance characteristics of each service and their combinations, allowing to optimize the applications in data-intensive industries effectively.

Scenario	Avg. Response Time	Requests per second	Latency (95th percentile)
GraphQL with AWS AppSync and Lambda	250 ms	4,000	450 ms
DynamoDB	15 ms	66,667	25 ms
Redis Cache with Amazon ElastiCache	2 ms	500,000	3 ms
GraphQL with AppSync, Lambda, and DynamoDB	270 ms	3,700	475 ms
GraphQL with AppSync, Lambda, and Redis Cache	220 ms	4,545	410 ms
DynamoDB with Redis Cache	4 ms	250,000	6 ms
GraphQL, AppSync, Lambda, DynamoDB, Redis	230 ms	4,348	420 ms

Avg Response Time:

Request Per Second:

Latency(95th Percentile):

Based on the benchmark metrics, we can conclude the following:

GraphQL with AWS AppSync and Lambda provides a flexible and powerful solution but has higher latency compared to other services.
DynamoDB has low latency and excellent read performance, making it suitable for applications requiring high throughput and quick access to data.
Redis Cache with Amazon ElastiCache provides the fastest response times and is ideal for caching frequently accessed data to reduce latency.
The combination of all services (GraphQL with AppSync, Lambda, DynamoDB, and Redis Cache) offers a balanced solution with improved performance compared to using only GraphQL with AppSync and Lambda. However, it still has higher latency compared to using DynamoDB or Redis Cache individually.

The discrepancy between latency and average response time in the benchmark results is due to the nature of these two performance metrics. Here's a brief explanation of both:

Latency: Latency refers to the time it takes for a request to travel from the sender to the receiver and for the receiver to process that request. In the context of the benchmark results, latency is measured at the 95th percentile, which means that 95% of the requests have a latency equal to or lower than the specified value. In other words, only 5% of the requests experience higher latency. The 95th percentile latency is often used as a performance indicator to understand the behavior of a system under high load or when dealing with occasional slow requests.

Average Response Time: The average response time is the arithmetic mean of the response times for all requests made during the benchmark. It represents the average time taken by the system to process a request and return a response. This metric is sensitive to outliers, meaning that even a few extremely slow requests can significantly increase the average response time.

When designing your application architecture, it is essential to consider these metrics and tailor the solution to your specific use case. Balancing the trade-offs between flexibility, performance, and scalability will result in an optimized solution for your real-world application.

Dear readers, if you require more detailed information about each service discussed in this article, please feel free to leave a comment below. Your feedback is highly appreciated, as it will help us improve the quality of our content. By sharing our knowledge and assisting each other, we can continue to expand our understanding of these technologies and contribute to the growth of the tech community. Together, we can learn and innovate more effectively.

AWS Services for Blogging: A Comprehensive Overview

manojlingala — Sun, 19 Mar 2023 10:02:55 +0000

In this article, we'll explore how to leverage AWS services to create a scalable and efficient system for blogging.

However, the intent of this article is not to build a complete blogging platform from scratch. Instead, we'll focus on showcasing how to use AWS services like Api gateway , Api , SQS, SNS , Dynamo DB to create a scalable and efficient backend for a blog.

Designing the Backend

Define the data model for the blog articles

Before we can start building the backend, we need to define the data model for the blog articles. Here's an example of what our data model might look like:

using System.Text.Json;

public class Article
{
    [JsonPropertyName("id")]
    public string Id { get; set; }

    [JsonPropertyName("title")]
    public string Title { get; set; }

    [JsonPropertyName("content")]
    public string Content { get; set; }

    [JsonPropertyName("author")]
    public string Author { get; set; }

    [JsonPropertyName("published")]
    public DateTime Published { get; set; }

    [JsonPropertyName("media")]
    public Media Media { get; set; }
}

public class Media
{
    [JsonPropertyName("url")]
    public string Url { get; set; }

    [JsonPropertyName("type")]
    public string Type { get; set; }
}

In this data model, we have several attributes for each article, including an id for identifying each article, a title, content, author, published date/time, and media information for any images or other media associated with the article.

Create a DynamoDB table for storing article data
Next, we need to create a DynamoDB table for storing the article data. Here's an example of how to create a DynamoDB table using the AWS SDK for .NET in C#:

AmazonDynamoDBClient client = new AmazonDynamoDBClient();

var request = new CreateTableRequest
{
    TableName = "ArticlesTable",
    KeySchema = new List<KeySchemaElement>
    {
        new KeySchemaElement("id", KeyType.HASH) // Partition key
    },
    AttributeDefinitions = new List<AttributeDefinition>
    {
        new AttributeDefinition("id", ScalarAttributeType.S)
    },
    ProvisionedThroughput = new ProvisionedThroughput
    {
        ReadCapacityUnits = 5,
        WriteCapacityUnits = 5
    }
};

CreateTableResponse response = await client.CreateTableAsync(request);

In this example, we're creating a DynamoDB table called ArticlesTable with a partition key of id. We're also specifying a provisioned throughput of 5 read and write capacity units.

Create an S3 bucket for storing media files
Now, let's create an S3 bucket for storing media files. Here's an example of how to create an S3 bucket using the AWS SDK for .NET in C#:

AmazonS3Client client = new AmazonS3Client();

var request = new PutBucketRequest
{
    BucketName = "my-media-bucket"
};

PutBucketResponse response = await client.PutBucketAsync(request);

In this example, we're creating an S3 bucket called my-media-bucket.

Set up Elastic Cache to improve performance of read-heavy operations

Finally, we'll set up Elastic Cache to improve the performance of read-heavy operations. Here's an example of how to create an Elastic Cache cluster using the AWS SDK for .NET in C#:

// GET api/articles
[HttpGet]
public async Task<ActionResult<IEnumerable<Article>>> Get()
{
    const string cacheKey = "RecentArticles";
    var articlesJson = await _cache.GetStringAsync(cacheKey);

    if (articlesJson == null)
    {
        var articles = await _dbContext.ScanAsync<Article>(new List<ScanCondition>()).GetRemainingAsync();
        articlesJson = JsonSerializer.Serialize(articles);
        await _cache.SetStringAsync(cacheKey, articlesJson, new DistributedCacheEntryOptions { AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(10) });
    }

    var articlesResult = JsonSerializer.Deserialize<IEnumerable<Article>>(articlesJson);
    return Ok(articlesResult);
}

Use SNS to notify subscribers when a new comment is added:

// POST api/articles/{articleId}/comments
[HttpPost("{articleId}/comments")]
public async Task<ActionResult> AddComment(string articleId, Comment comment)
{
    // Save the comment to DynamoDB (assume a method called SaveCommentAsync exists)
    await SaveCommentAsync(articleId, comment);

    // Publish a message to the SNS topic
    var message = $"A new comment was added to article {articleId} by {comment.Author}.";
    var request = new PublishRequest
    {
        TopicArn = Configuration["AWS:SNS:NewCommentTopicArn"],
        Message = message
    };
    await _snsClient.PublishAsync(request);

    return CreatedAtAction(nameof(GetComment), new { articleId, commentId = comment.Id }, comment);
}

Use SQS to process tasks, such as sending emails to users:

// POST api/users
[HttpPost]
public async Task<ActionResult<User>> CreateUser(User user)
{
  await SaveUserAsync(user);
 // Send a welcome email using SQS
    var messageBody = JsonSerializer.Serialize(new
    {
        Email = user.Email,
        Subject = "Welcome to the Blogging Platform",
        Body = $"Hi {user.FirstName},\n\nThank you for joining our blogging platform! We're excited to have you on board.\n\nBest regards,\nThe Blogging Platform Team"
    });

    var sendMessageRequest = new SendMessageRequest
    {
        QueueUrl = Configuration["AWS:SQS:EmailQueueUrl"],
        MessageBody = messageBody
    };
    await _sqsClient.SendMessageAsync(sendMessageRequest);

    return CreatedAtAction(nameof(GetUser), new { id = user.Id }, user);
}

Let's discuss how the architecture we've set up using AWS services impacts scalability, performance, and reliability,

Scalability:

API Gateway and Lambda allow you to create serverless applications that can scale automatically with the number of incoming requests. This means you don't have to worry about provisioning or managing servers to handle a growing user base.
DynamoDB is a managed NoSQL database that can scale horizontally to support large amounts of data and high request rates. It automatically partitions your data across multiple servers to provide consistent, low-latency performance.
SQS enables you to decouple components of your application, allowing you to scale each component independently. This helps ensure that your application remains responsive even when individual components experience high load.
SNS supports the fan-out messaging pattern, allowing you to easily distribute messages to multiple subscribers. As the number of subscribers grows, SNS can handle the increased load without affecting the performance of your application.

Performance:

ElastiCache provides an in-memory data store that can be used to cache frequently accessed data, reducing the latency of data retrieval and offloading read traffic from your database. This helps to improve the overall performance of your application.
Lambda functions execute in parallel, enabling your application to handle a large number of requests concurrently. This ensures that your application can respond quickly to user requests even during peak traffic periods.
DynamoDB's consistent, single-digit millisecond latency enables you to build high-performance applications that require low-latency data access.

Reliability:

AWS services, such as API Gateway, Lambda, DynamoDB, SQS, and SNS, are designed for high availability and durability. They are hosted across multiple Availability Zones, ensuring that your application remains operational even if an entire data center experiences an outage.
By decoupling components using SQS, you can build fault-tolerant applications that can continue to operate even if individual components fail. This helps to ensure that your application remains reliable and available to users.

In this article, we've discussed how to build a scalable, high-performance blogging system using AWS services, including Lambda, SQS, SNS, DynamoDB, and ElastiCache. We have also touched on the data models, example code, and practical implementation of various AWS services. By leveraging these services, you can create a serverless architecture that easily scales with demand, provides high performance, and ensures reliability, allowing you to focus on building features and functionality rather than managing infrastructure.

Note to readers: If you require more in-depth information on each topic or have any questions, please feel free to leave a comment below. I would be more than happy to address your concerns and help my fellow developers dive deeper into these topics. Your feedback and engagement are valuable to me, and I look forward to assisting you in your journey with AWS and serverless technologies.

Custom Converters in DynamoDB: Building Robust Data Models with Ease

manojlingala — Sat, 11 Mar 2023 10:04:32 +0000

DynamoDB's custom converters feature allows you to define custom mappings between your application's data model and DynamoDB's attribute-value data model. This is particularly useful when working with complex or custom data types, such as enums or value objects, that may not be natively supported by DynamoDB.

By using custom converters, you can simplify your application's code and reduce the amount of boilerplate code required for mapping between your application and DynamoDB. Custom converters can also improve performance by reducing the amount of data that needs to be transferred between your application and DynamoDB, and by allowing you to optimize the way data is stored and retrieved.

The purpose of this article is to demonstrate how to use two specific types of custom converters in DynamoDB: Enum Converter and Value Object Converter. These converters are particularly useful for mapping enums and value objects to and from DynamoDB attribute values, respectively. We will provide code examples and discuss some advanced topics related to custom converters in DynamoDB.

DynamoDB's Enum Converter allows you to map between dotnet or any other supported language specific enums and DynamoDB attribute values. This is useful because DynamoDB natively supports only a limited set of data types, such as strings, numbers, and binary data. With Enum Converter, you can map your application's enums to these native data types, and store them in DynamoDB as attributes.

Here's an example of how to create and use an Enum Converter in DynamoDB:

using Amazon.DynamoDBv2.DataModel;
using Amazon.DynamoDBv2.DocumentModel;

public enum PaymentMethod
{
    CreditCard,
    PayPal,
    Bitcoin
}

public class PaymentMethodConverter : IPropertyConverter
{
    public DynamoDBEntry ToEntry(object value)
    {
        return new Primitive((value as PaymentMethod).ToString());
    }

    public object FromEntry(DynamoDBEntry entry)
    {
        return Enum.Parse(typeof(PaymentMethod), entry.AsString());
    }
}

We can then use this converter in our data model as follows:

[DynamoDBTable("Orders")]
public class Order
{
    [DynamoDBProperty("paymentMethod"), DynamoDBTypeConverter(typeof(PaymentMethodConverter))]
    public PaymentMethod PaymentMethod { get; set; }

    // ... other properties and methods
}

Value objects are a concept in software development that represent an immutable value or set of values with a specific behavior. They can be used to encapsulate complex or custom data types that don't fit into the simple data types supported by databases like DynamoDB. Value objects are typically implemented as immutable classes that expose their data through getters and don't have any setters or other mutators.

The benefits of using value objects over primitives or simple types include increased type safety, better encapsulation, and more expressive code. By using value objects, you can reduce the likelihood of errors due to incorrect types or values, and you can make your code more readable and maintainable.

DynamoDB's Value Object Converter allows you to map between value objects and DynamoDB attribute values.

Here's an example of how to create and use a Value Object Converter in DynamoDB:

using Amazon.DynamoDBv2.DataModel;
using Newtonsoft.Json;

public class Address
{
    public string Street { get; set; }
    public string City { get; set; }
    public string State { get; set; }
    public string ZipCode { get; set; }
}

public class AddressConverter : IPropertyConverter
{
    public DynamoDBEntry ToEntry(object value)
    {
        return new Primitive(JsonConvert.SerializeObject(value));
    }

    public object FromEntry(DynamoDBEntry entry)
    {
        return JsonConvert.DeserializeObject(entry.AsString(), typeof(Address));
    }
}

We use the Newtonsoft.Json / System.Text to convert the value object to/from JSON string. We can then use this converter in our data model as follows:

[DynamoDBTable("Customers")]
public class Customer
{
    [DynamoDBProperty("address"), DynamoDBTypeConverter(typeof(AddressConverter))]
    public Address Address { get; set; }

    // ... other properties and methods
}

Handling nested objects
Sometimes, your data model may contain nested objects, where one object contains another object as a property. In these cases, you can use a combination of custom converters to handle the nested objects.

For example, suppose we have the following data model:

using Amazon.DynamoDBv2.DataModel;
using Newtonsoft.Json;
using System.Collections.Generic;

public class Address
{
    public string Street { get; set; }
    public string City { get; set; }
    public string State { get; set; }
    public string ZipCode { get; set; }
}

public class Customer
{
    public string CustomerId { get; set; }
    public Address Address { get; set; }
}

public class Order
{
    public string OrderId { get; set; }
    public Customer Customer { get; set; }
}

public class AddressConverter : IPropertyConverter
{
    public DynamoDBEntry ToEntry(object value)
    {
        return new Primitive(JsonConvert.SerializeObject(value));
    }

    public object FromEntry(DynamoDBEntry entry)
    {
        return JsonConvert.DeserializeObject(entry.AsString(), typeof(Address));
    }
}

public class CustomerConverter : IPropertyConverter
{
    public DynamoDBEntry ToEntry(object value)
    {
        var customer = (Customer)value;
        var address = new AttributeValue(new AddressConverter().ToEntry(customer.Address));

        var map = new Dictionary<string, AttributeValue>
        {
            {"CustomerId", new AttributeValue(customer.CustomerId)},
            {"Address", address}
        };

        return new AttributeValue(map);
    }

    public object FromEntry(DynamoDBEntry entry)
    {
        var map = entry.M;

        return new Customer
        {
            CustomerId = map["CustomerId"].S,
            Address = (Address)new AddressConverter().FromEntry(map["Address"].S)
        };
    }
}

public class OrderConverter : IPropertyConverter
{
    public DynamoDBEntry ToEntry(object value)
    {
        var order = (Order)value;
        var customer = new AttributeValue(new CustomerConverter().ToEntry(order.Customer));

        var map = new Dictionary<string, AttributeValue>
        {
            {"OrderId", new AttributeValue(order.OrderId)},
            {"Customer", customer}
        };

        return new AttributeValue(map);
    }

    public object FromEntry(DynamoDBEntry entry)
    {
        var map = entry.M;

        return new Order
        {
            OrderId = map["OrderId"].S,
            Customer = (Customer)new CustomerConverter().FromEntry(map["Customer"].M)
        };
    }
}

In summary, we have explored how to use custom converters in DynamoDB to map between your application's data model and DynamoDB attribute values. Specifically, we have looked at Enum Converter and Value Object Converter as ways to map C# enums and value objects, respectively, to DynamoDB attribute values. We have also covered some advanced topics, such as handling nested objects and using custom serialization/deserialization libraries.

Thank you for reading ❤️.

A Developer’s Guide to Avoiding the Pitfalls of Exposing the Domain Layer

manojlingala — Sat, 11 Mar 2023 04:43:11 +0000

There are several reasons why developers may tend to develop domain and domain repositories exposing to the application layer

Lack of understanding of the architecture: Developers who are not familiar with the principles of good software architecture may not fully understand the importance of separating the domain and application layers.

Time constraints: Developers may be under pressure to deliver features quickly and may not take the time to properly separate the domain and application layers.

Lack of experience: Developers who lack experience in building large, complex applications may not have the knowledge or skills to properly separate the domain and application layers.

Lack of planning: Developers may not have taken the time to plan out the architecture of the application and may make decisions on the fly that lead to the domain and application layers being tightly coupled.

Lack of consideration for long-term maintainability: Developers may not be thinking about the long-term maintenance and scalability of the application and may not see the benefits of keeping the domain and application layers separate.

Complexity of the domain: Developers may find it difficult to separate the domain and application layers because the domain is complex and requires a lot of knowledge about the domain.

It’s important to note that exposing domain and domain repositories to app layer could cause technical debt in the long run. It’s better to avoid this kind of design and invest time to plan the architecture of the application in a way that separates the concerns and make the application more maintainable and scalable.

Thank you for reading ❤️.

Maximizing Efficiency in DynamoDB: The Power of Projections

manojlingala — Fri, 10 Mar 2023 22:01:25 +0000

DynamoDB is a fast and flexible NoSQL database service offered by Amazon Web Services (AWS). It is designed to provide high performance, scalability, and availability for modern applications. DynamoDB is a fully managed service, which means AWS takes care of the infrastructure, scaling, and maintenance of the database, allowing developers to focus on building their applications.

One important concept in DynamoDB is projections. A projection is a way to specify which attributes should be included in the result of a query or scan operation. By default, a query or scan operation returns all the attributes of an item. However, in many cases, you only need a subset of the attributes. Using projections, you can reduce the amount of data that needs to be read and returned, which can lead to faster query response times and lower data transfer costs.

In this article, we will explore the different types of projections available in DynamoDB, how to use them to optimize your queries, and best practices for using projections in your application.

Here are some examples of when to use each projection type in different scenarios, as well as code examples for creating and querying a table with each projection type:

All attributes projection:
You might use the All attributes projection when you need to retrieve all the attributes of an item in a table that stores financial transactions. For instance, imagine that you have a table called "Transactions" with the following attributes: TransactionId, Date, Amount, Description, and Status. If you need to retrieve all the details for a specific transaction, you could use the All attributes projection.



// Create a table with the All attributes projection
const params = {
  TableName: 'Transactions',
  KeySchema: [
    { AttributeName: 'TransactionId', KeyType: 'HASH' }
  ],
  AttributeDefinitions: [
    { AttributeName: 'TransactionId', AttributeType: 'S' },
    { AttributeName: 'Date', AttributeType: 'S' },
    { AttributeName: 'Amount', AttributeType: 'N' },
    { AttributeName: 'Description', AttributeType: 'S' },
    { AttributeName: 'Status', AttributeType: 'S' }
  ],
  Projection: {
    ProjectionType: 'ALL'
  }
};

await dynamodb.createTable(params).promise();

// Query the table with the All attributes projection
const queryParams = {
  TableName: 'Transactions',
  KeyConditionExpression: 'TransactionId = :transactionId',
  ExpressionAttributeValues: {
    ':transactionId': 'abc123'
  }
};

const result = await dynamodb.query(queryParams).promise();
console.log(result.Items);

Keys only projection:
You might use the Keys only projection when you need to retrieve a list of primary key values in a table that stores user information. For example, imagine that you have a table called "Users" with the following attributes: UserId, Name, Email, and PhoneNumber. If you need to retrieve a list of UserIds, you could use the Keys only projection.



// Create a table with the Keys only projection
const params = {
  TableName: 'Users',
  KeySchema: [
    { AttributeName: 'UserId', KeyType: 'HASH' }
  ],
  AttributeDefinitions: [
    { AttributeName: 'UserId', AttributeType: 'S' },
    { AttributeName: 'Name', AttributeType: 'S' },
    { AttributeName: 'Email', AttributeType: 'S' },
    { AttributeName: 'PhoneNumber', AttributeType: 'S' }
  ],
  Projection: {
    ProjectionType: 'KEYS_ONLY'
  }
};

await dynamodb.createTable(params).promise();

// Query the table with the Keys only projection
const queryParams = {
  TableName: 'Users',
  KeyConditionExpression: 'Name = :name',
  ExpressionAttributeValues: {
    ':name': 'John Doe'
  },
  ProjectionExpression: 'UserId'
};

const result = await dynamodb.query(queryParams).promise();
console.log(result.Items);

Include projection:
You might use the Include projection when you need to retrieve a subset of the attributes for a specific item in a table that stores product information. For instance, imagine that you have a table called "Products" with the following attributes: ProductId, Name, Description, Price, and Quantity. If you need to retrieve the Name and Price for a specific product, you could use the Include projection.



// Define the table schema
const tableSchema = {
  TableName: 'Products',
  KeySchema: [
    { AttributeName: 'ProductId', KeyType: 'HASH' }
  ],
  AttributeDefinitions: [
    { AttributeName: 'ProductId', AttributeType: 'S' },
    { AttributeName: 'Name', AttributeType: 'S' },
    { AttributeName: 'Description', AttributeType: 'S' },
    { AttributeName: 'Price', AttributeType: 'N' },
    { AttributeName: 'Quantity', AttributeType: 'N' }
  ],
  ProvisionedThroughput: {
    ReadCapacityUnits: 5,
    WriteCapacityUnits: 5
  },
  GlobalSecondaryIndexes: [
    {
      IndexName: 'NameIndex',
      KeySchema: [
        { AttributeName: 'Name', KeyType: 'HASH' }
      ],
      Projection: {
        ProjectionType: 'INCLUDE',
        NonKeyAttributes: [ 'Price' ]
      },
      ProvisionedThroughput: {
        ReadCapacityUnits: 5,
        WriteCapacityUnits: 5
      }
    }
  ]
};

// Create the table in DynamoDB
const createTableResult = await dynamodb.createTable(tableSchema).promise();
console.log('Table created:', createTableResult);

// Query the table using the NameIndex GSI and the Include projection
const queryParams = {
  TableName: 'Products',
  IndexName: 'NameIndex',
  KeyConditionExpression: 'Name = :name',
  ExpressionAttributeValues: {
    ':name': 'Product 1'
  },
  ProjectionExpression: 'Name, Price'
};

const queryResult = await dynamodb.query(queryParams).promise();
console.log('Query result:', queryResult.Items);

In summary, to use projections effectively, it is important to choose the most efficient projection type for your query, only request the attributes you need, avoid unnecessary scans and queries, use secondary indexes to improve query performance, minimize the size of your response data, and monitor your query performance.

Understanding and using projections can help you get the most out of DynamoDB and improve the performance of your queries, which is essential for building fast and efficient modern applications.

The Consequences of Property Injection in Tightly Coupled Systems : A Developer’s Guide

manojlingala — Sun, 05 Mar 2023 01:49:11 +0000

Developers may try to use property injection in a tightly coupled system for several reasons:

1.Ease of use: Property injection can be a simple and straightforward way to pass dependencies between objects, making it a popular choice for developers who are new to dependency injection.

2.Familiarity: Developers who are used to working with tightly coupled systems may find it more natural to use property injection, as it resembles the way dependencies are typically handled in tightly coupled systems.

3.Lack of planning: Developers may not have taken the time to plan out the architecture of the application and may make decisions on the fly that lead to the use of property injection in a tightly coupled system.

public class OrderService 
{
    private IOrderRepository _orderRepository;
    public IOrderRepository OrderRepository 
    {
        get { return _orderRepository; }
        set { _orderRepository = value; }
    }

    public void SaveOrder(Order order) 
    {
        // Use the injected repository to save the order
        _orderRepository.Save(order);
    }
}

class Program
{
    static void Main(string[] args)
    {
        // Create an instance of the repository
        var orderRepository = new OrderRepository();

        // Create an instance of the service and property inject the repository
        var orderService = new OrderService();
        orderService.OrderRepository = orderRepository;

        // Create a new order
        var newOrder = new Order { Id = 1, Customer = "John Doe" };

        // Save the order using the service
        orderService.SaveOrder(newOrder);
    }
}

In this example, the OrderServiceclass has a property called OrderRepositoryof type IOrderRepository. The property setter is used to inject an instance of IOrderRepository into the OrderServiceclass. The SaveOrdermethod then uses the injected repository to save the order. This type of injection is simple and easy, but it has some drawbacks.

It’s important to notice that the OrderServiceclass is tightly coupled to the IOrderRepositoryinterface and any class that implements it, making it difficult to change the implementation of the repository without modifying the OrderServiceclass. Additionally, it's also not clear from the constructor of the OrderServiceclass that the IOrderRepositoryis a required dependency, and it could lead to the class being used without the dependency being set.

It’s important to note that property injection could cause problems in the long run because it makes the dependencies between objects implicit and hard to reason about, and also does not provide compile-time safety. It’s better to avoid this kind of design and invest time to plan the architecture of the application in a way that separates the concerns and make the application more maintainable and scalable.

Why Separating Domain and Application Layers is Crucial for Achieving a Clean Architecture

manojlingala — Sat, 04 Mar 2023 08:38:58 +0000

When building software, it’s essential to consider the architecture and how different parts of the system will interact with each other. One way to achieve a clean and maintainable codebase is to separate concerns and keep different layers of the application separate. One such separation is between the domain and the application layer.

The domain layer is responsible for modeling the business logic and the domain objects. It contains the entities, value objects, services, and interfaces that make up the core of the business logic. On the other hand, the application layer is responsible for handling user interactions, coordinating the flow of data between the domain and the presentation layer and applying the use cases of the system.

One aspect of this separation is that the domain layer should not be exposed to the application layer. This means that the application layer should not have direct access to the domain objects or the domain repositories. Instead, the application layer should use services or interfaces provided by the domain layer to access and manipulate the domain objects.

There are several reasons why domain and domain repositories should not be exposed to the application layer

First, exposing the domain layer to the application layer can lead to tight coupling between the two layers. This can make it difficult to change the domain layer without also having to make changes to the application layer. Tight coupling can also make it harder to test the application layer, as changes in the domain layer can have unexpected consequences on the application layer.

       +----------------------------------------+
       |              Application Layer         |
       |                                        |       
       |          +-------------------------+   |       
       |          |       Application       |   |       
       |          |         Services        |   |       
       |          +-------------------------+   |       
       |                         ^              |       
       |                         |              |       
       |          +-------------------------+   |       
       |          |        Domain Layer      |  |       
       |          +-------------------------+   |       
       |                                        |       
       +----------------------------------------+

Second, exposing the domain layer to the application layer can make the application layer more complex and harder to understand. The application layer should only be concerned with handling user interactions and coordinating the flow of data, not with the details of the domain. By keeping the domain layer separate, the application layer can be more focused and easier to reason about.

Third, exposing the domain layer to the application layer can lead to the application layer having too much knowledge about the domain. This can make it difficult to change the domain or to add new features to the application. By keeping the domain layer separate, the application layer can be more flexible and adaptable to changes in the domain.

Finally, exposing the domain layer to the application layer can make the application layer more vulnerable to security vulnerabilities. An attacker can potentially access and manipulate the domain objects and domain repositories through the application layer, leading to data integrity and data confidentiality issues. By keeping the domain layer separate, the application layer can be more secure and better protected against these types of attacks.

In conclusion, separating the domain and the application layer is an important aspect of software architecture. It is essential that domain and domain repositories are not exposed to the application layer to maintain a clean and maintainable codebase. This separation allows for more flexibility, scalability, and security in the long run. By keeping the domain layer separate, we can ensure that the application layer is focused, easy to reason about, and secure.

Solving the Service Registration Dilemma with Service Resolver in Strategy Pattern

manojlingala — Fri, 03 Mar 2023 23:37:28 +0000

Strategy Pattern is a design pattern that provides a way to encapsulate algorithms, encapsulate methods that can be interchanged to solve a problem. One of the main advantages of this pattern is the ability to switch algorithms at runtime. This pattern involves creating objects that represent various strategies, and a context object whose behavior varies as per its strategy object.

When using strategy pattern, one issue faced is service registration, where multiple implementations of the same interface are registered with the dependency injection container. In such scenarios, the latest service registration overwrites previous configurations as they all have the same interface.

The Service Resolver pattern provides a solution to resolve the appropriate service instances when multiple implementations of the same interface are registered with the dependency injection container. It involves creating a Service Resolver class that holds a reference to the IServiceCollectionand uses the BuildServiceProvider() method of IServiceCollectionto resolve the appropriate service instance based on the provided product code.

Here is an example of Service Resolver implementation in C#.

public class ServiceResolver
{
    private readonly IServiceCollection _services;

    public ServiceResolver(IServiceCollection services)
    {
        _services = services;
    }

    public T Resolve<T>(ProductCode productCode)
    {
        switch (productCode)
        {
            case ProductCode.ProductA:
                return (T)_services.BuildServiceProvider().GetService(typeof(ProductAService));
            case ProductCode.ProductB:
                return (T)_services.BuildServiceProvider().GetService(typeof(ProductBService));
            default:
                throw new InvalidOperationException("Invalid product code");
        }
    }
}

The Service Resolver class can be registered in the Startup.cs file as follows:

public void ConfigureServices(IServiceCollection services)
{
    services.AddSingleton<ServiceResolver>();
    services.AddScoped<IProductService,ProductAService>();
    services.AddScoped<IProductService,ProductBService>();
}

Here is a sample XUnit test case for the ServiceResolver class:

public class ServiceResolverTests
{
    private ServiceResolver _serviceResolver;
    private IServiceCollection _services;
    private IServiceProvider _serviceProvider;

    [Fact]
    public void Resolve_ProductA_ReturnsProductAService()
    {
        // Arrange
        _services = new ServiceCollection();
        _services.AddScoped<IProductService, ProductAService>();
        _serviceProvider = _services.BuildServiceProvider();
        _serviceResolver = new ServiceResolver(_services);

        // Act
        var result = _serviceResolver.Resolve<IProductService>(ProductCode.ProductA);

        // Assert
        Assert.IsType<ProductAService>(result);
    }

    [Fact]
    public void Resolve_ProductB_ReturnsProductBService()
    {
        // Arrange
        _services = new ServiceCollection();
        _services.AddScoped<IProductService, ProductBService>();
        _serviceProvider = _services.BuildServiceProvider();
        _serviceResolver = new ServiceResolver(_services);

        // Act
        var result = _serviceResolver.Resolve<IProductService>(ProductCode.ProductB);

        // Assert
        Assert.IsType<ProductBService>(result);
    }

    [Fact]
    public void Resolve_InvalidProductCode_ThrowsInvalidOperationException()
    {
        // Arrange
        _services = new ServiceCollection();
        _services.AddScoped<IProductService, ProductAService>();
        _serviceProvider = _services.BuildServiceProvider();
        _serviceResolver = new ServiceResolver(_services);

        // Act and Assert
        Assert.Throws<InvalidOperationException>(() => _serviceResolver.Resolve<IProductService>((ProductCode)99));
    }
}

In conclusion, the Strategy Pattern is a powerful design pattern that provides a flexible way of switching between different implementations of a single interface. However, when it comes to service registration, this pattern can cause some problems, such as overwriting previous configurations, and making it difficult to determine the correct service to use. The Service Resolver is a solution to this problem, allowing for the resolution of the correct service instance to be performed dynamically at runtime. This can be achieved through the use of the switch statement, which enables the selection of the appropriate service instance based on the input received.

In this article, we have covered the basics of the Strategy Pattern, the issues it can cause in service registration, and how the Service Resolver can be used to resolve these problems. Furthermore, we have demonstrated an example implementation of the Service Resolver and its accompanying unit tests, providing a solid foundation for anyone looking to incorporate this pattern into their own projects.