DEV Community: Muhammad Harith Zainudin

Simplify Your Workflow 📈: A Guide to Standardizing Commit Messages with Husky 🐶 in Monorepos 📦

Muhammad Harith Zainudin — Mon, 07 Aug 2023 05:08:36 +0000

You have a project. But, its a monorepo. Along the way, you start to have many people onboard in the project. But, you want people to follow a certain standard when committing a message for the changes that they have make. You are thinking about the future. The clarity of what have been done. The maintenance effort and so on.

How to implement a standard commit message across your team? Well, one of the ways is by using git hooks, and Husky 🐶 can help you with that!

To read more about why and what’s the benefit of standardizing commit message? You can read it here.

Today, I’ll give you step by step, on how to setup husky on monorepo to standardize the commit message across your teams.

Let’s just say you have your folder structure like below, where you’re building for your Frontend project.

There's a multiple folder that you create for your admin website and public website. Or maybe you have project for mobile and another one is for desktop. Anything. As long as you have multiple projects in a repository.

Let's get started!

It's recommended to add husky in root package.json. But in this tutorial, we’ll just install husky in one of the folder in your repo and just use our existing package.json. It’s totally okay and fine.

Meaning, you will not have package.json and package-lock.json at your root folder.

Go to any of your folder that you want Husky to be in. In this case, let’s take user-public folder as an example.
Install husky by running below command.
```
 npm install husky
```

3. Update your `package.json` manually. You can update the `prepare` scripts in `package.json` according to your preferences. In this case, we change directory to the root folder (as husky install must be run in the same directory as `.git`) and put husky config inside the `user-public` folder. Or you can just let husky install in your root folder. Just your husky modules will be inside user-public folder.

     ```


     {
       "name": "user-public",
       "version": "1.0.0",
       "description": "Bla bla bla...",
       "main": "index.js",
       "keywords": [],
       "author": "Harith Zainudin",
       "scripts": {
         "prepare": "cd .. && husky install user-public/.husky"
       }
       "license": "ISC",
       "dependencies": {
            ...<all-your-dependencies-here>,
       }
     }

In our case, our .git is the same level with our user-public and admin-internal . Hence we will need to do some manual configuring on our package.json by ourself before running the command. That is what we do in step 3, where we amend our package.json a bit to cater with our folder structure and point out to husky that we are using current folder to install husky. Incase you wondering and don’t understand where is your .git folder is and what it is, click here for explanation. Then, what you need to do, is just run the command below.
```
 npm run prepare
```

5. This is what you will get, once you have run the above command and you can see the `.husky` config folder under your `user-public` folder.

     ![Image showing successfully run npm run prepare](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k1o2nv0szffu6dkyd18n.png)

     ![Image showing .husky config folder is created](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zq0atb9xnerr3t1iso9y.png)

6. Before we add our Git Hooks, we need to add the “Scripts” that will check for your commit message. In this case, you can just get the template that I have make [here](https://gist.github.com/harithzainudin/a99b25c04d099e4f6c08c21927ef9319). It is in Javascript (Please don’t judge me hahah). You can make your own in bash or any language you like, but for me, I prefer and comfortable with Javascript, hence I use Javascript. The template might be not really complete or perfect, but hey, it get the jobs done for me! :p

7. Once you have download/copy the template or make your own checking, put the template inside `.husky` config folder, and your folder will look something like this now.


     ![Image showing the final result when have put commit-msg-linter.js inside husky config folder](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/sddlp6a3ci18qn45jwjj.png)

8. Now we are ready to start adding our git hooks! Husky supports [all Git hooks](https://git-scm.com/docs/githooks). For us, because we want to standardize the commit message only, let’s use commit-msg hooks. Run below command to add the hooks. [Click here](#step-8-explanation) for explanation on command below.

     ```


     # You can change to the git hooks that you prefer. But we will use commit-msg hooks as for now.
     npx husky add .husky/commit-msg "cat user-public/.husky/commit-msg-linter.js | node --input-type=commonjs"

     # Make sure you stage the changes for husky config, then your hooks will take effect.
     git add .husky

Once you run the above command, you will get the result below. Now, your .husky config folder will contain commit-msg file. This file is automatically create by husky once you run the above command.
Once you start to commit your changes with your message, and if the commit is not according to your checking and validation, it will show something like this. Husky will prevent you from committing your commit.

You’re good to go now! That’s all you need :)

Of course, if you don’t like how’s the message looks like or you want different kind of checking, feel free to update or change the content inside commit-msg-linter.js. Like I was saying in step number 6, you can use whatever language that you comfortable with!

Hope you able to improve and standardize the commit message across your team! Goodluck and have fun with the commit message.

Stay hungry, stay foolish, and keep learning!

Thank you for reading :D

