Blog

Publishing a React website on AWS with AWS amplify and AWS CloudFront with Custom Domain (Part 2) - Best Software Development Team Extension Partner for Nordics

Eimon Hossain Taief — Fri, 24 Apr 2026 09:52:07 GMT

This post is a part of the series which will help you publish your React based project/website on AWS using AWS Amplify and AWS CloudFront. This part will walk you through the steps to setup AWS CloudFront so that you can access your website using any domain of your own.

If you want to learn about how to upload your React project on AWS using AWS Amplify or if you just want to follow along with this whole series, check out Part 1. This post will continue from where we left off in the first part. So it’s recommended that you go through that one first.

Part 1 covers the React project creation and AWS Amplify part.
Part 2 covers the CloudFront configuration and custom domain setup part.

Before You Begin (part 2)

As this post uses AWS, we will assume that you already have an AWS account or have access to an account, as you will need to use your credentials for AWS Amplify and will need to go to AWS console and configure AWS CloudFront. If you still think this post can help you, then let’s get into it.

Create an AWS CloudFront Distribution

Well, to begin with, what we need to do first? Of course create a new CloudFront distribution, what else, right? So let’s head to the AWS CloudFront console home page and select the Create Distribution button.

CloudFront Home page

After that, it will take you to the delivery method selection page, where, as of the time of this post writing, you will be given two(2) options to choose from, one is Web, the other one is RTMP (which will be discontinued from December 31, 2020). We will be selecting the Web one.

Now we will actually get the main form to create a new CloudFront Distribution.

If you click on the Origin Domain Name input box, AWS will suggest the S3 buckets you have along with some other options. We need to select the one we created in Part 1, which was reactawsamplify-20201222013512-hostingbucket-dev. But there is a catch, we can’t just select the bucket from the drop-down as it will only point the distribution to the bucket, which we don’t want. We want the distribution to point at the hosting site. So instead of just writing the name of the bucket, we will write the entire hosting URL.

By this time, you might be wondering how the hell you will get the URL? Do you have to publish the project with AWS Amplify again just to get the URL? Well, don’t worry about that, you don’t have to go to such length. There is an easy and convenient way to get that. Just go into the S3 bucket, and select the Properties tab on the top.

Select the Properties tab on the S3 bucket

On that page, went to the bottom of the page and you will find a card named Static website hosting and there you will find the desired URL.

The URL of the hosting site

Copy that URL and paste it on the CloudFront Distribution page’s Origin Domain Name input field and click anywhere outside. It will load the necessary information into the other input fields.

Paste the URL in this input box

Now let’s set up the other fields that we need. We will keep the default value for the following fields: Enable Origin Shield, Origin Connection Attempts, Origin Connection Timeout, Smooth Streaming, Restrict Viewer Access(Use Signed URLs or Signed Cookies), Compress Objects Automatically, Supported HTTP Versions, Enable IPv6.

So let’s start customizing the Default Cache Behavior Settings.

1st of all, we will change the Viewer Protocol Policy settings. You can keep it as it is, but it’s recommended to change it to Redirect HTTP to HTTPS.
2nd, as our current website doesn’t have any PUT, POST, or DELETE operations, we will not change Allowed HTTP Methods. But if you have a form or you communicate with an API, then you need to select the GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE option.
3rd, for the Cache and origin request settings, we’ll change it to Use legacy cache settings as we don’t want to keep any cache. If you want to keep it, don’t change the settings.
If in the 3rd one, you selected the Use legacy cache settings, then you will get an Object Caching option. Which we will change to Customize and then set the Minimum TTL, Maximum TTL, Default TTL to 0 (zero). This will help the users to get up-to-date content each time they reload the page.

This is the end result so far that we have implemented in the distribution page:

The settings we implemented so far in the previous steps

Now it’s time for the Distribution Settings part. In this part, we will actually keep most of the things as it is, but this is the place where we will set up the custom domain. You can do that later so we will go through the process for now and keep all the default values. Just click Create Distribution at the bottom and you are done!!

You will be taken to the CloudFront home page and you will find the distribution you just created.

You will find the distribution on the CloudFront home page

It takes some time for the distribution to be deployed for the first time. When it’s done, you will the Status as Deployed. When that is ready, you can copy the Domain Name and paste it in the browser and you will see it’s showing the website you hosted on the S3 bucket! So now you don’t have to remember the long S3 bucket hosting URL just to visit the website.

Use the URL from the domain name to visit the website. Website loading using the Domain name from the CloudFront

Setting up Custom Domain

For setting the custom domain, we need two things.

A registered domain and access to that domain’s DNS setting or access to the mails for that domain.
A custom SSL certificate generated from AWS

We’ll assume you already have a domain registered somewhere. And you have access to your DNS settings. But if you don’t have access to DNS, then it’s alright too, as we will show you how to get registered using email as well.

To get the SSL Certificate, if you already don’t have one, you can just click the Request or Import a Certificate with ACM from the distribution page.

Or you can also directly to the Request Certificatepage. Request custom SSL Certificate page

Enter your custom domain name and press Next.

Then you will be taken to the Select validation method page, where you will get two types of validation method:

DNS validation: It’s the most used one. It requires the user to go to the domain DNS settings page, then adding a new CNAME record.
Email validation: It uses some pre-configured email address to send you a validation email where you will be asked to verify that you requested the SSL certificate. If you accept that, then it will create an ACM SSL certificate in AWS. The email addresses are:
* postmaster@yourdomain.com
* hostmaster@yourdomain.com
* admin@yourdomain.com
* webmaster@yourdomain.com
* administrator@yourdomain.com

We will just briefly walk you through both of the ways just in a bit. But for now, let’s continue by selecting the Email validation option as it is the easy one.

In the next step, just press Review and you will be given a final checkup.

Make sure everything is in place

Now hit Confirm and it’s ready to go. AWS will send you an email for the confirmation on the pre-configured email addresses as mentioned before.

Email is sent to the shown email addresses

Until you verify your email or set up the DNS, you will see the verification status as Pending validation.

Waiting for confirmation

This is how a verification email looks like:

The verification email from AWS

Just press the Amazon Certificate Approvals link or copy and paste the URL on any browser and it will show you the message again. Hit the I Approve button and you are all set!

You can find that on the SSL certificate page as well if you refresh it.

The domain SSL certificate is created
For some domain/hosting platform, the Email Validation doesn’t work. If you find that the domain is not working, try using the DNS Validation instead of Email Validation. The DNS CNAME record-setting differs for different vendors. So we can’t cover that here.

DNS validation Process
In case you selected DNS instead of Email, you will have to follow a different route. In that case, after you Confirm the process, you will get this:

CNAME record credentials You will find the credentials you need to set in the domain DNS system as a CNAME record. You can also download that credentials CSV file if you want to do it later or send it to someone who has access to the DNS settings. After the CNAME record is created, it will show the status as issued in the SSL certificate list.

When setting up the CNAME, you actually will need to set up 2 CNAME records.

For verifying the custom SSL certificate. In this case, the name and value you will get from the AWS, the image we’ve shown just before.
For redirecting to the CloudFront when we enter the domain on a browser. The name for this one will be the custom domain name you want to set up for the website (in our case reactaws.apphousebd.com) and the value will be the CloudFront distribution domain name. Keep in mind the custom domain name you set up for as the name, because it will be needed later when setting up the Alternate Domain Names (CNAMEs) field.

CloudFront distribution domain name
It may take some time to verify the domain with DNS validation, so wait at least 5–10 mins before trying again.

Setting the Custom domain in CloudFront

Now for the moment that we are building up the whole thing!

Go to the CloudFront distribution page and select Edit.

There in the Alternate Domain Names (CNAMEs) field, enter the custom domain name of which you have already created an SSL certificate.
After that, select the Custom SSL Certificate (example.com) option for SSL Certificate. There if you click on the input box, you will find the SSL certificate you created. Select the one with the domain you entered in the previous step.
Enter index.html in the Default Root Object input field
Keep the other thins as it is.

Distribution setting after everything is set up

Hit Yes, Edit and that’s it. Finally, everything is over!!! Just wait until the status of the CloudFront distribution is changed from In Progress to Deployed and then you can test the website with the custom domain you just set.

Well, it’s been a long way since the start. But I believe you now have enough knowledge about how to deploy your own or any other person’s React website on AWS. Hope this post helps you in your exciting coding/developer life.

Happy coding!

Two Heads, One Keyboard: The Magic of Pair Programming - Best Software Development Team Extension Partner for Nordics

Foisal Reza — Thu, 18 Dec 2025 18:00:00 GMT

Introduction

We programmers often think that programming is a solitary job. But it is more of a social job. Developers are more productive when they are inspired and collaborate with their teams. This entails providing developers with tools and resources that will enable them to cooperate more effectively with other developers.

We can achieve this by a variety of tactics and one of the most widely regarded methodologies is pair programming. At first glance one can identify these tactics as to improve productivity but it also adds a pair with your colleague, besides producing code with fewer bugs, code with more readability, better solutions of the problem and sharing knowledge.

What is Pair Programming?

Pair Programming is a programming methodology where two programmers are working together on a single task simultaneously and collaboratively. While doing the task they share their thoughts on how to solve the problem efficiently. And ultimately they came up with an optimum solution for the problem. There are many ways to do pair programming. One of the widely regarded patterns is having two roles, one is driver and the other one is navigator.

The Driver Navigator Style

One of the most widely used styles as far as pair programming is concerned is the driver-navigator.

Its term comes from how two travelers may manage a vehicle drive through a new region. The driver concentrates on tactical issues concerning the mechanics of the action. This includes using the gas and brake pedals, moving the wheel, and keeping a lookout for hazards and other vehicles. The navigator, on the other hand, focuses more on the larger picture. How long will we be on this highway until we have to exit? Does my phone alert me to any unforeseen traffic jams?