Psstt pstt :p
Do consider to love this article ❤️ and follow me! Why not right? It's FREE~
I would really appreciate it 👨🏻‍💻
Will be posting more on things related to AWS, JavaScript, Serverless and more!

EXTRA INFORMATION

Explanation for Command on step 8

npx husky add .husky/commit-msg: This part of the command tells Husky to add a commit-msg hook to the .husky directory. The commit-msg hook is used to enforce commit message conventions.
cat commit-msg-linter.js | node --input-type=commonjs: This is the script that will be executed by the commit-msg hook. Let's break it down further:
- cat commit-msg-linter.js: This part uses the cat command to read the contents of the commit-msg-linter.js file. It's assuming that commit-msg-linter.js contains a script for linting or validating commit messages.
- |: This is a pipe symbol, which is used to redirect the output of the command on the left side of the pipe to the command on the right side.
- node --input-type=commonjs: This part of the command runs the Node.js interpreter with the commit-msg-linter.js script as input. It specifies the --input-type=commonjs flag to indicate that the input script should be treated as CommonJS module syntax.

What is .git, how to know and where is it located?

The .git folder is a hidden folder that is created when you initialize a Git repository or clone a project from somewhere else. It contains all the necessary information for your project in version control, including the history of commits, remote repository address, and more. It will be in your root folder in your project.

Here is some key information about the .git folder:

Purpose: The .git folder serves as the repository for your project, maintaining a history of the changes made to your codebase. It stores metadata and the object database for the project.
Contents: Inside the .git folder, you will find various files and directories that are essential for Git to handle your code. These include the commit history log, object database, configuration files, hooks, and more.
Visibility: The .git folder is hidden by default to prevent accidental deletion or modification. You can view it using the command ls -a in the Git Bash terminal. To show hidden folder for VS Code, see here.
Importance: The .git folder is crucial for performing Git operations on your project. Without it, your project is considered a local project and not a Git project. Deleting the .git folder would remove all version control information and make it difficult to track changes and collaborate with others.

It's important to note that the .git folder should not be modified or deleted manually unless you have a good understanding of Git and its implications.

Unlocking Seamless Collaboration and Code Quality: The Power of Standardized Commit Messages in Software Development ⚙️

Muhammad Harith Zainudin — Sun, 06 Aug 2023 06:53:45 +0000

I totally understand that sometimes it is really hard to give a meaningful commit message. For me, if it’s hard for you to give commit message, means there are just too much changes in your commit or it is complex. But if it is really super hard, then don’t waste your time. Just try your best to make it as simple as you can. Just don’t waste too much time.

Today, we will be talking about what’s the benefit of standardizing commit message across your project or team members.

Standardizing commit messages across teams in software development can bring several benefits that contribute to better collaboration, code quality, and maintainability. Here's a list of some key benefits:

1. Clarity and Consistency

Standardized commit messages provide a clear and consistent format for conveying the purpose and context of code changes. This makes it easier for team members to understand the changes, even if they are not directly involved in that part of the codebase.

Example: ABC-123: Implement profile picture upload functionality

If you able integrate your git repo with your issue tracking system like Jira, YouTrack or anything, The git will be able to detect the ticket number and directly point to the ticket in your issue tracking system.

2. Improved Communication

Clear commit messages enhance communication among team members. Developers can quickly grasp the changes made, understand the reasons behind them, and collaborate more effectively.

3. Easier Code Review

Standardized commit messages make code reviews more efficient. Reviewers can quickly assess the changes, understand the context, and provide meaningful feedback without spending extra time deciphering unclear messages. When your team mates or senior review your merge request, one of the way is to look at the commit message. If it’s clear, then, you will make the review process much faster!

4. Documentation and History

Well-structured commit messages serve as documentation for the codebase's history. Team members can look back and understand why certain decisions were made, which is valuable for troubleshooting, debugging, and maintaining the code in the future.

5. Automated Processes

Many development tools and platforms leverage commit messages for automation. Continuous integration, continuous deployment (CI/CD) pipelines, version control systems, and issue tracking systems can use commit messages to trigger actions, generate changelogs, or link changes to specific issues. When you able to standardize it, you able to automate your deployment process.

6. Search and Navigation

Standardized commit messages make it easier to search and navigate through the version control history. Developers can quickly find specific changes, understand their context, and follow the evolution of a feature or bug fix.

7. Onboarding New Team Members

When new team members join, standardized commit messages help them quickly familiarize themselves with the codebase and understand ongoing development efforts.

8. Consistent Changelogs

Commit messages can automatically generate changelogs for software releases. Consistent commit messages enable accurate and coherent changelogs that provide users with clear insights into new features, bug fixes, and improvements.

9. Codebase Maintenance

As software evolves, the codebase may pass through multiple hands. Standardized commit messages make it easier for different developers to maintain and extend the codebase without confusion. Pretty sure you know it well that the bigger the codebase, the harder the maintenance. AND THE MORE CONFUSION ITS GONNA BE! Hence, one way to reduce this, is by having standard commit message.

10. Coding Best Practices

Encouraging thoughtful and standardized commit messages promotes coding best practices and a culture of professionalism within the development team.

11. Reduced Technical Debt

Clear commit messages help avoid ambiguity and misunderstandings about code changes. This reduces the likelihood of introducing technical debt due to miscommunication.

12. Support for Open Source Projects

If the project is open source, standardized commit messages can make it more accessible to contributors outside the core team. Contributors from different backgrounds can understand and contribute effectively based on clear commit messages.

Overall, standardized commit messages play a significant role in fostering collaboration, maintaining code quality, and ensuring the long-term success of a software project. Commit message is not everything, but by having a standard commit message, you will be able to reduce the confusion and maintenance of the codebase while improving your process and standard in a long term.

Stay hungry, stay foolish, and keep learning!

Thank you for reading :D

Strategies to minimize Vendor lock-in in cloud technology ☁️

Muhammad Harith Zainudin — Sat, 05 Aug 2023 13:12:39 +0000

After my final year in degree, I directly jump to the industry and doing cloud native development. It has 2 years now. During the 3rd month on doing cloud native development, I was taking certificate for Microsoft Azure Developer and AWS Developer. At that time, I was thinking, what if I build something on Azure natively and wanted to migrate to AWS? or vice versa. What if there is a customer that don't want to use their current cloud provider, and wanted to migrate to AWS. This must be hard.

There are 1 term that we can relate to this which is Vendor lock-in. Vendor lock-in refers to a situation where a an application becomes dependent on a particular cloud provider and finds it difficult or costly to switch to a different provider.

But throughout the process, now I understand on how to minimise this issue. I understand that we are concerns about vendor lock-in in cloud-native development. However, I would like to provide some additional context on this issue.

First, it is true that cloud-native development often involves using the native capabilities of a specific cloud provider. This is because these capabilities are designed to work seamlessly with the cloud provider's infrastructure and services, which can result in better performance, scalability, and security. However, this does not necessarily mean that you are locked into that provider forever.

There are several strategies that can be used to minimize the risk of vendor lock-in.

1) Technologies and frameworks

Use cloud-agnostic technologies and frameworks that can run on multiple cloud platforms. For example, many cloud-native applications use Kubernetes as a container orchestration platform, which can be deployed on any cloud provider or even on-premises. You can also use serverless framework, where we use compute as a service to deploy our code. To move between cloud, we just need to cater the code a bit according to the cloud provider. This is much better than you completely refactoring the whole code.

2) Design for portability

Design applications using a modular architecture that separates the application logic from the underlying infrastructure. When designing and developing cloud-native applications, consider portability as a key requirement. This can make it easier to switch cloud providers.

3) Tools from the cloud providers

Additionally, most cloud providers offer tools and services to help you migrate your applications to their platform or to another platform if you decide to switch providers. While there may be some costs and effort involved in this process, it is typically much less than starting from scratch. These migration tools and services that are provided by the cloud providers can ease the process. Example are AWS Migration Hub, AWS Application Migration Service, Azure migrate and many more.

In summary, while vendor lock-in is a valid concern in cloud-native development, it is not an insurmountable obstacle. It is possible to minimize the risk of lock-in and maintain the flexibility to choose the best platform for your needs.

But hey, on the other side if you stick to one vendor, you can reduced the complexity of your application. Sticking with a single cloud provider can simplify IT operations by reducing the number of systems and providers that need to be managed. It depends on what you want to achieve in your organization, how you handle the complexity, and which path you want to choose.

Problems will always there. What we can do about it? Try to minimize it as little as possible.

Stay hungry, stay foolish, and keep learning!

Thank you for reading :D

5 best practices for AWS Lambda function design standards

Muhammad Harith Zainudin — Sun, 21 May 2023 08:00:44 +0000

Here are a few best practices to incorporate into your Lambda function design standards.

1. Store and reference dependencies locally

If your code retrieves any externalized configuration or dependencies, make sure they are stored and referenced locally after initial execution. For example, if your function retrieves information from an external source like a relational database or AWS Systems Manager Parameter Store, it should be kept outside of the function handler. By doing so, the lookup occurs when the function is initially run. Subsequent warm invocations will not need to perform the lookup.

If you see handler.js on line number 3, we are defining the global value. Then, on line number 6, we are checking either the value is exist or not, if yes, then we will get the value and assign back to the variable value. With this, in the next invocation of lambda, if the lambda is still warm, we do not need to get again the same parameter value.

2. Limit re-initialization of variables