When you apply the metaphor to programming, the driver handles typing, file navigation, and basic implementation. The navigator, on the other hand, considers wider issues and checks for errors. Is this technique consistent with the architecture? Are we potentially duplicating an existing implementation? Is this a dead end?

Driver-navigator works best with two specialists who can switch responsibilities. It works well with both an expert and a novice. This occurs most readily when the expert navigates because a novice navigator may sit idly while the expert does both jobs.

Pair Partner

A pair partner is one of the two developers who is actively doing the same task in real time using the same workstation. A pair partner may alternate between being a driver and a navigator. As both pair programmers will actively do a single task it is important to have a good pair partner. A good pair partner is a blessing in disguise, often bringing unexpected benefits that enhance the development process.

Advantages of a Good Pair Programmer: Having a good pair partner can speed up productivity. The continuous feedback loop and collaborative problem solving actually reduce the time spent in debugging and rework. They can brainstorm the solution in real time resulting in an optimum solution.
Emotional and Mental Awareness: An attentive pair partner is always aware of their other’s mental and emotional conditions and may spot symptoms of worry, exhaustion, or tension. Keeping a safe and effective work environment requires this insight. A quick coffee break or some lighthearted talk can help ease tensions when one partner senses that the other is feeling overburdened or anxious. These modest yet thoughtful deeds promote a supportive environment, relieve tension, and act as a mental reset.
Benefits of Breaks and Informal Interaction: Keep the screen away from the eyesight, both partners can return to their task with a refreshed mind and renewed energy. Additionally, some informal chats or some funny jokes can strengthen their bond, making the collaboration job more enjoyable and productive. This kind of behavior not only boosts morale but also enhances overall productivity, as both of the pair partners ensure that they will operate at their best as possible. So in the long run such mindful interactions with the pair partner contribute a lot.
Long-Term Contributions: A good pair partner encourages continuous improvement. Through constructive feedback and shared learning experiences, both partners can continuously refine their skills and approaches. This commitment to ongoing development can lead to long-term benefits, making each subsequent project more efficient and successful.

How to Find a Pair Partner

As previously stated, having a decent companion is a blessing in disguise. If one can find a decent companion, development can be joyful; otherwise, it can be a disaster. Because if one’s partner is not open to new experiences, heated fights may arise. So it is important to pick one that is appropriate. Here are some strategies to help you find the right person to pair with:

Seek Experience and Openness: If you’re doing pair programming for the first time, it’s a good idea to find someone who has done it before. An Experienced guy can guide you through the whole process and also tell you the best practices one should follow while pair programming.
Compatibility and Communication: It is also vital to locate a partner who is compatible with you. Someone with whom one may work despite any fear or awkwardness associated with asking dumb questions. Effective pair programming relies on open communication and mutual respect rather than ego or criticism.
Shared Goals and Learning Mindset: It is adamant to choose a partner who has a similar mindset of learning as yours. Pair programming is more than simply writing code together. It is also about learning from another person’s strengths and limitations. Working together to solve problems and besides growing as developers.

Pair programming is popular nowadays since it allows people to collaborate. They begin chatting for the sake of development, resulting in a greater bonding and understanding, which will help them solve more problem-related issues in the near future since they understand each other properly and know each other’s strong and weak areas.

Why Pair Programming is Necessary

The Role of Pair Programming

There can always be times that a feature needs to implement as soon as possible. We developers can work round the clock, push ourself to do the coding and deliver the features under tight deadlines. But how productive will it be if the work is done all alone? The code can have some technical flaws, hidden bugs and performance issues. After deploying the codes in production and after a few months if those issues arise solving them will be a real time killing job and will cost more time as well as effort.

Here pair programming comes as a savior. Pair programming doesn’t mean that to produce more code in a short passage of time. It’s not like if one person can do the job within a day, then with a pair partner the job will be finished within a half day. Pair programming is about knowledge sharing.

Enhancing Code Quality and Maintainability: The code should be easy to read and behave as expected. We need to bear in mind that about the next developer who will maintain the code. To do that one needs to pair with others so that the code should be as easy as it gets and there should always be fewer bugs and also behave as expected. The quality of code produced by two people is inherently more readable and maintainable because it benefits from the mutual understanding and scrutiny of both partners.
Collaborative Problem-Solving: When two people are thinking about the same problem, they bring diverse perspectives and ideas to the table. This collaborative approach leads to more robust solutions, as each partner can identify potential issues and improvements that the other might miss. This shared responsibility and combined expertise significantly reduce the likelihood of errors and enhance the overall quality of the code.

Pair Programming Template

Pair programming requires adhering to templates, which are rules to follow. If a template is not defined, pair programming is likely to fail. There are no hard and fast rules for following particular rules in pair programming; instead, the rules should be set by the pair partners and added based on mutual understanding. Here are some basic principles that a pair partner can follow, albeit it all depends on their attitudes.

Basic Principles for Pair Programming

Define the period of time.
Define a precise goal as what must be accomplished in that amount of time.
Define how often and for how long you will switch rules.
Track an alarm for both break and switch rules.
Every interruption during the pair programming should be disregarded.
Respect one other’s opinions and actively listen to one another.
Use collaboration tools.
Create a communication channel with your pair companion.
Review today’s session and make a schedule for the next one.

2. Ideal Length of Pair Programming Session

It is obvious that there will always be a deadline for a task . That does not mean that you have to work for hours with your companion. It is important to take breaks between works so that you may refocus your efforts and generate optimum solutions in an effective manner. As a result, setting time limits between sessions is important. However, there are no hard and fast regulations for a time restriction. It all depends on the pair partner. They should impose a time restriction of 30 minutes, 60 minutes, or something in between. After each session, pair partners should take a 5-15 minute rest, depending on their pair partner. Following the break, they should resume the session.

Pair programming is not intended to be used just to prolong the session. The goal is to make the session as beneficial and productive as possible. Smaller sessions are OK as long as they are fruitful. When one has more expertise with sessions, it becomes easier to have longer sessions that can last several hours. However, it is important to remember to shift responsibilities between sessions, regardless of their length. So that each pair mate can experience each position.

Taking breaks does not mean one is relaxing. Breaks provides an opportunity to give one’s partner time to reflect on its work. Addressing issues which he/she encounters and coming up with new ideas. A quick chit chat about anything which is not related to work or simply removing yourself from the computer screen can enhance creativity and problem solving skills. Breaks can also help to prevent burnout, which benefits both couples’ emotional and physical health.

Advantages of Pair Programming

The main advantage of the process is that while the navigator is navigating each and every line of code, this type of inspection enables the early detection of bugs before the code reviews and which saves more time. Some more advantages are:

Fewer Bugs : As an old saying says, two heads are better than one. As Two heads are working together there is always room that there should be fewer bugs than usual.
Focused Workflow: As two people are working together there should be more focus and attention to work than before. If someone loses focus there always will be one who will help to refocus.
Knowledge Sharing: When two people are thinking about the same problem and they will share their perspective regarding the problem resulting in sharing their point of view to each other.
Less Code Reviews: When two people are working together and one person is continuously navigating the code. So there are high chances that the bugs are identified at the first point resulting in most code reviews being done on the first part.
Code Quality: It also improves code quality as the patterns always tend to follow the industry best practices.
Minimize Your Stuckness: While working , one may naturally become stuck several times. In these situations, one may contact their partner for assistance. Additionally, the pair partner’s can identify when someone is heading in the wrong path and help them change course.
Enhancing Focus: Some developers find lonely programming a boring task as sometimes the developer can be out of focus. In that case the pair programming enables us to focus on the task completely as two people are actively participating on a single task. If any of the partners feels boredom or out of focus his/her pair partner should always try to keep him/her in focus and out of boredom which enables higher productivity than the usual lonely programming.
Continuous Learning: Engaging in pair programming allows developers to continuously learn from each other. Partners can share new techniques, tools, and insights, contributing to ongoing professional growth and development.

So pair programming unlocks more productivity, better collaboration, higher quality, better codes, and more sustainable development practices as well as personal growth.

Conclusion

Pair programming is a productive approach that has been utilized for years in the software development industry. It may enhance teamwork and information exchange, among other areas of your job. Naturally, there are some obstacles along the way, but even your first pairing sessions may be successful if you follow these couple programming principles.

Pair programming is something you should try with your team if you haven’t before. Additionally, be sure you read the instructions about getting started with pair programming if this is your first time. This will improve team communication, add enjoyment to your job, and, of course, write better code.

Case Study: Tackling a Complex Video Editing Feature Without Breaking Existing Functionality - Best Software Development Team Extension Partner for Nordics

Craftsmen Software Maestro — Wed, 12 Nov 2025 05:15:00 GMT

The feature under development is a complex video editing operation involving significant logical and computational challenges, as well as a high number of potential usage patterns. This complexity required careful consideration of numerous use cases and edge cases to ensure reliability and scalability in the codebase.

The Core Challenge: Preserving Stability Amid Ongoing Development

The central challenge was clear from the beginning: how to implement new functionality without compromising the reliability of existing features. The original system already handled between ten to fifteen distinct use cases, each containing unique combinations of media states, clip transitions, user interactions, and data persistence requirements.

Every new modification risked introducing regressions, breaking features that previously worked flawlessly. Early attempts showed how fragile the balance was. A new feature might fix one scenario while inadvertently causing issues in another. This constant push and pull made progress uncertain and forced the team to look for a more sustainable strategy.

Manual verification of all scenarios after each code change quickly proved to be unmanageable. With so many combinations of user actions, browser contexts, and temporal states to account for, testing everything by hand would have taken days after each iteration. This became a bottleneck, limiting the team’s ability to move forward with confidence and slowing down development velocity.

Strategic Approach: Automating for Confidence

To address this, a structured automated testing approach was introduced. Each new code addition was accompanied by comprehensive unit tests, including tests for boundary conditions.

This ensured that any regression was immediately detected, tests would pinpoint which case failed to meet expected outcomes. Maintaining parallel progress between production and test code allowed developers to iterate safely: if all tests passed, existing functionality remained intact, enabling focus on extending capabilities.