You should also limit the re-initialization of variables or objects on every invocation. Any declarations in your Lambda function code (outside the handler code) remain initialized when a function is invoked.

To improve performance, limit the re-initialization of variables or objects in an AWS Lambda function. When a Lambda function is called, any code outside the handler function is only run once during the function's startup or cold start. Variable declarations and object initialization are included.

Re-initializing variables or objects on each invocation suggests that the code is doing redundant operations that might have been performed only once during startup. This can result in longer execution times and a decrease in the performance of your Lambda function.

Limiting variable or object re-initialization ensures that these activities are only executed once during the cold start. Subsequent Lambda function invocations (warm invocations) can then reuse the initialised variables.

3. Check and reuse existing connections

Add logic to your code to check whether a connection already exists before creating one. If one exists, just reuse it.

In this example, the database client is stored in a global variable dbClient. During the initial invocation (cold start), the code checks to see if dbClient is null. If it is null, a new database client is generated with the auxiliary function createDatabaseClient. If dbClient is not null, it indicates that a client already exists, and the function reuses existing client.

Following invocations of the Lambda function (warm invocations) might save the overhead of generating a new database connection and client setup, which can be time-consuming. Reusing the client aids in the performance and efficiency of the Lambda function.

Note: To ensure best practises for maintaining database connections, you must manage error scenarios, connection pooling, and proper client closure in a real-world scenario. The supplied example is simplified for demonstrative purposes.

4. Use /tmp space as transient cache

Add code to check whether the local cache has the data that you stored previously. Each execution context provides additional disk space in the /tmp directory that remains in a reused environment.

The code uses fs.existsSync to check if the cache file exists in the /tmp directory. If the file exists, it reads the data from the cache file using fs.readFileSync and parses it as JSON for further processing.

If the cache file does not exist, it retrieves the data from an external source, processes it, and then stores it in the cache file located in the /tmp directory using fs.writeFileSync.

By utilizing the /tmp space as a transient cache in JavaScript, you can reduce the need to repeatedly retrieve the same data from an external source, thereby improving the performance and reducing the execution time of your Lambda function.

5. Check that background processes have completed

And finally, make sure any background processes (or callbacks in the case of Node.js) are complete before the code exits. Background processes or callbacks initiated by the function that don’t complete when the function ended will resume, if you get a warm start.

Summary

By utilising the best practice above, you will be able to reduced latency, optimize cost, improve performance and reduced load on external resources of your AWS Lambda.

To read more, you can go to AWS Lambda Documentation for more best practices.

Stay hungry, stay foolish, and keep learning!
Thank you for reading :D

Cover image by Diego PH on Unsplash

Security in AWS for Serverless Application

Muhammad Harith Zainudin — Thu, 09 Mar 2023 08:00:01 +0000

Cloud security is our top priority. That is undeniable. It is important and it is needed. When you’re designing serverless architectures, the best practices that apply while securing any other cloud architecture still apply.

One benefit of serverless architectures is that when you leverage Amazon Web Services (AWS) managed services, you shift the burden of the shared responsibility model toward AWS. You have the same security issues, but AWS manages more of them on your behalf. For AWS Lambda specifically, you aren’t responsible for the operating system or network configuration where your functions run.

So let’s discuss about three general best practices that you are responsible for:

Follow the principle of least privilege
Protect data at rest and in transit
Audit your system for changes, unexpected access, unusual patterns, or errors.

In other words, only let in people you invite, lock up your private stuff, and make sure no one is doing anything unexpected while visiting. This means how to protect the data that comes into or resides inside the house.

1. Follow the principle of least privilege

When you are setting the permissions with IAM policies, remember that to only give the necessary permission to complete a task. You can achieve this by specifying least-privilege permissions, commonly known as the activities that can be performed on specified resources under specific circumstances.

How you want to know that I have already given only the necessary permissions? Well, there are 2 approach for this, and it's totally up to you on which approach you want to choose.

Begin with broad permissions and over the time you can strive to grant fewer permissions as your use case develops. Always check and keep cutting the permissions that you do not need. But don't forget afterwards to cut out the permissions that you do not need.

You can start with granting permission that you think you only need. If you are not sure, then just don't put it yet. Try, do and check. This approach will need you to have a debugging skills to check on the logs. The reason is, you might encounter not enough permissions when doing something. Then, add the permission for the things that you do not have permission with.

So which one do you want to choose? Up to you. I personally will go with the first approach as it will take me faster time to develop or do something. I will have less time encountering not enough permission issue.

Other than that, you can use the AWS managed policies that grant permissions for many common use cases. They are available in your AWS account. You can also use IAM Access Analyzer to help you generate least-privilege policies based on your access activity. When you want to move to production, you can use IAM Access Analyzer policy validation to help you do the validation and giving you actionable recommendations to help you author secure and functional policies.

2. Protect data at rest and in transit

Protecting data at rest

Use Encryption
One of the most fundamental ways to protect data at rest is by encrypting it. AWS offers several encryption options, including server-side encryption (SSE) and client-side encryption. With SSE, data is encrypted and decrypted automatically by AWS services, while with client-side encryption, data is encrypted and decrypted on the client-side using an encryption key.
Use AWS KMS
AWS Key Management Service (KMS) is a fully-managed service that makes it easy to create and control encryption keys. AWS KMS can be used with other AWS services to provide secure and easy-to-use encryption features.
Use S3 Bucket Policies
S3 bucket policies can be used to control access to data stored in S3. Bucket policies can be used to deny or allow access based on conditions such as IP address, time of day, or request type.

Protecting data in transit

Use HTTPS
HTTPS (HTTP Secure) is a protocol for secure communication over the internet. HTTPS is used to encrypt data sent between the client and server and helps prevent eavesdropping and tampering.
Use AWS Certificate Manager
AWS Certificate Manager (ACM) is a service that makes it easy to provision, manage, and deploy SSL/TLS certificates for use with AWS services. ACM provides a simple way to secure traffic between AWS services and applications.
Use VPC Endpoints
Virtual Private Cloud (VPC) endpoints provide a secure and private connection between AWS services and VPCs. VPC endpoints can be used to route traffic directly between AWS services without the need for an internet gateway or NAT gateway.

For additional information, when it comes to passing data to Lambda functions, you have three options:

No	Options	Scoped
1	Environment variables	Scoped to a single function
2	AWS Systems Manager Parameter Store	Can be shared across multiple applications
3	AWS Secrets Manager	Can be shared across multiple applications

Choose whatever fits your use case!

3. Audit your system for changes, unexpected access, unusual patterns, or errors.

Another crucial component of safeguarding a serverless architecture is auditing your system for changes, unexpected access, unusual patterns, or errors. In order to identify any odd or suspect activity that can point to a security threat or a system fault, this process entails monitoring and analysing numerous system logs and data.

To check your system for modifications, unauthorised access, odd patterns, or mistakes in AWS, you can use a variety of tools and services, such as:

AWS CloudTrail
This service keeps a thorough record of all activities that take place in your AWS account. Every API activity in your account, including API calls, AWS Management Console sign-in events, and AWS service activity, may be tracked and recorded using CloudTrail.
AWS Config
AWS Config is a service that offers a comprehensive list of AWS resources, configuration change notifications, and configuration history. You can keep tabs on modifications to your AWS resources and track compliance with your policies using AWS Config.
AWS CloudWatch
Amazon CloudWatch is a monitoring service that offers metrics and logs for AWS applications and resources. Lambda functions, API Gateway, and other AWS services can all have logs and metrics collected and monitored by CloudWatch.
AWS GuardDuty
AWS GuardDuty is a threat detection service that employs machine learning to examine data from numerous sources, such as DNS logs, CloudTrail logs, and VPC flow logs. GuardDuty can be used to find numerous threats, such as botnets, compromised credentials, and reconnaissance.

By using these tools and services, you can monitor and analyze various system logs and metrics for your serverless application to detect any unexpected access, unusual patterns, or errors that could indicate a security threat or a system error. This helps you identify potential security risks and take proactive steps to remediate them before they become a bigger problem.

The key point is that security best practices don’t change with serverless. Make yourself aware of how you can take advantage of AWS managed services to reduce the security burden you have to manage. Think about security end to end at each integration point in your distributed architecture.

"Do It, Do It Right, Do It Better": A philosophy for Cloud Developer

Muhammad Harith Zainudin — Thu, 09 Feb 2023 16:16:06 +0000

As a cloud developer, you must approach every project with an eye towards quality, efficiency, and continuous development. This mindset is encapsulated in the statement, "Do it, do it right, do it better," which serves as a great reminder of the necessity of achieving excellent results in cloud development. In this article, I'll explain how to apply this statement in your daily work.

First and foremost, execute it or "do it."

The initial step in every cloud development project is to begin. The cloud computing market is continually changing, and developers must keep up with the latest technology and best practices. Starting with "do it" is the first step towards delivering a high-quality cloud solution.
To begin, do the following:

Defining your project objectives and determining the tools and services required to fulfil them
Make a schedule and divide the necessary resources to ensure the project is done on time.
Lastly, start working on your implementation to ensure it meets your project's needs.

Of course, the most important thing to remember when you're just starting is to DO IT FIRST.

Complete the business requirements. Make sure that all of the features are included in the project you're working on.

Don't put too much emphasis on adding or implementing new technology or experimenting here and there. This will happen later on. If you are capable of following best practices, try to do so. It's OK if you're not entirely sure; do it later.
The general attitude is, "Do it first!"