Equally important was the quality of the tests themselves. Tests were written to build genuine confidence in system behavior rather than to simply meet coverage metrics. Poorly designed tests may pass without providing assurance; meaningful tests reflect true system integrity and support reliable evolution of the code.

Outcome and Impact

The feature is now complete and has demonstrated substantial improvement in development confidence and agility. Automated test coverage provided a safety net for change, enabling faster iteration without fear of regressions.

Breaking the problem into smaller, testable units proved essential for managing complexity. The result was a system that could evolve steadily while maintaining a high degree of reliability.

Conclusion: From Reactive Debugging to Proactive Assurance

The successful implementation of this complex feature validated the effectiveness of embedding testing into the development process. Treating tests as an integral design component, rather than a final validation step, shifted the workflow from reactive debugging to proactive quality assurance.

The result is a resilient, maintainable, and confidently extensible system, one that meets its functional goals while reflecting strong engineering maturity and process discipline.

The Smart Way to Add Languages to Your Streaming Content (Without Breaking the Bank) - Best Software Development Team Extension Partner for Nordics

Mostaq Ahmed Polok — Mon, 23 Jun 2025 18:15:00 GMT

The Global Streaming Dream vs. The Costly Reality

In today’s hyper-connected world, streaming platforms dream of reaching global audiences. Viewers expect content in their language, and delivering that is no longer a luxury — it’s a necessity. But ask any video engineer about adding multiple languages to a large content library, and you’ll likely hear a sigh. Why? Because the traditional methods are often a budget-draining nightmare.

As a video engineer, I faced this challenge head-on. Expanding content globally meant dealing with the harsh reality of multiplying infrastructure costs.

The Old Way: Expensive, Slow, and Inefficient

Traditionally, adding a new audio track or subtitle set meant going back to square one:

Re-encoding: Processing the entire video file again for each new language.
Duplication: Generating and storing complete, separate sets of video segments for every language variant.
Storage Bloat: Paying to store visually identical video content over and over.
Manifest Mayhem: Juggling complex sets of separate manifest files for each version.

Imagine doing this for thousands of assets and ten different languages. The costs (storage, processing) and time commitment scale frighteningly fast, becoming a major bottleneck to global expansion.

“Adding languages traditionally meant re-encoding everything. For large libraries, costs spiraled out of control.”

A Smarter Approach: Dynamic Manifest Integration

I knew there had to be a better way. Instead of brute-forcing the problem, I looked at the elegance of modern streaming protocols like HLS and DASH. My solution leverages their flexibility through Dynamic Manifest Integration.

Think of a streaming manifest (like an HLS .m3u8 or a DASH .mpd file) as a detailed “playlist” or “table of contents” that tells the video player exactly where to find the video, audio, and subtitle segments it needs to play.

My approach cleverly modifies this playlist:

Keep One Video: I maintain just one high-quality set of video segments. No visual duplication!
Separate Audio/Subtitles: Audio tracks and subtitle files are processed and stored independently.
Update the Playlist: I dynamically update the manifest file to simply point to these external audio and subtitle components.
Seamless Experience: The player reads the updated manifest, presents the user with all available language options, and plays the correct combination using the same video stream.

How It Works: A Peek Under the Hood (HLS & DASH)

The magic lies in specific tags within the manifest files.

For HLS (HTTP Live Streaming):

I use #EXT-X-MEDIA tags within the main manifest to declare separate audio tracks and subtitles, linking them to their own small manifests or files.

Original HLS Manifest (Video Only — Simplified):

Integrated HLS Manifest (Video + Multiple Audio + Subtitles):

(Note: The URI points to separate HLS manifests containing only the audio or subtitle segments)

For DASH (Dynamic Adaptive Streaming over HTTP):

DASH uses <AdaptationSet> elements within the MPD (Media Presentation Description) file. We simply add new AdaptationSet blocks for each audio language and subtitle file.

Original DASH Manifest (Video Only — Simplified):

(Simplified) Integrated DASH Manifest (Video + Audio + Subtitles):

(Note: The BaseURL points directly to the segmented audio file or the complete subtitle file)

The Payoff: Real-World Wins

This isn’t just theoretical. Implementing dynamic integration yielded dramatic results:

Slash Storage Costs: I achieved over 90% reduction in storage costs for multilingual content compared to duplicating video files. For a 1-hour video, adding 10 languages traditionally could mean +36GB; My way adds only about +1GB. That’s a 72% saving just for the audio!
Lightning-Fast Updates: Adding new languages to a 5,000-asset library took under 2 hours, compared to an estimated 2 weeks using traditional re-encoding methods. Integrating just the new audio/subtitle tracks often takes less than 5 minutes per asset.
Simplified Operations: Language management is decoupled from video assets. Adding or removing languages becomes a simple manifest update, not a complex re-processing job. Troubleshooting is easier too.
Better User Experience: Viewers get the same high-quality video regardless of language choice, full control over language selection, and improved accessibility compliance.

“90% storage savings and updates in hours, not weeks? That’s the power of dynamic manifest integration.”

Tackling the Technical Hurdles

Of course, it wasn’t entirely straightforward. Key challenges included:

Path Resolution: Ensuring the manifest correctly points to audio/subtitle files, especially if they live in different storage locations than the video (e.g., calculating relative paths like ../audio/ENG.m3u8 correctly).
Language Tagging: Using consistent language codes (like ISO 639) and setting appropriate defaults for a smooth user experience.
Synchronization: Making sure audio and subtitles align perfectly with the video requires matching segment durations and timestamps precisely.
CDN Caching: Ensuring Content Delivery Networks (CDNs) pick up the updated manifests quickly after changes are made.

Careful implementation addressing these points is crucial for robust playback.

Conclusion: Work Smarter, Not Harder for Global Reach

Dynamic integration of audio and subtitles isn’t just a neat technical trick; it’s a fundamental shift in how we approach multilingual content delivery. By intelligently using the capabilities already built into HLS and DASH, we can bypass the costly and time-consuming process of re-encoding.

This approach directly translates technical efficiency into business agility. It allows streaming platforms to:

Expand globally much faster and more affordably.
Respond quickly to market demands for specific languages.
Offer a better, more inclusive experience to viewers worldwide.

For any platform serious about international scale, this dynamic manifest pattern offers a powerful alternative to traditional methods. It proves that sometimes, the most impactful innovation comes not from inventing new technologies, but from finding smarter, more efficient ways to use the standards we already have.

AWS Lambda integration testing with Python, Localstack, and Terraform

Mahabubur Rahaman Melon — Tue, 15 Apr 2025 18:00:00 GMT

To start with unit testing for AWS Lambda integration testing with Python, Localstack, and Terraform we can just choose a testing framework and start writing our beautiful unit tests. For testing AWS services we also can use some mock tools like moto. But what about integration testing? A solution may be to deploy with the Continuous Deployment tool and run some test code against real AWS services. But there are some problems:

It takes more time to deploy every time
Running test code against AWS takes more time
Increases the AWS bills

So one good solution could be using a local infrastructure that resembles the same as AWS real infrastructure. So here comes our friend Localstack to solve the problem. And today we will take a look at how we can use Localstack for integration testing of AWS Lambda.

Prerequisite

Python for lambda and test code
Terraform, an IaC tool to deploy lambda at the Localstack
Localstack to use AWS infrastructure locally
Docker, latest Localstack version needs docker to run.

Install python version greater than on equal 3.8, Terraform version 1.10.2 and latest docker.

The Skeleton

Install terraform version 1.8.2 from here on your local machine.

1. Create project directory

2. Create directory for lambda codes

3. Add handler.py file in lambda directory

4. Create directory for terraform

5. Add requirements file in project root directory

6. Create directory for test code

7. Create python file for test code

8. So the skeleton will look like this

Add requirements

Let’s add some python requirements in requirements.txt file

Make a python virtual environment named “venv”

Activate virtual environment and install necessary packages from requirements.txt file

Add Lambda Code

We will add a very simple code. Our lambda will just get the webpage https://example.com and return the page source as text.

Add Files to deploy Lambda

Let’s add a terraform variable for the lambda function name. So from our test code, we will provide the lambda function name and then test it to make the testing more dynamic. Add a file vars.tf in terraform dir and add following codes.

Now add terraform code for lambda at `terraform/lambda.tf`

Now we are going to add terraform/localstack.tf to which will tell terraform to use Localstack for deployment

Deploy to Localstack with Terraform

Now time to test deployment at LocalStack

Run command to start localstack in one terminal window

2. On another terminal run commands to test deployment. But this is only for testing and we are going to automate it in next steps.

Automate Test Code

Now time to automate the lambda testing. Our strategy:

Deploy terraform to LocalStack from test code e.g python code
Execute lambda using boto3
Check if we get the webpage as text
Destroy infrastructure with terraform to LocalStack using test code

Add terraform helper function at tests/terraform_helper.py which will responsible for creating infrastructure at test start and destroy after the test

Let’s add test code and we are going to use python’s unit test module to test our code

Finally, the project will look like this

Time to test the Test

Now come to the moment of playing 🎻

As we implemented the tests with the unit test module, we can run the test using

After a lot of logs we can see final output like this

⚠️ WARNING

Localstack is growing very faster. So if it works today may break tomorrow if the required packages are not fixed. So please try to fix all the packages version in Pipfile. Sometimes it may require some python packages to start various services like DynamoDB or StepFuntions. Add those at Pipfile accordingly.

Final codes

All of the codes are in this GitHub repository:

https://github.com/melon-ruet/lambda-testing-localstack

Mastering Sorting Techniques in DynamoDB: From Chaos to Clarity - Best Software Development Team Extension Partner for Nordics

Shahed Chy Suzan — Wed, 09 Apr 2025 18:15:00 GMT

Amazon DynamoDB is a highly efficient, scalable, and low-latency NoSQL database service, ideal for managing large data volumes and high traffic loads. Its robust architecture and single table design principle ensure exceptional performance and reliability which makes DynamoDB a top choice for numerous applications.