Do It Correctly

Once you've begun your cloud development project, you must concentrate on "doing it right." This entails taking advantage of the advantages of cloud computing while ensuring that the implementation is secure, scalable, and reliable.
To accomplish this, you should:

Stay current on the latest technologies and best practices: Because the cloud computing business is constantly growing, it's critical to stay current on the latest innovations and best practices. Attending webinars, reading industry blogs, or engaging in online forums could all be part of this.
Work with stakeholders: Working with stakeholders, including business leaders, end users, and other developers, can help you understand their needs and discover areas for development. Seeking and incorporating input regularly can assist you in ensuring that your implementation is "doing it properly."
Measure success with metrics: Metrics are critical for determining the effectiveness of a cloud implementation. By keeping an eye on critical indicators like performance, availability, and cost, you can identify areas for improvement and make data-driven decisions about how to make your deployment function best.

Finally, do it better.

After you've begun your cloud development project and focused on "doing it correctly," it's time to shift your attention to "doing it better." This entails constantly upgrading your implementation to produce results that exceed expectations. To accomplish this, you should:

Accept automation: Automation is an essential component of cloud development since it can help you save time and boost efficiency. You'll have more time to concentrate on more critical projects and improve your cloud development skills if you automate routine processes like testing and deployment.
Seek input and make improvements regularly. Getting feedback from stakeholders often and using it in your work will help you figure out where you need to improve. You can make sure your cloud development projects are always "doing it better" by asking for feedback and making changes on a regular basis.

Finally, the "Do it, do it right, do it better" concept serves as a helpful reminder of the necessity of producing exceptional results in cloud development. Suppose you just get started, focus on doing it well, ask for feedback and make improvements on a regular basis. In that case, you can ensure that your cloud development projects always meet high standards and produce results that exceed expectations.
You have to start somewhere, especially if you are a junior just starting out. Don't waste your time focused on one issue that will consume your time until you miss the deadline. If you stick to the philosophy, you'll be OK! This attitude, I believe, is equally applicable to others.

I hope you got the spirit of what I was saying!
Continue to be hungry, foolish, and curious!

How to use async await process inside map function with Promise all in Javascript

Muhammad Harith Zainudin — Mon, 26 Dec 2022 04:13:37 +0000

If you are working with API, web development, or backend logic, there will be a time where you will need to loop a certain array and call an endpoint to get a result or response from an API.

In this example, we will be using dummy API from Dummy JSON to call the endpoint.

I'll show you directly since this is a tutorial to show how to use async await process using map function and Promise.all in Javascript. Read more below for the comparison and explanation between for loop and map function.

This is how you use map function with async await process.

Well technically, you can use for loop like below to call an endpoint

And when you run it, you will get result of an array of object, something like this.

with an average of time around 4.2 seconds to 4.6 seconds to get all the result (run the program around 5 times).

This will slow the process and you will need to wait one by one for the endpoint to give the response then you can proceed with the next one until you have loop all the array, and this will increase your response time to load all the resources.

Now, lets compare back for loop and map function.
map() creates a new array from calling a function for every array element and it calls a function once for each element in an array. It does not execute the function for empty elements and map() does not change the original array.

A for loop repeats until a specified condition evaluates to false. The JavaScript for loop is similar to the Java and C for loop.

Basically, both of them do a loop for the array. For loop, will only loop, while map function, will loop also, but it loop a function and creates a new array as a response. Since map function creates a new array, we can pass this to Promise.all, as Promise.all takes an array of promises as input and returns a single Promise

This returned promise fulfills when all of the input's promises fulfill (including when an empty iterable is passed), with an array of the fulfillment values.

As easy summary for Promise.all, if we have 5 products info to get from database, all 5 endpoint will be executed at the same time. Does this make sense to you? (Hope you can understand :p)

This is time taken for map function and Promise.all to return all the 5 products.

I know that for loop is much more faster (You can read the comparison here), but in this case, we are getting information from API response, so we need something other than for loop to receive the response faster. Each function/loop have its own use case, and in this case, my suggestion, it's better to use map function with Promise.all.

By the way, you can also use Promise.all with for loop, but you might need to push the Promise to an array first using for loop, then, pass the array of Promises to Promise.all as an input. But, I prefer to use map function as I can see the logic clearly.

That's it for this article, feel free to comment below if you think there are better way to use async await process with map function and Promise.all :)

Thank you for reading :D

Psstt pstt :p
Do consider to love this article ❤️ and follow me! Why not right? It's FREE~
I would really appreciate it 👨🏻‍💻
Will be posting more on things related to AWS, Javascript, Serverless and more!

Things that I have learned for the past 1 year in Cloud Computing