With great power comes great responsibility, hence one of the key challenges developers often experience while working with DynamoDB is implementing efficient sorting strategies, which can have a major effect on how well data is retrieved.

In this blog I will cover fundamental principles, advanced mechanism, and practical advice for turning chaotic data into orderly resources.

Sort Key in DynamoDB:

DynamoDB supports two kinds of primary keys: the partition key and the composite primary key. A partition key(aka hash key) is a single attribute, while a composite primary key includes a combination of 2 attributes: ‘hash key’ and ‘sort key’.

DynamoDB uses the partition key value as input to the hash function. The output from the hashing function determines which partition the item will be placed in. A sort key is also referred to as a range attribute of an item and used to arrange and organize items in a partition. It is possible that many items will have the same value for a partition key; however, they must have different values for sort keys.

By default the Items in DynamoDB partitions are ordered by sort key in ascending order. A well defined sort key provides the capability to query dynamoDB tables by using the conditions expression.

The Sort key cannot be changed after table provisioning, Therefore be mindful when creating a sort key. If your data contains hierarchical (one-to-many) relationships and you want to query at any hierarchy level, use a composite primary key.

For example, The sort key for a restaurant DDB table can be structured as follows.

Here ‘chain’ means company name of the restaurant.

Here, the sort key allows for efficient range queries for locations at various levels of aggregation, from ‘chain’ to ‘area’, and everything in between. By defining sort key as above we can query table with more granularity, like if we want to get data for a specific ‘chain’ then we can query with sortkey begins_with chain# , similarly if we want to get data for any specific ‘country’ we can query the table like sortkey begins_with chain#country.

Points to consider for Sort Key:

The sort key attribute must be a scaler type.
It should be noted that within a partition, sort key has to be unique meaning that there ought to be no other item with the same partition key as well as the same sort key.
Sort key names can’t be a reserved words. You can see the reserve list in the dynamoDB documentation here.
The length of the sort key attribute should not exceed 255 characters.
Sort keys should follow DynamoDb’s naming conventions for attributes.
Name your Sort Key Attribute something meaningful and descriptive that reflects the type of data it is holding so that when you make queries, they will make more sense and help in faster execution.

Diving Deeper: Sorting Mechanism in DynamoDB

The most fundamental sorting strategy in DynamoDB involves using the sort key of your table’s primary key. If you define a composite primary key with partition key + sort key, DynamoDB will store items inside every partition automatically in ascending order of the sort key.

Here are two main rules you will need to get into the habit of following if you need any kind of specific ordering when reading multiple items in DynamoDB.

You’re going to have to use composite primary keys first.
Second, ordering must be done with the sort key of a certain item collection.

DynamoDB uses the partition key to isolate item collections into different partitions. This then supports O(1) lookup time to find the proper node. Afterward, items inside an item collection are stored as a B-tree to allow O(log n) time complexity in search. This B-tree is arranged in lexicographical order according to the sort key and forms what is used for sorting.

In this blog I will delve into the following sorting mechanism:

Basics of sorting:

1. 1. Lexicographical sorting mechanism.
  2. Sorting with Timestamps, how to handle timestamps,
  3. Unique, sortable IDs (unique identifiers that still need sorted chronologically).

Sorting on changing attributes

Ascending vs. Descending sorting

Two relational access patterns in a single item collection

Zero-padding with numbers

Faking ascending order

Let’s get started, there’s a lot to discuss!

1. Basics of sorting:

Sorting is done in DynamoDB only based on the sort key which can be a scalar types such as: string, number or binary. This implies that we do not need to consider how a map attribute will be sorted by DynamoDB.

In cases where sort keys are numbers, they are directly ordered according to their numerical values. However, for sort keys of type strings or binaries, items are arranged based on the order of UTF-8 bytes. Now let’s examine this more closely.

1.1. Lexicographical sorting:

A simplified version of sorting on UTF-8 bytes is to say the ordering is lexicographical. Lexicographical sorting, also known as dictionary or alphabetical order, It is the default method of sorting strings in DynamoDB. Strings are compared character by character in this method based on their Unicode values.

To determine what character comes after which, consider the sequence written below:

Symbols(e.g. # or $) and Numbers (0-9) come before uppercase letters.
Uppercase letters (A-Z) come before lowercase letters.
Lowercase letters (a-z) come last.

Notice that these letters are separated by case (first capital letters and afterwards lowercase). This means “Banana” will come before “apple”. That is crucial to be aware of if you want to avoid surprises later.

Here’s an example table demonstrating the lexicographical ordering of various characters based on their UTF-8 values(dec):

I’m refering to this page for a complete list of UTF-8 characters including special ones sorted according to their bytes order.

Example of a lexicographical sorting with Uppercase Rule:

A common mistake people make with lexicographical ordering is forgetting the uppercase rule. For instance, consider an item collection with names “Ellen VanDyke” (with a capital “D” in the middle of VanDyke), ‘Alice Vanbyke’ and ‘Bob Vanhoten’, In an item collection using these last names as SK. it might turn out as follows:

You might be surprised to see that ‘VanDyke’ came before ‘Vanbyke’! This is due to the casing uppercase before lowercase. To avoid odd behavior around this, standardize your sort keys to either all uppercase or all lowercase values:

Here, when all last names are in uppercase, they are sorted as expected.

1.2. Sorting with Timestamps:

Regarding sorting, the second fundamental issue I want to mention is how to go about timestamps. First and foremost, your choice must be such that it can be sorted. What you definitely cannot do is use a non-sortable format like “May 26, 1988”. This will not sort in DynamoDB and you will have some painful moments there.

Personally, I prefer to use ISO 8601 format: “YYYY-MM-DDTHH:MM:SSZ”. Because this format is human-readable and it also follow lexicographical order.

This ISO 8601 format is universally recognized standard used in many countries across the globe for showing dates-times (e.g., “2023-05-15T10:30:00Z”). It consists of year, month, day, hour, minutes, seconds, and then Z suffix indicating UTC timezone.

Eg: “2023-07-10T14:48:00Z” which will properly sort before “2023-07-11T15:00:00Z”.

1.2. Unique, sortable IDs:

An often encountered requirement is to have unique IDs that can be sorted. This mostly comes where you need an item with a unique identifier (preferably URL friendly) but you still want them ordered by date or time created. In this arena, there are several options but ‘KSUID’ implementation stands out for me.

KSUID means K Sortable Unique Identifier. Simply, it’s an identification number that begins with a timestamp and has enough randomness to minimize the possibility of overlapping values. On the whole this gives you a 27-character string, which is better than any UUIDv4 but yet achieves lexicographical sortability.

For more check out Rick’s blog post on the implementation of KSUIDs.

2. Sorting on changing attributes:

DynamoDB uses the sort key to sort items within a collection, useful for displaying recently stored items or top scores. However, sorting based on frequently changing values can be challenging. For example, consider a ticket tracker app might allow users to view tickets in order by most recently updated.

Let’s imagine you decide to model your table as follows:

This database design uses the organization name as a partition key for ‘group by’ functionality and sorting tickets with the ‘UpdatedAt’ field as a sort key for order. However, this design has limitations, as the primary key cannot be changed during item modification. In your case, you have included ‘UpdatedAt’ field into the primary key which changes each time a ticket is updated. So whenever you update a ticket item, first delete the existing ticket item, and then create another new one with updated primary key. causing a complicated process and potential data loss if not handled properly.

However, I’m thinking maybe we can do things differently here. For our primaryKey, let’s give two attributes that will not change anything at all. We’ll keep ‘OrganizationName’ as partition key but switch to using ‘TicketId’ as sort key instead.

So, here is how our table looks like now.

At this point, we can also add local secondary index which has a secondary sort key known as ‘UpdatedAt’. The information contained in the base table gets copied into the secondary index and appears as shown:

Note that this was exactly how our original table design used to be. Consequently, we can use the Query API against this secondary index to satisfy our ‘Fetch most recently updated tickets’ access pattern. Significantly, there is no need for us to worry about complex delete + create logic while trying to update an item because DynamoDB takes care of all this when replicating data into secondary index.

3. Ascending vs. Descending sorting:

We know DynamoDB by default reads the items in ascending order. By employing ‘ScanIndexForward=False’ you will be reading them in descending order. This is useful in many cases such as when you want the most recent timestamps or check highest score on a leaderboard.

But it becomes complex if you combine different entity types into a single item collection and then try to read them back together with a parent object for establishing a one-to-many relationship between parent and child entities. In that situation you need to consider the common sort order you’ll use in this access pattern to know where to place the parent item.

For example, let’s assume a library system where users often want to access a book with the latest 10 review items.

You could structure your table as shown below:

Here according to the table data our query retrieves the oldest Book and Review items, but if the collection is large, multiple pagination requests may be needed to fetch recent ones. To avoid this, you can prefix our Review items with ‘#‘. After doing that, our table will appear as:

So now if we use ‘ScanIndexForward=False‘ our Query API will retrieve recent Review Items for each Book item starting from the last item in a collection.

4. Two relational access patterns in a single item collection:

Let’s take this example if we can have a one-to-many relationship where the related items are before or after the parent items, can we do both in one item collection?

Yeah, sure! To achieve this you need to have two access patterns: one fetching related items in ascending order and another in descending order.

To give an illustration, consider a SaaS application where an organization has two sub-concepts: Employees and Teams, each with a one-to-many relationship with the organization.

You could think of each of these relationships as having a relational access pattern ‘Fetch Organization and all {Employees|Teams} for the Organization’. Additionally, you would want Employees returned sorted by their names but not care how Teams are sorted because there shouldn’t be too many of them.

You could model your table as follows:

This above table contains three types of items: Team, Org, and Employee. Each item has same PK value of ORG#, with Team items bearing SK #TEAM#, Org items bearing SK ORG#, and Employee items bearing SK EMPLOYEE#. Here, the Org item is positioned between Team and Employee items, with the Team item preceding the Org item, The structure of our item collection was designed with a ‘#’ prefix, ensuring Team item precedes Org item.

Now we can query for all team items as well as org:

This process searches our partition, identify items less than or equal to the sort key value for our Org item, and then scans backward to retrieve all Team items.

Below is an image showing how it works on the table:

Alternatively you could do the reverse to fetch both Org item and Employee items, look for items greater than or equal to our Org item sort key and read forward to retrieve all Employee items from your table.

This is a very advanced pattern that doesn’t necessarily mean you must use it but it will eliminate more additional secondary indexes from your table.

5. Zero-padding with numbers:

One should be aware of lexicographic sorting with numbers represented as strings. For better demonstration. Let’s revisite our above ‘Book Review’ example and now we are using ‘RatingNumber’ instead of timestamps for the sort key.

You can have a table that looks like this:

Here, the rating order is incorrect, 10 is being placed before 2 due to lexicographic sorting. one character at a time is compared from the left towards right. When it compares ’10’ and ‘2’, the first digit(‘1’) in 10 comes before the first digit(‘2’) in 2, so 10 came before 2.

To avoid this, you can zero-pad your numbers—make sure that your sort key has a fixed length such as three digits in this case. When you find that your value does not contain many digits, you append with a ‘0’. Therefore, It will turn “10” into “010”, and “2” into “002”.

Now, this is how our table looks like:

This means that RatingNumber 2 comes before RatingNumber 10 as expected. However, the main thing here involves you having the padding about to accommodate any increase. In this case, we had a fixed width of three digits thus reaching Rating number 999. Make your fixed length longer if your requirements are greater than that.

6. Faking ascending order:

Let’s revisite our above example of zero-padding with numbers. Now retrieve reviews in ascending order by the book name according to their rating, So here i am going to implement a technique to fake ascending order by transforming the sort key.

We’ll modify the SK into a FakeRating for efficient querying in ascending order. To fake ascending order, we can invert the ratings by subtracting each rating from a constant value (e.g., 100), then zero-pad the result to ensure lexicographical sorting,

That means, FakeRating = (100 – ActualRating) and then convert it to a zero-padded string.

For example, imagine we were again using a zero-padded number with a width of 3. If we had an item with an ratingID of “10”, the zeropadded number would be “010”. To find the zero-padded difference, we subtract our number (“10”) from the highest possible value (“999”). Thus, the zero-padded difference would be “989”

If we put this in our table and query with ‘ScanIndexForward=False’ you would get:

This strategy may appear unconventional and may not be necessary in practice. The most important lesson to learn from this approach is how versatile DynamoDB can be if you combine multiple strategies. Once you grasp the basics, you may put them together in unique ways to solve your problem.

Conclusion:

When dealing with data management in DynamoDB, sorting is one of the core functions that decides how fast information can be retrieved. By understanding these above discussed sorting mechanism will help you optimize your DynamoDB tables for many difficult use cases so that you can maintain correct order and clearness in your data.

From basic lexicographic ordering to advanced mechanism like zero-padding and faking ascending order, acquiring expertise in them will help you take advantage all the potentialities of DynamoDB. As your data grows and application scales, these sorting techniques will ensure your queries remain fast and efficient, keeping your data access organized and performant.

Thinking in React: Component-Based Architecture

Ebrahim Ali — Mon, 17 Mar 2025 18:00:00 GMT

React has revolutionized web development by giving developers a powerful tool for creating dynamic, responsive user experiences. The founding principle of React is its component-based architecture, which divides complicated user interfaces into smaller, reusable parts known as components. This simplifies code maintenance and reading, as well as helps in the development of scalable systems. In this blog, we will look at component-based architecture ideas and demonstrate how to apply them to the development of a React application.

What is Component-Based Architecture?

A component-based architecture is an approach rather than a technique for developing UI whereby the UI is built by splitting it into reusable fragments called components. Each component is assigned to handle a particular feature or part of the user interface thus making the application easier to maintain and extend. The main ideas behind this architecture are:

Reusability: Components can be utilized in numerous places across the application, which helps to avoid writing the same code numerous times. For example, a button component designed for a form can be utilized in a pop-up or another portion of the app.
Encapsulation: Components handle their own state and behavior, which enhances modularity. Each component has a clear interface and can be built, tested, and maintained independently.
Separation of Concerns: Each component concentrates on a single task or function, which leads to cleaner and more manageable code. This separation enables developers to understand and work on each component of the application independently.

Benefits of Component-Based Architecture

Improved Code Maintainability

Smaller, self-contained components are easier to manage and update.
When a bug is found or a new feature is needed, developers can easily find and fix the specific component without searching through a lot of code.

Enhanced Collaboration

Teams can work on different components at the same time without causing conflicts.
This speeds up the overall project timeline and makes better use of team resources.

Scalability

Adding new features or changing existing ones is simpler with a modular component structure.
As the application grows, developers can build new components or change existing ones without affecting other parts of the application.

Aspect	Traditional Monolithic Architecture	Component-Based Architecture
Codebase	One large, unified codebase	Broken down into smaller, independent components
Scalability	Difficult to manage and scale as the application grows	Easier to scale by adding or modifying individual components
Impact of Changes	Changes in the UI can affect the entire application	Changes in one component typically don’t impact others
Development Efficiency	Slower, as changes require careful consideration of the entire system	Faster, as developers can work on isolated components
Risk of Bugs	Higher risk, as changes in one area can cause bugs in another	Lower risk, as components are independent and self-contained

Core Concepts of React Components

Understanding Components and Props

Components are the building blocks of a React application. Consider them as JavaScript functions that return HTML. Props (short for properties) are used to transfer data from one component to another, enabling dynamic content rendering.

An example of a basic functioning component with props:

State and Lifecycle

React comes with a built-in object called State that lets components handle their own data. To keep the user interface (UI) up to date with the data, state changes cause re-renders.

Example of a component with state:

Creating a React Application

Prerequisites

Before building a React application, ensure you have the following:

Node.js & npm installed on your system. You can check by running:

Basic understanding of JavaScript and ES6+ features & familiarity with React components (covered in the previous section).

Once you have these in place, you’re ready to go.

Setting up a React Project

Use Create React App to start a new React app:

Structuring the Project

Configure your project using a well-defined folder structure:

Building a Todo List Application

Creating and Organizing Components

In this section, we will develop a simple Todo List application, which will include three key components:

TodoItem: Represents an individual todo item.
TodoList: Displays a list of todo items.
TodoForm: Contains a form to add new todo items.

TodoItem Component: The TodoItem component will receive a todo object as a prop and display its content.

TodoList Component: The TodoList component will render a list of TodoItem components. It will receive an array of todos as a prop.

TodoForm Component: The TodoForm component will manage the input for adding new todos. It will use local state to keep track of the input value.

Managing State and Props Between Components

We now have to manage the application’s whole state within the App component. This component will contain the todos array and the function for adding new todos.

Best Practices for Component-Based Architecture in React

To maintain your application easy to handle and grow, use these recommended practices:
Single Responsibility Principle: Each component should be capable of performing a single task well. This facilitates understanding, testing, and maintenance. For example, the TodoItem component displays a single todo, whereas the TodoForm component handles input and submission.
Reusability and Modularity: Create components that can be used in multiple places throughout your app. This reduces duplicate code and makes maintenance easier. For example, you could design a Button component that can be utilized in different forms in all around the application.
Proper State Management

Lifting State Up: Place the state to the nearest common parent of the components that require it. This allows components to communicate more effectively and avoids passing props down multiple tiers.
Context API: To handle the global state without having to use prop drilling, use the Context API. This is especially useful in larger projects with multiple nested components.

Using Hooks for Functional Components: React hooks such as useState and useEffect enable functional components to manage state and lifecycle methods. As a result, managing complicated logic without the need for class components is made easier for functional components.

Refactoring the Todo List Application for Better Practices

To improve our Todo List application, we may develop a separate Button component for reuse:

TodoForm‘s button can now be replaced with our Button component:

Advanced Component Patterns

Higher-Order Components (HOCs)

Functions known as HOCs accept a component and return a new one. This allows for the reuse of component logic, such as authentication checks or data fetching.

Render Props

Render Props is a mechanism for exchanging code between React components, utilizing a prop whose value is a function. This provides additional flexibility in component rendering.

Compound Components

Compound components enable you to design a collection of components that interact to form a complicated UI element. This pattern allows you to encapsulate shared functionality while providing users with a simple API.

Example of Compound Components:

Testing React Components

Why Testing Matters in Component-Based Architecture
Testing helps to confirm that your components are functioning properly. It also makes it easier to change the code with assurance. A well-tested app has fewer bugs and problems, which speeds up development.

Tools and Libraries for Testing

Jest: A popular testing tool for React that offers many features for testing JavaScript apps.
React Testing Library: A library designed for testing React components, focusing on how users interact with them.

Writing Unit Tests for Components

When you write unit tests, focus on how individual components behave instead of how they are built. This makes your tests stronger against changes in the component design.

Testing the Todo List Application Components

Here’s an example of a unit test for the TodoForm component to ensure it correctly adds a new todo:

Running Tests

To run the tests, you can use the following command:

This command will execute all the tests in your application and provide feedback on their results.

Conclusion

Component-based architecture in React is a great way to build apps that are easy to scale and maintain. By following the ideas and best practices in this blog, you can make strong React apps that are simple to manage and grow.

In this post, we looked at key ideas about React components, like props, state, and lifecycle methods. We built a basic Todo List app to show how to set up components and handle state well. We also talked about advanced methods like Higher-Order Components, Render Props, and Compound Components to improve your component design.

Finally, we discussed the necessity of testing in component-based programming and demonstrated how to construct unit tests for your components. By implementing these techniques in your React projects, you’ll be prepared to tackle complex apps with confidence.

Code Quality Matters: Understanding Smells and Heuristics in Code - Best Software Development Team Extension Partner for Nordics

Omor Faruk Rakib — Wed, 12 Mar 2025 18:00:00 GMT

Introduction

In the world of software development, the quality of your code plays a huge role in how successful your projects will be. Code quality isn’t just about making sure the code works—it’s about ensuring that it’s clean, readable, and easy to modify as your project grows. When code quality is poor, it can lead to many problems that slow down development, make bugs harder to fix, and cause a lot of frustration for everyone involved.

Why Code Quality Matters (Good code vs Bad code)

Good code quality isn’t a luxury—it’s a necessity. When your code is clean and tidy, you spare yourself a great deal of unnecessary agony later. On the other hand, poor code quality can cripple your project in ways you may not even realize.

Here’s why good code matters and what happens when you ignore it:

1. Ease of Maintenance vs. Technical Debt

Good Code: With great code, everything is organized in such a manner that somebody else would be able to modify the code with ease. In addition, new features may be added with zero repercussions.
Bad Code: When poor code is exhibited, it results in something called technical debt, where a quick fix creates a far bigger issue down the line. The more code is haphazardly organized, the more difficult it is to maintain.

Example:
Say you write a function that applies a discount, rather than having a centralized logic, you decide to duplicate and keep the discount logic in multiple files. Now, whenever any changes need to be made to the discount logic, you have to track down all copies and clones. And if you miss one, boom—bugs!

2. Fewer Bugs vs. Hard-to-Find Errors

Good Code: There are fewer chances that the good code contains hidden bugs.
Bad Code: If a code looks unstructured and messy, it means finding errors in the code would be near impossible.

Example:
If another programmer, or even yourself from the future, comes back and sees a variable x, it will not be immediately clear what that value is meant to portray, and therefore the programmer wastes a lot of time deciphering the meaning and purpose for x. On the other hand, using good variable names like totalAmount can eliminate such situations.

3. Better Team Collaboration vs. Developer Frustration

Good Code: A cohesive code style means manageably understand what has been written and one understands what parts of the code they can make contributions to.
Bad Code: Poorly arranged code adds more confusion to an already complex structure, wasting time while pouring huge amounts of irritation.

Example:
If two developers write similar functions with different naming styles—one calls it fetchUserData(), another calls it getUserInfo()—it creates unnecessary confusion.

4. Scalability vs. Rigid, Hard-to-Modify Code

Good Code: Well design code is capable of expanding without becoming an overly confusing assortment of parts.
Bad Code: Poor design choices early on make future expansion painful.

Example:
There is no need to have one massive function that is responsible for everything. If you break tasks to smaller modular functions, your overall coding structure becomes easier to work with.

5. Performance Optimization vs. Slow, Inefficient Code

Good Code: Code that is clean and devoid of unnecessary statements executes perfectly and optimally.
Bad Code: Careless code causes unnecessary constraints on the effectiveness with which a computer system functions.

Example:
When an O(n) solution is available, an O(n²) loop will needlessly hinder the performance of your application. Realizing that writing efficient code from the beginning allows one to have a much easier experience down the road.

Understanding Code Smells: A Key Indicator of Code Quality

One of the ways to measure and assess the quality of your code is by looking for “code smells.” While a code smell doesn’t always mean the code is broken, it suggests that the code might need to be cleaned up or refactored to improve its quality.

What is a Code Smell?

A code smell is any characteristic in your code that could indicate a deeper problem. These are usually easy to spot, even if you didn’t write the code yourself. Code smells act as a warning sign, letting you know that there might be areas in your code that need attention. They aren’t bugs—the code still works—but they point to places where the code could be improved.

Case Study: A Messy User Registration System

Imagine a system where new users are registered, their details are validated, their email is verified, and they are assigned roles based on their account type. Below is the function handling this process:

This function works, but it is full of code smells. Let’s break down the problems using this example:

Long Methods: When you find a method that is unnecessarily long, that’s usually a code smell. The above function is doing too many things:

Validating passwords
Checking email format
Verifying the user’s age
Storing user data
Sending notifications

This makes the function difficult to read and maintain.

2. Too Many Parameters: If you have a function that requires five or more parameters, it’s likely a code smell. The above function takes 10 parameters (name, email, password, confirmPassword, age, phone, address, accountType, notifyAdmin, sendWelcomeEmail). Passing this many parameters is confusing and makes the function hard to use.

3. Duplicated Code: Duplicating code in multiple places is a clear sign of a code smell. The function manually checks if password !== confirmPassword and then separately checks if email.includes(“@”) && email.includes(“.”). If these validations are needed elsewhere in the system, they will have to be duplicated.

4. Feature Envy: This occurs when a method in one class spends too much time interacting with the data of another class. In practice, this could lead to tight coupling between classes, making it difficult to change or extend the code without affecting other parts of the system. For example the above function interacts too much with unrelated concerns:

It decides when to notify an admin.
It sends a welcome email.
It stores user information in the database.
It performs multiple types of validation.

These tasks should belong to different parts of the system.

5. Dead Code: Dead code refers to code that is never executed but still exists in the codebase. For example: If the notifyAdmin and sendWelcomeEmail flags are set to false, the related code does nothing. This conditional logic adds unnecessary complexity.

6. Inconsistent Naming: Consistency in naming is crucial for code readability. When similar things are named differently or different things are named similarly, it leads to confusion and makes the code harder to understand. For example, The function uses notifyAdmin, but sendWelcomeEmail instead of notifyUser. Naming inconsistencies like this make the code harder to understand.

7. Obvious Behavior Is Unimplemented: Functions should do what their names suggest. If a function’s name implies behavior that isn’t implemented, it creates a code smell. For example, the function registerUser implies it will create a new user, but it doesn’t explicitly return the user object. Instead, it just prints a message.

8. Obsolete Comment: A comment that is outdated or no longer relevant is a code smell. Comments should provide value by explaining why something is done, not just what is done. When a comment becomes obsolete, it can mislead developers, making it harder to understand the current state of the code. For example: the function contains a comment // It checks age limit up to 18 . and if someone changes the logic without updating the comment, it will create confusion.

9. Vertical Separation: Variables and functions should be defined close to where they are used. A variable that is declared far from its usage or a private function defined far from its first invocation creates a smell, making the code harder to read and maintain.
For example: the function jumps between unrelated concerns (validation → database storage → notifications), making it harder to follow.

10.Too Much Information: Exposing too many details, such as internal variables or methods, in a class interface leads to high coupling and low cohesion. This makes the class difficult to use and maintain. For instance, the function is directly handling how user data is stored, validated, and processed. A better approach would be to delegate these tasks to different modules.

11. Magic Numbers: Hardcoding literal numbers or strings in your code, instead of using named constants, is a common code smell. For example, the function hardcodes the age limit (18). It should instead use a named constant, like MINIMUM_AGE.

This list includes some of the most common code smells, but it’s not exhaustive. There are many other potential issues that could arise in your codebase.

The Impact of Code Smells

If you ignore code smells, you can run into several problems:

Increased Complexity: As code smells accumulate, the codebase becomes more complex and difficult to work with. This complexity can lead to mistakes, as developers struggle to understand how different parts of the code interact.
Reduced Readability: Code smells make your code harder to read, which in turn makes it harder to maintain. If the code is difficult to understand, new developers joining the project will have a hard time getting up to speed, leading to longer onboarding times and more errors.
Lower Flexibility: Smelly code is harder to modify or extend. Adding new features or making changes becomes risky because the existing code is so tightly coupled or disorganized.
Higher Risk of Bugs: Because smelly code is harder to understand, it’s easier to overlook potential issues, leading to bugs that can be difficult to track down and fix.

Code Quality: The Gap Between Academic Learning and Real-World Development

When we start to learn how to code either at a university or self taught, the first thing that we try to accomplish is learning how to solve problems in the best way possible. During these times, we tend to work alone or in small teams with little to no collaboration, and we try to get the code to do what we want in the shortest time possible. The problem with having this approach is that the code which is produced is often problematic as it may solve the problem but is not readable, maintainable, nor scalable. Because during one’s education, collaboration and following quality code standards are often lacking, this is the type of code students often produce. This tends to change during the transition to real world software development. Setting becomes heavily results-oriented in the sense that writing code which works is not enough, it involves writing code which is understandable, modifiable, and extendable to other developers. With the expectation that the code will eventually be worked on by several developers over time, new requirements arise which shift focus to cleanliness, organization, and scalability of the code. This is when developers understand the weight of code quality and the standards that are expected. The challenge in functioning on a professional level still persists amongst many developers even after they have mastered the ability to write code..

Grasping the importance of code quality and learning how to identify and fix code smells is critical for any developer attempting to be successful in the real world of software engineering. It is not enough to simply write functioning code; one must consider its longevity and how easily it can be comprehended and maintained by others.

Heuristics: Tools for Identifying and Fixing Code Smells

Heuristics are practical guidelines that can help you identify and address code smells. They provide a framework for evaluating your code and making decisions about when and how to refactor it.

Key Heuristics for Identifying Code Smells

Keep Functions Small: This heuristic recommends that every function must do one thing. The functions must indeed be separated logically, if only to make it easier to understand, test and maintain the code. For example, you may have a function that validates data, processes, and produces output. It is easier to maintain if each task has its own function.
Prefer Composition Over Inheritance: In object-oriented programming, this heuristic suggests that it’s often better to compose objects using smaller, more focused classes rather than relying heavily on inheritance. This approach makes the code more flexible and easier to refactor.
Avoid Global Variables: Since global variables are accessible from anywhere in the code, they can produce strange results and make debugging difficult. Local variables or encapsulated state within objects are much better options, since they reduce dependencies.
Refactor Often: When you refactor your code regularly, it stays clean and does not accumulate too much technical debt. Everyone knows that code always has room for improvement, and as you make these improvements, you make sure that code smells do not develop.
Write Tests First: Writing tests before you write your code ensures that your code is testable and encourages good design practices. Tests help catch potential problems early, reducing the risk of introducing new code smells.

Real-Life Example: Identifying and Fixing Code Smells

While we can’t cover every possible scenario, let’s explore a couple of common cases to see how code smells can be identified and addressed through refactoring, all within the context of real-world development.

The Problematic Code

Here’s a piece of code written in javascript that has several code smells:

Code Smells:

Long Method: The processOrder function is doing too many things—calculating shipping, applying discounts, processing payments, and updating the order status.
Too Many Parameters: The function takes six parameters, making it hard to understand and use.
Feature Envy: The function accesses multiple details about the order and customerType objects, which could be encapsulated within their respective classes.
Flag Arguments: The use of Boolean flags like isExpress suggests that the function is doing multiple tasks, which should be split into separate functions.

Refactored Code:

Here’s how the javascript code could be refactored to address these smells:

Improvements Made:

Smaller Functions: The original processOrder function has been broken down into smaller, more manageable and specific functions that accomplish one task each making it easier to add new functions without changing the existing ones.
Reduced Parameters: Merging correlated data into objects, like customer and order, has also yielded a reduction in the number of parameters to be set.
Removed Flag Arguments: The parameter isExpress of the main function has been omitted as it is a flag and is now being handled in the calculateShipping function.
Encapsulation: The applyDiscount and processPayment functions now encapsulate details about the customer and payment methods, reducing the need for external code to manipulate these details.

Conclusion

The quality of code is important in building software that is maintainable, scalable, and dependable. Resolving and understanding the issue of code smells is a fundamental part to make sure that your codebase is both clean and functional. Being able to identify bad code and having rules of thumb for how to make improvements will make it easier for you to prevent a lot of future issues.

You shouldn’t let code smells turn into more serious problems. By addressing them early, you’ll create a codebase that is not only functional but also a pleasure to maintain and build upon. Better code means better software, happier developers, and successful projects.

Elegance in Databases: The Art of SQL vs NoSQL - Best Software Development Team Extension Partner for Nordics

Foisal Reza — Tue, 04 Mar 2025 18:00:00 GMT

Database, the center point of each application, plays a crucial role as data is always needed to execute a project and must be stored in some fashion. As applications grow in complexity and scale, the process of storing and managing data becomes more difficult.

When it comes to storing and managing data, developers face the challenging decision of choosing between traditional SQL databases or modern NoSQL databases. This comparison—SQL vs NoSQL—highlights their unique strengths, weaknesses, and ideal use cases, making the decision even more daunting.

In this blog, we will dive into the art of SQL vs NoSQL, comparing their features, examining their suitability for different scenarios, and understanding the principles that help us choose between the two. For this exploration, we benchmark one popular SQL database, PostgreSQL, and a leading NoSQL database, DynamoDB.

What is Postgresql?

PostgreSQL is an open source rdbms(relational database management system) which evolved from the ingres project in the university of california. It follows the traditional ACID (Atomicity, Consistency, Isolation, Durability) properties, making it highly reliable and suitable for various applications.

What is DynamoDB?

DynamoDB is on the other hand one of fastest growing modern NoSQL databases which is fully managed by AWS(Amazon Web Services) and follows the single table design pattern. It is designed to handle high volumes of unstructured and schemaless data and traffic. It automatically scales up or down according to the workload.

Design Patterns

Postgresql

ACID Properties: It follows the basic acid properties which a must have for sql databases. Atomicity ensures either a transaction will commit or not and there is no in between. Consistency ensures data should remain consistent no matter from where the query comes from. Isolation ensures only one person can write into the database in a single point of time and finally, durability ensures committed data will persist throughout the time.
Schema Based Design: It uses a structured schema with different tables. Each table has a primary key(unique identifier) and is connected to another table through a foreign key. It has also join operations to combine two tables to fetch data as well as indexing to fetch data quickly.

Here is a sample table design in postgresql where CustomerID is defined as primary key in the Customers table and as far as the Orders table is concern OrderId is the primary key and CustomerID is the foreign key which is outlined in red as how the both table are being connected

3. Indexing: In SQL also in Postgresql uses different types of indexing to retrieve the data faster as the data grows and traditional sql databases tend to slow it down as the query uses sequential searches. So indexing comes as a savior as it uses B-tree to speed up the search.

4. Normalization: Organize data into related tables to reduce data redundancy. There are various types of normalization like 1NF, 2NF,3NF. This process involves large tables divided into smaller ones and multiple ones ensuring each table focuses on one topic. For example let us consider a table order table has the following items

Order table
Order_id	Customer_id	Order_date	Product_id
1	101	12-11-2003	1,2
2	102	12-11-2003	3,4

As we can see the product_id column holds multiple entries which violates the idea of normalization. As normalization states that each column should hold data atomic we need to break down the table into two and introduce order_items table and new table should look like as follows

Order table
Order_id	Customer_id	Order_date
1	101	12-11-2003
2	102	12-11-2003

Order items table
Item_id	Order_id	Product_id	Quantity
1	1	1	2
2	1	2	3
3	2	3	4
4	2	4	5

Here we saw the basic operation on normalization which breaks the initial two tables into two and this is called 1NF. However the tables can be further normalized and in order to retrieve data we might need join operation

5. Aggregation: SQL aggregation functions are used to perform calculations on multiple rows of a table’s column and return a single value. Common aggregate functions include SUM, which adds up all values in a column; AVG, which calculates the average; COUNT, which counts the number of rows; MAX, which finds the highest value; and MIN, which finds the lowest value. These functions are often used with the GROUP BY clause to group rows sharing a common attribute and apply the aggregate function to each group. For example, SELECT department, COUNT(*) FROM employees GROUP BY department counts employees in each department.

6. OLAP: OLAP (Online Analytical Processing) in SQL is a powerful data analysis approach used for complex querying and reporting. It enables users to perform multidimensional analysis of large datasets stored in data warehouses. OLAP operations include slicing, dicing, drilling down, and pivoting to view data from different perspectives. SQL-based OLAP leverages aggregate functions, groupings, and hierarchical data structures to provide insights into business metrics. For example, a retail company can analyze sales data by product, region, and time. OLAP enhances decision-making by allowing interactive analysis and quick retrieval of aggregated data, making it essential for business intelligence and strategic planning.

DynamoDB

Single Table Design: Unlike the traditional SQL design DynamoDB follows single table design meaning it stores all types of data in a single table rather than multiple ones. This type of design introduces two new key words one is partition key and another one is sort key. In single table design we can declare each row as an item and if the items are being corresponding to one partition are called item collection. There some keyword which are being used in the single table design as follows

Partition Key: In dynamodb partition key defines how data is being distributed among the partitions.It is also referred as hash key as data data in dynamodb is stored and retrieved as hash. Whenever a data is being inserted it generates a hash and based on the hash it stores the data into the corresponding partition and same goes for retrieving data from a particular partition.

Sort Key: Sort key is determined as to how a data is being organized in a particular partition. There is always a possibility that items have the same value for the partition key but there must be a different value for the sort key.
Primary Key: Primary key uniquely identifies a row. Sometimes the partition key is regarded as the primary key, however it can be the combination of both partition key and sort key.

2. Event Driven Architecture: dynamoDB streams is a feature of dynamoDB which captures any crud operations in a dynamoDB table and records them into streams. It allows any application to track any types of changes and triggering an event. Each event in the stream is called a stream record which contains information about the item affected and the type of modification. For e When a new order is placed in an order stable, a stream record is generated. A Lambda function can be triggered to process the order, update inventory, send notifications, or replicate the order to another data store.

3. Time to Leave(TTL): Time to leave is a feature of dynamoDB which is responsible for automatically deleting items from a table after a particular time. We don’t need to delete data manually or by query like in SQL. This reduces the storage cost by removing unnecessary data which is no longer needed after a particular amount of time which is about 48 hours by default.

4. Access Pattern: One of the most important yet most challenging tasks is to define the access pattern for your dynamoDB. The design solely depends on what kind of query can happen after the application is being live. The design of partition key and sort key depends on the access pattern. Depending on the query the database will first go to the desired partition where the desired data might reside. So we need to define the access pattern first before designing the database

5. Global and Local Secondary Indexes: It enables another layer of flexibility as far as querying is concerned. In LSI one can add another sort key along with the present sort key and partition key. But if one uses an LSI the partition size automatically becomes a 10gb of size. One can use at most 5 LSI for one table design and it comes free of cost meaning aws will not charge you any penny if one uses any kinds of LSI in a table.

On the other hand GSI allows you to add another partition key and sort key in a table. What it does is it copies all the data from the table and in that table we can apply the partition key and sort key. AWS allows you to used up to 20 GSI for a particular table but in that case dynamoDB will charge for each write and read operations.

6. Data Duplication: One of the main features of DynamoDB is the ability to duplicate data, which significantly enhances query performance and response times. However, data duplication increases storage costs, but AWS never charges for storage and only charges for write and read operations. However, while data duplication improves efficiency significantly, it also has drawbacks. Every change must be propagated across all duplicates, increasing the number of write operations that AWS charges for.

When to Choose PostgreSQL or DynamoDB?

Choose Postgresql

Complex Queries and Joins are Necessary: Though join operations are sometimes costlier. PostgreSQL excels with complicated queries and joins, allowing you to quickly access and manage relevant data from numerous tables. Here is an example operations of join query

SELECT customers.name, SUM(orders.amount) FROM customers JOIN orders ON customers.id = orders.customer_id GROUP BY customers.name;

2. Extensive Analytical and Reporting Needs: If your application needs heavy analytical reports postgresql should be the go to databases as it can handle extensive queries and also reporting data

3. Data Integrity and Consistency : Foreign keys, unique constraints, and check constraints are among PostgreSQL’s several data integrity capabilities, helping in the maintenance of consistent and correct data.

CREATE TABLE products

( product_id SERIAL PRIMARY KEY,

name VARCHAR(100) NOT NULL,

price NUMERIC CHECK (price > 0),

stock INT CHECK (stock >= 0) );

Using constraints to enforce data integrity.

Choose DynamoDB

Scalability and Performance are Top Priorities: DynamoDB’s seamless scalability and flexibility to manage heavy traffic make it ideal for applications with varying or enormous workloads.
Faster Response: If one’s access patterns are defined and you designed your database efficiently DynamoDB will always retrieve data faster than SQL regardless of the data volume it will always fetch data faster.
Flexible Data Models and Schema-less Design: DynamoDB’s schema-less design enables flexible data modeling, accepting various data structures without specified schema.
High Availability and Fault Tolerance: DynamoDB’s multi-region, multi-active architecture provides high availability and fault tolerance, ensuring that your application remains available even in the face of regional outages.

Scenario

Restaurant Management System

Consider a restaurant management system: customers go through the menus and and according to the menu they place orders and waiters serve the orders.In that case the following requirements are necessary

Requirements:

Complex queries and joins for reporting.
High data integrity and consistency.
Scalability for handling variable traffic.
Low-latency read and write operations.

Probable Access Pattern:

Get all the menu
Add an order
Daily/monthly/yearly total order quantity/amount

Recommendation:

Postgresql: It can be used for complex queries and joins operations for reporting purposes. Also any type of OLAP operations like how many orders for a particular time or over a period of time or how much sales generates over a period of time.
DynamoDB: It can be used for faster read and write operations, for example retrieving all the menu items from the menu or adding an order. As these operations need faster response and also it can be used for variable traffic like when more users are entering the menu item or add in an order it should automatically scale up or down depending on the situations.

Conclusion

PostgreSQL and DynamoDB are both powerful database systems, with unique advantages based on your application’s requirements. PostgreSQL excels in handling complicated queries, transactions, and relational data models, making it ideal for traditional corporate applications and data warehousing. DynamoDB, on the other hand, provides seamless scalability, faster query response, low latency performance, and flexible data modeling, making it perfect for contemporary, high-traffic applications, IoT systems, and real-time analytics.

By evaluating your application’s specific needs around data structure, scalability, performance, and integration requirements with other AWS services, you can make an informed decision between PostgreSQL and DynamoDB. Both databases offer robust solutions to effectively manage and scale your data infrastructure, ensuring optimal performance and reliability for your application.

Building End-to-End Live Streaming Solution with AWS Media Services - Best Software Development Team Extension Partner for Nordics

Omor Faruk Rakib — Mon, 24 Feb 2025 18:00:00 GMT

Introduction

In today’s digital age, live streaming has become a powerful tool for businesses, content creators, and broadcasters. Whether it’s for entertainment, education, or corporate communications, delivering high-quality live video to a global audience is more accessible than ever, thanks to cloud-based services like AWS Media Services. In this blog, I’ll walk you through the process of building a live streaming solution using AWS Media Services, starting from capturing video with a webcam to delivering it to viewers through a Content Delivery Network (CDN).

Why AWS Media Services?

Before diving into the walkthrough, let’s quickly review why AWS Media Services is a great choice for building live streaming solutions. AWS Media Services offer a comprehensive set of tools that allow you to ingest, process, package, and distribute live video with high performance and scalability. The services work seamlessly together, providing a reliable pipeline for live video streaming from start to finish.

Overview of the Process

Here’s a step-by-step overview of what we’ll be doing:

Capture video using a webcam and transmit it using FFmpeg.
Ingest the video stream with AWS Elemental MediaConnect.
Process the video stream with AWS Elemental MediaLive.
Package the processed video for delivery with AWS Elemental MediaPackage.
Deliver the video to viewers through Amazon CloudFront.

Let’s get started!

Step 1: Capturing and Transmitting Video Using FFmpeg

To begin, we need to capture video from a webcam and transmit it to AWS. For this, we’ll use FFmpeg, a versatile tool for handling multimedia data.

Install FFmpeg: First, download and install FFmpeg on your local machine. This tool will be used to capture the video feed from your webcam and send it to AWS.

You can verify the installation by opening a bash terminal inside the FFmpeg folder and running the following command:

This will display the FFmpeg version if it has been installed correctly.

Identify Video and Audio Sources: Once FFmpeg is installed, identify your webcam and microphone sources. You’ll need this information to configure FFmpeg properly. You can list all available devices using the following FFmpeg command:

Transmit Video Using FFmpeg: With the sources identified, you can now use FFmpeg to transmit the video. Here’s the command:

Replace YourWebcamName and YourMicrophoneName with the names of your devices, and YOUR_MEDIA_CONNECT_IP:PORT with the IP address and port provided by AWS MediaConnect (in step 2).

Step 2: Ingesting Video with AWS Elemental MediaConnect

AWS Elemental MediaConnect is responsible for ingesting the video stream and forwarding it to other AWS services for processing.

1. Create a MediaConnect Flow :

- In the AWS Management Console, navigate to AWS MediaConnect and create a new flow.
- Select the source type as Standard Source, as the video will be coming from your local machine.

2. Configure the Flow :

- Set the protocol to SRT-Listener and specify the inbound port number (e.g., 3000).
- For this demo, set 0.0.0.0/0 in the allowlist (CICD block).
- Create the flow. AWS will provide an inbound IP address and port, which will be used in your FFmpeg command (refer to Step 1.4).
  .
3. Run the FFmpeg Command:
- Replace YOUR_MEDIA_CONNECT_IP:PORT in the FFmpeg command with the provided Inbound IP:Port.
- Run the command to start sending the video stream to MediaConnect.

4. Start the Flow :

- Start the MediaConnect flow and ensure the FFmpeg command is running.
- This will initiate the video stream from FFmpeg to MediaConnect. Verify that the health status of the flow shows as connected.

Note: While the MediaConnect flow typically sends video to AWS MediaLive for processing, and MediaLive then sends its output to MediaPackage, we’ll create the MediaPackage channel first since its endpoints are required during the MediaLive channel setup.

Step 3: Packaging Video with AWS Elemental MediaPackage

AWS Elemental MediaPackage packages the processed video into formats suitable for delivery to end-user devices.

Create a MediaPackage Channel:
- Go to the AWS MediaPackage console and create a new channel.
- Provide the necessary information, such as the channel ID, description, and enable logging.
- Once completed, create the channel.
HLS Ingest Endpoints:
- MediaPackage will automatically generate two HLS ingest endpoints, each with a unique URL, username, and password.
- These credentials will be required when configuring your MediaLive channel (refer to Step 4 in the MediaLive setup).
Create an Origin Endpoint:
- Navigate to the “Manage Endpoints” section in the MediaPackage console and create a new origin endpoint.
- Provide an ID for the endpoint and leave the other fields set to their default values.
- Once created, this origin endpoint will serve as the URL where viewers can access the video stream.

Step 4: Processing Video with AWS Elemental MediaLive

AWS Elemental MediaLive is used to process the live video stream, enabling broadcast-quality video processing in real-time.

Create a MediaLive Channel:
- Navigate to AWS MediaLive and create a new channel.
- Start with a predefined channel template, such as HTTP Live Streaming (HLS), and ensure you select the proper IAM role.
- Set the channel class to SINGLE_PIPELINE, which means only one stream will be processed.
Set Up Input Attachments:
- In the channel configuration, add an input attachment and set the input type to MediaConnect, as your video stream originates from there.
- Set the input class to SINGLE_INPUT and attach the previously created MediaConnect flow ARN.
- Once the input is created, return to add input attachment and refresh inputs to attach the newly created input to the channel.
- Additionally, create and name an audio selector under General Input Settings.
Configure Outputs:
- In the HLS output group, remove all default outputs except output_1 and output_2 for this demo.
- Use the URL, username, and password from the HLS ingest endpoint of the MediaPackage channel (created in Step 3) in the HLS group destination. Provide a name and copied password while creating the parameter.These credentials will be used to send the output to MediaPackage.
- In output_1 and output_2, select the audio selector created earlier in the Input Attachment section.
Create and Start the channel:
- Once all the steps are completed, create the MediaLive channel.
- Start the channel and wait for the channel state to change to Running.
- Check the preview section to confirm the live stream is running successfully.

You can also view the live stream by navigating to the preview link under the Origin Endpoints section of the MediaPackage channel.

Step 5: Delivering Video with Amazon CloudFront

Amazon CloudFront, a CDN service, delivers the video to viewers with high performance and low latency.

Create a CloudFront Distribution: Go to the CloudFront console and create a new distribution. Select the MediaPackage origin you created earlier as the origin for this distribution.
Configure Distribution Settings: Allow the necessary HTTP methods (GET, HEAD, OPTIONS) for the viewer, select CachingOptimized as cache policy, select “Do not enable security protections” for Web Application Firewall, and leave other settings as default for this demo.
Generate the Streaming URL: After creating distribution, CloudFront will provide a distribution domain name. Replace the domain part of the MediaPackage origin URL with this distribution domain name to generate the final streaming URL.
For example:
- Original MediaPackage URL: https://example.com/out/v1/stream/index.m3u8
- CloudFront Distribution Domain: https://cdn.example.com
- Final Streaming URL: https://cdn.example.com/out/v1/stream/index.m3u8
Test the Streaming URL: Use a video player like VLC to open the final streaming URL. If everything is set up correctly, you should see the live video stream playing.

Voila! Now you should see your live stream video taken from your webcam, and using this URL, anyone can watch your livestream.

Conclusion

Building a live streaming solution with AWS Media Services is a powerful way to deliver high-quality video content to a global audience. By following these steps, you can create an end-to-end live streaming pipeline that captures video from a local webcam, processes it with AWS services, and delivers it through a CDN like CloudFront. This setup is scalable, reliable, and optimized for various network conditions, ensuring a smooth viewing experience for all your users.

Whether you’re a developer, content creator, or business looking to stream live video, AWS Media Services offers a comprehensive and flexible solution to meet your needs. With the right setup, you can deliver professional-grade live streams that engage and captivate your audience.