Muhammad Harith Zainudin — Sun, 21 Aug 2022 12:29:00 +0000

This week is my 1 year anniversary venturing into cloud computing.
Everyday at work, always an exciting day. New things that I don't know and learn.

So, I want to share with you guys on things that I have learned this past 1 year venturing into cloud computing.

Keep exploring and never stop learning
Cloud technology always keep changing and improving day by day. There's always new things that you will find really pique your interest along the way. Who knows that, there's a tool to improve the efficiency of your Lambda(AWS). I don't know that at first 🤷🏻‍♂️🤯
Always ask questions.
Sometimes, stupid question leads you to something that you don't even know exist! It's fine to keep asking your colleague, your friend, the community. That really shows that, you keep thinking, and curious about something.
Always become curious of something, and what happening behind the process.
Lack of curiosity would lead to lack of motivation to explore, learn new things and acquiring new knowledge. In short it affects the development and creates a disconnect to the surroundings. This disconnect will leads to increase in stress and affects your happiness.
Don't sad or give up when you make a mistake.
Acknowledge the mistake, analyse back, take time what led to you making the mistake, put the lesson learnt into practice, review your progress and remember that we can't avoid making mistakes. It's normal. The question is, how can we minimise it. Read back this paragraph and repeat.
Make friends and chat with your colleagues/community
You don't know who you will be talking with. I am sure that you will surely learn something from them. Find a community that can help you in this cloud journey. Maybe after that, you can help back the community by helping others.

Yup, that's all!

Thank you for reading :D

Difference between Lodash Concat and Javascript Native Concat

Muhammad Harith Zainudin — Sun, 31 Jul 2022 16:41:00 +0000

Concat function in Lodash will creates a new array that concat the array with any additional arrays and/or values.
It will not change the original array.

It's easy to use and simple.
Same goes to the Javascript native concat method. But what's the difference between this 2 method?
Well obviously, one is using libraries (Lodash), and another one is Javascript original concatenation.

The syntax also different. BUT, the native Javascript concat win. Let me show you.

I've run the test 5 times in a row, with about 1-2 seconds of interval and this is the result

Running Native concat first, then lodash concat

Test	Native Concat	Lodash Concat	Differences
1	0.318ms	0.179ms ✅	0.139ms
2	0.097ms ✅	0.16ms	-0.063ms
3	0.094ms ✅	0.159ms	-0.065ms
4	0.094ms ✅	0.16ms	-0.066ms
5	0.09ms ✅	0.158ms	-0.068ms

Running Lodash concat first and then native concat.

Test	Lodash Concat	Native Concat	Differences
1	0.525ms	0.009ms ✅	0.516ms
2	0.237ms	0.008ms ✅	0.229ms
3	0.247ms	0.008ms ✅	0.239ms
4	0.259ms	0.008ms ✅	0.251ms
5	0.25ms	0.008ms ✅	0.242ms

With obvious result, native javascript concat wins. This is only using small dataset. With big dataset, surely it will tak e more time to process. Although the result is sub-milliseconds, the timing is important to make our apps run faster.

I'm not saying do not use Lodash concat, but hey, if we have already concat method in built with javascript, it's better to use it. Unless you have other reason to use lodash concat function and your applications don't really care about response time.

Some of Lodash function do actually make our life easier. It is useful and it makes the development much easier and faster as we do not have to implement a complex logic to get the result. So, it is up to you!

We will try to cover up more of the differences between lodash and inbuilt function so that we can have a look later on!

Thank you for reading :D
Psstt pstt :p Do consider to love this article ❤️ and follow me! Why not right? It's FREE~
I would really appreciate it 👨🏻‍💻
Will be posting more on things related to AWS, Javascript, Python, Serverless and more!

Invest in something as developer

Muhammad Harith Zainudin — Mon, 18 Jul 2022 16:02:21 +0000

As a developer/programmer, it is important to know what is the best thing to invest. Surely we need to invest in money and time. Well, mostly is the time because of things that we need to learn especially in technologies and master it, do project yada yada and so on.

Below, I'll list out the top 5 worth 'investment' that you need to do!

invest in your health
- You have only one body and it deserves to be treated with respect. Take a deep breath everyday. Walk. See the outside world. Prioritize your health. Don't just sit and do work. You will get backpain. Surely, and it is not good. Like my boss said, at least watch something that is far from you to give your eyes a rest every hour during working. Oh, and also not to forget, mental health also is very important.
invest in learning resources
- As a developer, surely you want to learn and grow technically. It is quite obvious to invest in learning resources. Don't just go and buy every resources that you think you will learn and do, but in the end, you are not using that resources. Find something that is useful and good resources
Invest in connection
- It's important to have connection. Meet new people and allow your mind to be refreshed by different people's perspectives. Discuss your projects with them and inquire about theirs. It may surprise you how much of a difference it makes.
Invest in writing something or presenting something
- Well, this is quite subjective. It's up to you. But as for me, when you want to write an article or presenting about something, you will do your research and reading, hence you will know more. If you don't know about something that you are reading, then you will search for it. The more you know, the more you realize you don't know. You also learn how to present your idea in a good manner so that other people will understand with what you are trying to tell.
Invest in reading
- This point is like the kind of like the fourth point. At first, I don't really like reading. But what I do is, I just subscribe to newsletter that piqued my interest like technologies, tips and tricks etc. Everyday, I'll open my email, just to go through this newsletter and just quick read everything. Without I'm realising, it become a habit to me, and I tend to read more article through my phone, and tend to search more as the things that I read make me interest and want to know more.

Yup, that's about it. Hope this will help you to invest more for yourself and widen your knowledge!

If you got others, do share in the comment below!

Thank you for reading :D

Psstt pstt :p
Do consider to love this article ❤️ and follow me! Why not right? It's FREE~
I would really appreciate it 👨🏻‍💻
Will be posting more on things related to AWS, Javascript, Python, Serverless and more!

Define Amazon Cognito as authoriser for lambda function in serverless using shared API Gateway 🚀

Muhammad Harith Zainudin — Mon, 06 Jun 2022 15:11:25 +0000

Note: You can get all the codes below in this gists

If you are creating API, maybe you will want to increase the security or limit the access on who can invoke your API. One of the way is to use Amazon Cognito user pool as authoriser for the REST API.

By default, each serverless project will generates a new API gateway, however, we can share same API gateway between multiple project by referencing its REST API ID and Root Resource ID in serverless.yml!

In this example, we will define every services that we will create in difference configuration. This is because, as your application grows, you will likely need to break it out into multiple, smaller services.

Serverless project A

API gateway

Serverless project B

Amazon cognito user pool
API Gateway Authoriser

Serverless project C

Lambda function

You can also define service in serverless project A and B in one project. Up to you!. But like I've mention above, we want to share the same API gateway between multiple project by referencing its REST API ID and Root Resource ID in serverless.yml! I just utilise the intrinsic function in cloudformation so that we can learn more.

Let's get into it!

Serverless project A

We define the service that we will create that is API gateway(line 14-18). We will also exports the root resource ID(line 26-32), and the ID of the API gateway(line 21-24) to be used later service B

Serverless project B

Now, in project B, you can see that we define the authoriser for API gateway in here (line 36-45). We use the properties for RestApiId: !ImportValue service-a-dev-apigw-id (line 39) that we export in service A. We also define the user pool (line 15-24) in this service.

The authoriser will used the user pool as the authentication when invoking the REST API. So, it's fine if you want to define your authoriser in service A instead. But don't forget to make sure to export the outputs of the physical ID. This physical ID later will be used by the lambda in service C.

Serverless project C

In this service, we will define our lambda function (line 14-36), use the API gateway endpoint that we have create in service A under provider apiGateway (line 8-10) and also use the authoriser (line 33-36) that we have define in service B to be used when invoking the endpoint.

You can see that we use !ImportValue restApiRootResourceId and restApiId (line 9-10) to import the value from service A outputs variable and also we define our environment AUTHORIZER_PHYSICAL_ID (line 12) that we export from outputs variable in service B

With this pattern, if you have other microservices and you want to use the same format of endpoint for example https://fqhbso3qa4.execute-api.ap-southeast-1.amazonaws.com/dev/hello, you can just define it like in service C like how I did it under provider apiGateway (line 8-10n) and it will use the same format https://fqhbso3qa4.execute-api.ap-southeast-1.amazonaws.com/dev/etc

Hope all of this make sense to you!

I just want to show you, how you can use the API gateway that is being define from another service and the authoriser also from another service to be used in different service!

As you know, serverless have a limit of 500 resource limit services that we can define and deploy in a project. So I hope, this solution can help you overcome that by splitting your applications into microservices.

Do ask and let me know in the comment below if you have any question! 😁

Note: You can get all the codes above in this gists

Thank you for reading :D

How to use Lodash compact function?

Muhammad Harith Zainudin — Sun, 29 May 2022 12:10:00 +0000

Note: This tutorial also exist in my GitHub

Compact function will remove all falsey values in the array that you provided

Falsey values in javascript are something that evaluates to FALSE.
There are only six falsey values in JavaScript: undefined, null, NaN, 0, "" (empty string), and false.

How to use it? Simple.

const falseyValues = ["", null, undefined, 0, "Harith", "Malaysia"];

const cleanWords = _.compact(data.randomWord)
console.log(cleanWords)

The result will be

It will remove all the falsey values in the array that we provided. Simple as that

Thank you for reading :D