DEV Community: June Dang

Power of Rate Limiting and Explanation

June Dang — Sat, 27 Sep 2025 07:48:13 +0000

A system can only serve well when its resources are correctly consumed and allocated.

In the event that a system is flooded by unusual traffic—whether intentional or not—it could cause the entire system to collapse. A rate limit function in the API gateway can help mitigate this problem.
Rate limiting is a technique for capping how many requests, messages, or resource-consuming actions a client can make within a specific timeframe.

This technique is especially useful during sudden traffic spikes, such as limited-time offers or ticket release events. It also helps prevent malicious bot attacks and keeps your service available for legitimate users.

How does rate limiting work?

Rate limiting is all about tracking which IP addresses are sending requests to your application, while keeping an eye on how many resource access attempts are made within a specific amount of time.
If too many requests are sent from a single IP and exceed the limit, the service will temporarily deny further requests from that IP address.

This works just like a traffic cop at a busy intersection: when one road becomes too congested, the officer halts traffic on that route so others can flow. Similarly, the system pauses or blocks excessive requests to keep overall traffic running smoothly.

Rate limiting is implemented through these steps:

Identify the client
Each incoming request is tagged with an identifier (such as IP address, user ID, or API token).
Track request counts
The system keeps a lightweight counter for each client, usually stored in memory (e.g., Redis), and monitors how many requests are made within a rolling time window (e.g., 100 requests per minute).
Apply the rate limiting algorithm through common algorithms

Token Bucket – Every request spends a token; tokens refill at a steady rate, allowing short bursts while enforcing an average rate.
Fixed/Sliding Windows – Simple counters that reset every minute or roll smoothly across recent time intervals.
Edge Gateways + Redis – Enforce limits at the system’s perimeter using fast in-memory stores to maintain consistency across a distributed environment.

Enforce the limit

If the request is within the limit ➜ it is allowed.

If the limit is exceeded ➜ the server responds with HTTP 429 Too Many Requests, signaling the client to slow down.

Real cases of using rate limiting

Social media platforms apply rate limits to control how many API calls are allowed within a certain timeframe.
Unauthenticated users or free-tier users are typically allowed fewer requests than paid users.
Login forms block users after too many failed login attempts.
E-commerce platforms restrict checkout actions for high-demand or limited-quantity sale items.

How does an email service work?

June Dang — Thu, 10 Aug 2023 05:00:00 +0000

Email has become the cornerstone of modern communication tools and seamlessly integrating as part of our daily work. A statistic by Statista estimates that over 333 billion emails are sent and received every day. But have you ever been curious about the process of emails being stored and sent across the Internet? If yes, then this article is for you.

In the upcoming sections of this page, we will guide you through the most important protocols that help email services to function and finally answer the question: “How every email service works by relying on the use of SMTP to send email and IMAP (or POP3) to store and receive email”.

From sending or “pushing” emails with SMTP

Simple Mail Transfer Protocol (or SMTP) is a standard TCP/IP protocol for sending and receiving email. This protocol plays a crucial role in email infrastructure and is commonly used by email clients like Outlook, Gmail, or Thunderbird for delivering emails to intended receivers.

SMTP server

With every email client, there needs to have an SMTP server to send, receive, or relay emails. You can imagine an SMTP server as a post office that takes your mail and handles delivery to any address you would like to send.

SMTP server is an Outgoing Mail Server application that typically operates on port 25 or 587. Each port behaves differently in that it identifies the process of messages transmitted through the Internet. Some of the main functions of an SMTP server include:

Messages Transmission: the key role of the SMTP server is to establish a connection to the recipient’s server and relay outgoing email messages from the sender.
Address validation: An SMTP server can perform domain name resolution to ensure messages can be successfully delivered.
Messages routing: SMTP server determines the most efficient route for delivering the email to the recipient’s server by rapidly communicating with other servers during the way sending the email.
Ensuring security and authority: To prevent spam, an administrator can configure to only allow certain clients to use the server.

SMTP commands

During the messages transfer, an email client and the SMTP server can communicate through basic instructions called SMTP commands. These commands contain information that helps the SMTP server successfully deliver the messages such as sender and recipient addresses, message content, and status updates. Some common commands are:

HELO or EHLO: Initiate communication between the sender’s SMTP client and the recipient’s SMTP server.
MAIL FROM: Specify the sender’s email address.
RCPT TO: Indicate the recipient’s email address.
DATA: Trigger the transfer of data between the client and server. The message’s content is sent to the SMTP server, including the subject, body, and any attachments
QUIT: Used to terminate the session from client and server once the email transmission is completed.
RSET: Allows the sender to reset the current email transaction in case any errors happen.

SMTP limitations

Although SMTP can both send and receive email, most email services nowadays use it only for transferring emails as SMTP has limitations on queuing received emails and providing storage capabilities:

Minimalistic Protocol: SMTP is designed to focus on efficient message transfer and thus lacks key features for persistent email storage and mailbox organization.
One-way communication: SMTP only supports sending emails from sender to receiver and does not facilitate email retrieval or fetching.
No mailbox management: SMTP does not support a mailbox directory and so it cannot let users manage their mailbox such as: organizing emails into folders, marking them as read or unread, or searching for specific messages. To overcome the limitations of SMTP and ensure better storing and receiving capabilities, email services typically combine the use of SMTP with dedicated storage protocols such as POP3 or IMAP for email storage and retrieval.

To receive with IMAP or POP3

As mentioned earlier, IMAP and POP3 are both protocols that are used to receive or “pull” for recipients to read and store their incoming messages. More than that, you can set up security on these protocols to allow only receiving emails from verified sources. But above all that, these two protocols CANNOT be used for message transferring.

POP3

Post Office Protocol or POP for short is an email-receiving protocol with the latest version POP3 that was released in 1988. POP3 is based on the real-life idea of the post office that the email server will hold any received messages until you read them. After you connect to the mail server, it will download all received messages and store them locally on your computer for offline access. All the downloaded messages are removed from the server then.

IMAP

Internet Message Access Protocol (or IMAP) on the other hand, keeps the email on a server and then synchronized changes across multiple devices. Furthermore, you can access real-time folders, messages, and mailbox organization. But its behavior requires Internet access to be able to read or organize the messages.

How does an email service work?

A common email message transmission from the sender’s client to the recipient’s client included a three-step process that you can illustrate by the diagram below:

1. Sending an email using SMTP

The sender opens the mail client (such as Gmail, or Outlook) and creates a new email message
When the sender clicks the “Send” button, the email client connects to the outgoing SMTP server
The email client supplies the SMTP server with necessary information such as the recipient’s email address, sender’s address, subject, message body, and any attachments.

2. Transmit email messages from the SMTP server through the Internet

The SMTP server performs a DNS lookup to get the routing to the recipient’s email server’s IP address.

3. The recipient’s server receives the incoming message

With IMAP: The client requests an email list from the IMAP server and reads it. The email then stays on the IMAP server and any changes are synchronized within the IMAP server.
With POP3: The client requests an email list from the IMAP server and reads it. The unread email then is downloaded into the client’s local device and then removed from the POP3 server.

Conclusion

On the bottom line, an email service for the sender included the email client interface and the SMTP server for transferring messages, and for the recipient, there needs to be the receiving server to “pull” messages from the sender and store them such as IMAP and POP3. While IMAP offers real-time synchronization between devices, it cannot access emails when you are offline. POP3 in contrast, allows you to download all receiving messages, and change and read them on your local device without an Internet connection.

Questions

Over to you, let’s check your knowledge of this article through some questions:

What are the primary components of an email service?
What are the differences between IMAP and POP3?
Can you list down some common SMTP commands and their meaning?

Evolving the Web: Discovering the History of HTTP Versions

June Dang — Mon, 24 Jul 2023 05:00:00 +0000

If you do not know, HTTP was around us for a bit of time and even older than you think. It is a core of the World Wide Web that allows web applications to communicate with the servers to render data into our view.

As modern technologies and the Internet continuously emerge and so HTTP has evolved time over time to meet the need of the Internet infrastructure and now encompasses five versions that have been introduced since its inception: 0.9, 1.0, 1.1, and 2.0, with a future version, 3.0, on the horizon.

In today’s article, let us explore the changes in each HTTP version and how each version solves its previous problems.

If you are looking for a deep-dive explanation of how HTTP works, feel free to visit here. No more talking, let us drive into exploring the versions of HTTP.

The Invention of The World Wide Web and The Hyper Text Transfer Protocol

HTTP (Hypertext Transfer Protocol) is a network protocol invented by Tim Berners-Lee between 1989 and 1991. (Note: Tim Berners-Lee is also the founder of the World Wide Web.) It operates on the client-server model, where clients send requests and servers respond with data for browsers to render into the user’s screen.

While we often celebrate the creation of the Internet and the World Wide Web, it is important not to overlook the silent hero that enables communication between websites: HTTP.

HTTP/0.9

The first version of HTTP was released in 1991 and with extremely limited features when compared to its descendants. The first version does not even have a name and later was called HTTP/0.9. Here are some basic features that were introduced with HTTP/0.9:

The one-line portal: The request is a simple line that calls directly to the resource. For example: /mypage.html
The first version only supported a single HTTP method: GET
Neither HTTP error code nor HTTP headers at that time. If there is a problem happen during the connection, a simple HTTP page will display for human understanding.
Because of no HTTP headers, the first version only supports pure HTML file content.

A request/response these days was something like this:

GET /index.html HTTP/0.9 

<HTML> 
This is the content of the index.html document. 
</HTML>

HTTP/1.0

As the need for the Internet moved from statistic/documentary websites to dynamic/content-based websites, HTTP evolved to fit that requirement and HTTP/1.0 was introduced in 1996 with many advancements from the previous one:

Headers: The golden feature that opens many opportunities for web development that supports a range of features like variation of file transfer with Content-Type, caching, and authentication.
Flexible data transfer: Clients and servers were now allowed to transfer multiple types of data through the Content-Type header: media, scripts, stylesheets, etc…
HTTP status code: Supported HTTP status code to check whether the request success or failed.
Versioning: Indicate the version of HTTP in the request (HTTP/1.0 was appended to the GET line).
POST method: Besides the GET method, an HTTP POST request was introduced enabling more complex interactions between clients and servers.

A common HTTP/1.0 request/response now looks more like the HTTP we see this day:

GET /image.jpg HTTP/1.0 

Host: www.example.com 

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) 

HTTP/1.0 200 OK 

Date: Mon, 18 July 2023 12:00:00 GMT 

Server: Apache/2.4.6 (Ubuntu) 

Content-Type: image/jpeg 

Content-Length: 5000 

<Binary data representing the image>

A major problem with HTTP/0.9 and HTTP/1.0

If you have read my previous article about how HTTP works, you know that establishing the connection between the client and the server requires the use of TCP protocol which employs a three-way handshake to establish a communication channel. Although this approach at first improves the reliability between clients and servers, it can lead to performance issues as every HTTP request triggers a TCP three-way handshake which is a time-consuming task. To optimize the performance, there needs to be a solution to reduce the number of TCP connections between clients and servers as fewer connections are created which means less wait time for the clients. This issue was addressed in the introduction of HTTP/1.1.

HTTP 1.1

HTTP/1.1 has been in the development process which is parallel with the release of HTTP/1.0 a goal that aims for standardized the HTTP protocol. And one year after the release of HTTP/1.0, HTTP/1.1 was introduced which improves server functions from its father while clarifying the ambiguities.

Reused connection: The connection now can be reused to execute several requests within a single TCP connection. This dramatically improves the performance of the new HTTP when eliminating the need to establish a new TCP connection for each request.
Host Header: HTTP/1.1 is required to include the Host header in the request which allows servers to handle multiple domain names using the same IP address enabling better server resource utilization and facilitating the hosting of multiple websites on a single server.
Pipelining: One of the new features of HTTP/1.1 was that it allows a second request to be sent while waiting for a response from the first one. This helps in reducing the latency of the connection.
New supported HTTP methods: This version added six new methods: PUT, PATCH, DELETE, CONNECT, TRACE, and OPTIONS.
Content negotiation: The new HTTP standardized which content will be exchanged by clients and servers.
Caching: Additionally, a bunch of new caching mechanisms were introduced such as the Cache-Control header, allowing clients and servers to control caching behavior more effectively.

18 years of improvement

HTTP/1.1 was such a game changer for the Internet that it works so well that even through two revisions, RFC 2616 published in June 1999 and RFC 7230– RFC 7235 published in June 2014, HTTP/1.1 was extremely stable until the release of HTTP/2.0 in 2014 — Nearly 18 years later. Before continuing to the next section about HTTP/2.0, let us revisit what journey HTTP/1.1 has been through.

The introduction of HTTPS for better web security

One of the most significant improvements of HTTP was the introduction of HTTPS. In 1994, Netscape Communications bring out the concept of an encrypted transmission layer on top of the HTTP protocol. Following that was the development of HTTPS protocol which utilizes the SSL (Secure Sockets Layer) protocol to encrypt data into binary code, ensuring secure communication and preventing unauthorized interception of data transmitted between HTTP connections.

As the Internet grew in users and traffic. Websites are no longer just academic networks but more like the jungle. And so, the need for an encrypted transport layer became paramount. The success of SSL demonstrated the importance of securing online communication which then formed the creation of e-commerce websites. Over time, SSL evolved into TLS (Transport Layer Security), which is now the industry standard for securing web communication.

The creation of RESTful API

In 2000, a new concept called representational state transfer (or REST) was introduced for HTTP. The story begins with Roy Fielding’s doctoral dissertation, where he introduced REST as an architectural style that provides a set of principles for designing networked applications. The key characteristic of REST relies on making requests to specific URIs using basic HTTP/1.1 methods to access or update resources.

This approach quickly gained popularity due to its simplicity, scalability, and widespread adoption of HTTP as a protocol for web communication. REST provides a flexible and interoperable means for different applications and systems to communicate and exchange data. In fact, during the 2010s, RESTful APIs became so commonly used that they became the standard choice for web developers when building web APIs.

Cross-Origin Resource Sharing

With the birth of HTTP/1.1, web development emerges a surge in dynamic websites, powered by JavaScript, which enables client-side rendering and API calls from the client to the server. However, this shift also exposed potential security vulnerabilities in HTTP requests.

To overcome these concerns, it is important to address some of the constraints on which client domains were able to access the server’s resources. And so, two essential mechanisms were introduced: Cross-Origin Resource Sharing (CORS) and Content Security Policy (CSP).

Head of Line issue of HTTP/1.1

In HTTP/1.1, requests can run in parallel, and one TCP connection can handle multiple HTTP requests. However, the handling of each request occurs sequentially. This means that as the number of HTTP requests increases, subsequent requests will have to wait until the previous requests finish processing. Consequently, this scenario can lead to head-of-line (HOL) blocking, wherein a slow or large response from the server hinders other smaller, quicker responses from being sent to the client, causing a bottleneck in the connection.

HTTP 2

Accounting for the drawback of HTTP/1.1, during the 2010s Google was developing an experimental protocol called SPDY that allows more effective data transmission which then serves as the foundation of the HTTP/2 protocol in 2015.

As mentioned earlier, the main goal of HTTP/2 is to improve the performance of its previous version, which implements the following features:

Multiplex connection: HTTP/2 eliminates the HOL problem with multiplexing and allows clients and servers to send multiple requests and responses on a single TCP connection.
Binary protocol: instead of a text-based format like HTTP/1.1, HTTP/2 is a binary protocol making it better at parsing and processing data.
Header compression: to resolve headers that got duplicated when sending massive HTTP request, HTTP/2 compresses request and response headers which removes the duplication and improve the efficiency of the overall size of HTTP requests and responses.
Server Push: HTTP/2 introduced the server push mechanism that allows servers to initially send the resources to clients and store them in the client’s cache without waiting for clients to send requests.
Stream Prioritization: HTTP/2 allows clients and servers to assign priorities on a batch of requests which we can control the order of expected responses. This prioritization helps ensure that more critical resources are delivered first, improving user experience and page load times.

With the adaptation of modern technology, HTTP/2 steadily reduces the number of TCP connections when compared with its predecessor.

As a result of the significant performance improvements, an increasing number of websites are shifting towards adopting the HTTP/2 protocol. According to the HTTP Archive report in 2021, approximately 60% of web pages are now using HTTP/2.

HTTP 3 – Delegation to QUIC protocol

As HTTP has evolved for around three decades, its core client-server connection protocol is still the same. In the next major version of HTTP, HTTP/3’s first draft version is to overcome the use of TCP but instead replace it with QUIC (Quick UDP Internet Connections) protocol which is proven more efficient in reducing latency, improving congestion control, and offering better error recovery.

Just like TCP, QUIC is multiplexed but the key difference here is that QUIC runs over UDP protocol. UDP is simple, lightweight, and faster than TCP but has a drawback of data reliability and security. Thus, to compromise with this issue, QUIC also implements a higher-level feature of packet loss detection and retransmission independently that dramatically decreases the effect of packet loss where one packet of information does not make it to its destination, it will no longer block all streams of information.

Another advantage of HTTP/3 is that it differs from HTTP/2, which still relies on HTTPS for security connections. Meanwhile, HTTP/3 always establishes encrypted connections through the integration of the TLS security protocol.

The Future of HTTP

With the new introduction of the latest versions of HTTP, the future of HTTP aims for better web performance, default encrypted security connection, and higher user experience. For now, HTTP/3 is still in the standardization process, but soon more websites and applications are likely to transition to this new protocol. As of 2022, 26% of websites have already used HTTP/3.

Questions

To get the most out of this article, feel free to complete these challenges👇:

🐣Easy mode:

What is the current HTTP version used for your project?
Since when has HTTPS been in use?
🔥Hard mode:
What main aspects allow HTTP/3 faster than its predecessor?

References

Instagram Threads is not a Twitter clone – here’s why

June Dang — Sat, 15 Jul 2023 03:00:00 +0000

Last week, Meta introduced Threads, a new social media platform that aims to compete with Twitter by leveraging Instagram’s account system. However, concerns have been raised, including by Elon Musk, regarding potential threats to freedom of speech due to centralized control of data under Mark Zuckerberg.

Many even think that Threads is just a clone of Twitter and even Elon threatens a lawsuit against Threads for violating Twitter’s “intellectual property rights”.

What is all this about?

Just like Twitter, Threads is a text-based content application with main features focused on posting short content, liking, and sharing it over the platform. In fact, Threads hits 30 million users within a day making it the fastest application to hit the first one million users.

But with features like Twitter, what secrets have made Threads become so popular? And does Threads a copycat of Twitter?

Threads visions

Our plan is to make Threads part of the fediverse, a social network of different servers operated by third parties that are connected and can communicate with each other. Each server on the fediverse operates on its own but can talk to other servers on the fediverse that run on the same protocol. We plan for Threads to use a protocol called ActivityPub to talk to other servers that support this protocol.

Said on the help center of Instagram Threads.

Clearly see that in the notice of Threads on Instagram’s help center, the application vision is to focus on making what is called “Fediverse”. This term seems strange at first and somehow sounds familiar to Metaverse – A somehow failed vision of Mark in the past due to overhyped.

What is “Fediverse”?

The Fediverse, short for “federated universe,” is a decentralized network and online communities where thousands of independent social media platform servers connect and talk with each other using common protocols and standards.

In the Fediverse environment, each server is an instance and in this instance, users can create identities that can then be used to communicate across the border of the instances that support the same communication protocol. The key important feature here is that “Fediverse” focus on the data you own whereas decentralization is a matter that your data will not be fully controlled by centralized organizations.

Just imagine Fediverse is like you transfer money to your friend, although different banks have their own business and technology behind them, the money transfer between them is the same because they are using the same transfer money protocol.

An arrival of Threads in the “Fediverse” world

At launch, it was, like Twitter before it, a walled garden; a Threads account only allows for posting and reading content on Threads. But, Meta promises, it won’t be that way forever. Threads customers will eventually be able to interact with other platforms in the so-called fediverse like Mastodon (an open-source Twitter replacement) and vice versa by planning to adapt ActivityPub – An open internet protocol that implements the idea of “Fediverse”.

So what is the meaning of all this?

Imagine one day Threads is shutting down and you are on the edge of losing all your followers and content you have spent years building on this platform. But with the help of the implemented ActivityPub protocols, you can just bring all your data and your followers to a different platform. Right now, two of the most popular platforms that support ActivityPub are Mastodon and WordPress. By having the support of ActivityPub protocol, users are more control over their data and free of speech ability which then can make the social network a more open place.

With the joining of the Fediverse, Meta aims to improve the inter-social network that allows them to connect to more users through different platforms which then breaks the border between independent applications. This would enable cross-platform communication and allow Threads users to connect with a broader network of users beyond just the Threads platform itself.

With every social network, data privacy is a crucial part of its users, and through Fediverse, users have more control over their data, what they want to share, and which people they want to connect. This reduces the dependence of users on centralized platforms that use users’ data for the wrong purpose. Furthermore, this opens the capability that users can create their personal servers to store and keep safe for their data.

Groups and communities take an important part in social media. And just like Fediverse, Threads could foster the development of niche communities by allowing users to create instances or communities with their own rules and moderation guidelines. This decentralized approach could encourage diverse communities to form, each with its own focus, interests, and user base.

What is the downside?

For now, all the feeling of using Threads to me is exactly like people said: “like a copy of Twitter”. And while the “decentralized” vision sounds fancy but while ActivityPub is an open networking protocol, Threads is still a platform owned and controlled by a centralized company and thus there is no guarantee your data will not be gathered by Meta every time you use Threads.

If you like the idea behind Threads and the vision of “Fediverse”, write the comments below if you like me to make a post about how ActivityPub works.

What is HTTPS and how does it work?

June Dang — Tue, 11 Jul 2023 03:10:00 +0000

Have you ever wondered how websites communicate with a web browser and request data to the server to render into view? I used to ask those questions too.

If you are like me, curious about how the Internet work then you come to the right place. In this article let’s discuss how HTTPS works and how essential its role is to the World Wide Web.

What is HTTP?

The first step to having an understanding of HTTPS is to know its ancestor: HTTP. Hypertext Transfer Protocol (HTTP) is a common protocol for communicating between websites and browsers throughout the Internet. With the help of HTTP, all the information and connection of the entire World Wide Web are formed, and it is not a lie to say that HTTP is the major factor that backbone to the creation of the Internet we are using today.

HTTP requests and responses

HTTP is a request-response protocol, in which HTTP requests are sent from the client and server to handle those requests and respond to the client’s HTTP responses. Typically, a Transmission Control Protocol (or TCP) is used to form the connection between the HTTP client and server.

HTTP request

HTTP requests are sent from the browser to ask specific information to the server it needs to render into view for the user’s device. Each HTTP request contains the following important information:

HTTP version.
The client hostname or URL.
The HTTP method.
HTTP request header: Includes information like which type of data the client wants the server to respond to, what kind of browser the current user used, etc.
HTTP body: In case the client wants to submit data, otherwise this is optional.

HTTP response

When the server finish handling the request of the client, it replies with an HTTP response which includes the following information:

HTTP status code.
HTTP response header.
HTTP response body.

How HTTP works?

A common HTTP communication between clients and servers will be taken by the following steps:

The user enters the domain name, such as junedang.com, into the browser.
The browser acts as the client and sends a “GET” request to the server that hosts the specified address.
The server receives the request and analyzes the desired response from the client. This could include various types of data such as media, JSON, HTML, CSS, etc.
The server sends back the response to the client.
The client (browser) receives the response from the server and proceeds to render or execute the content based on the requested information. These steps demonstrate a common illustration for a GET HTTP request. In reality, HTTP supports many methods for clients to send requests. Each supports a specific type of purpose. Some of the most common HTTP methods include:

GET: Retrieves data or a web page from a server.
POST: Submit data for processing. Usually used in form submission.
PUT: Sends data to the server to create or update a resource.
PATCH: Sends partial data to update an existing resource.
DELETE: Requests the server to delete a specified resource.

The disadvantage of HTTP – Why we need to secure our HTTP requests

Although very important to the Internet, the original HTTP still suffers from security issues due to a lack of these abilities: data privacy, integrity, and identification.

Data privacy

HTTP communication is not encrypted and because of that, data transfer through the Internet by HTTP is not secured and can be easily eavesdropped by bad factors. This is extremely dangerous to the users, especially with sensitive information like login credentials, personal data, or bank details.

Integrity

The data sent between clients and servers using HTTP are unencrypted and so can be tampered with or modified without detection. Lack of integrity means data can be changed in the middle of the transmission which can lead to misunderstanding of information. With HTTP, there are no built-in safeguards to verify if the data remains intact and unaltered during transit.

Identification

HTTP is purely all about data transfers and communications but cannot verify the identity between communicators. This can open to potential impersonation attacks like man-in-the-middle.

What is HTTPS?

To get rid of HTTP downsides, an HTTPS protocol is introduced which stands for Hypertext Transfer Protocol Secure. It extends all characteristics of the old boy HTTP with added effective security layer using Transport Layer Security (TLS) for data encryption.

Before HTTPS, the transferred data somehow looks like this:

GET /HTTP/1.1
Host: www.junedang.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml

The informations are all shown through the eyes of the attacker. Now with the help of encryption using HTTPS, the data is encrypted and looks like the below:

bG9sZWNoYXV0aDpteXNlY3JldHBhc3N3b3JkCg==

With this approach, data is secured from being eavesdropped or captured during transferring – if the attackers have hijacked the data, all they receive are just encrypted binaries. Furthermore, HTTPS attached a digital signature of the domain to the transferred message which can ensure the identity of the receiver you would expect.

How HTTPS works?

As mentioned above, HTTPS works exactly the same as HTTP with an additional security layer called SSL. SSL is based on a technology called public key cryptography: the server stores the private key while the public one is shared with the clients through SSL’s certificate. The flow of how HTTPS works can be illustrated by a diagram below:

The client (web browsers or mobile devices) establishes an HTTPS connection with the server using https:// instead of http://.
The connection is established, and a TCP connection is formed between the client and the server.
The client and the server exchange the SSL information through a three-way handshake. If the SSL version is supported by both client and server the server sends an SSL certificate to the client which contains the following information: the public key, hostname, expiry dates, etc.
The client validates if the certificate is issued by a trusted Certificate Authority (CA) and has not expired or been revoked.
After successfully validating the certificate, the client generates an encrypted session key using the public key.
The server receives the encrypted session key and then decrypts it using the private key.
Now both the client and server share the same encrypted session key. A secure connection can be established then.
Encrypted messages are transferred in a bi-direction security channel. Through this process, HTTPS ensures the three security pillars that were missing from the HTTP protocol: data privacy, integrity, and identification.

Conclusion

HTTP is one of the most important technologies to form the Internet through establishing the connection between clients and servers for data transfer. But HTTP is lack security factors that can cause serious problems to end-user related to data privacy, integrity, and identification.

To overcome those problems, an HTTPS protocol is created to ensure the communications between clients and servers are safe and secure.

To get the most out of this article, feel free to complete these challenges 👇:

🐣Easy mode:

Check your current organization’s website to see if they are using an SSL certificate or not.
What is the information that is stored in an SSL certificate?

🔥Hard mode:

Can you list down a step-by-step on how to create a trusted SSL certificate?

How to build the culture of delivering clean code

June Dang — Mon, 03 Jul 2023 02:30:00 +0000

If you are working on the development team and in charge of managing multiple source codes, It’s crucial that you treat those codes with the utmost care to keep everything on the go. And then over time, the project gets larger and larger and so does your teammate. Now maintaining the cleanness of the codebase can be a challenging and time-consuming task since new joiners with different skills and mindsets can bring a difficulty to the onboarding of delivering code.

Because of that, building a culture that emphasizes the importance of clean code at the beginning is crucial that can ensure the long-term success of your team.

The idea of this article is to list out best practices to follow so that every member of the development team can count on building a culture of keeping the code clean.

Why you should keep the code clean?

Imagine you are a junior developer who doesn’t know about clean code and you’re working on a functioning system that is being maintained clearly by dedicated developers from your team. Now your manager demands you to give some implementation to the new feature. With your skills, you can then easily implement it and deliver the code on time but because of lacking knowledge about clean code you are unintentionally delivering the unstructured code – which creates a technical debt.

As time passes by, the code you delivered on that date started to propagate and infect the chaos to the system through imitation of other newcomers. Consequently, each subsequent change brings more costs and risks to the project which result in rigidity, fragility, immobility, and lower resilience.

Just like the “Broken Window” Theory which states:

“Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters or light fires inside.”

So what do we learn from the “Broken Windows” Theory?

The theory suggests that when one bad behavior happens in a clean and nice place without immediate action to correct it immediately, things can turn bad really quickly as a broken window without fixing is a sign of breaking rules without consequence. When applied to software development, the story gets more straightforward as if someone left the code unstructured without intending to fix it, this can cause the root of entropy within the system and the final result can be the collapse and pull out of control of the entire project which can cost billions every year.

Detect red flags on your codebase

Since software development is very complex and requires insane detail in craftsmanship skills, the border between clean and functioning features and the rotted ones is hanging on the behavior of developers who maintain that features. For a feature to start running out of control, there are multiple factors which will be listed below:

1. Neglect developers

To start the list, I should mention that every failed system is not backed by technical aspects but mainly because of human decisions. Perhaps, this is the most common and sadly the fastest way to destroy the project. No one likes a person who does not want to be responsible for his/her actions.

In software development, if it is not a personal project then you are likely to work with many people then cooperation and communication take key factors to success but these are the people who think their time is so precious that take a look again at what they have written just not worthy – all the entropy comes from this kind of mindset. Avoid this and accept it. No one can write perfect code in a single try.

2. Over complexity

Sometimes, developers just want to prove they are Tony Stark in the software development field.

I am a 10x developer baby!

And what do they do? Replace the three lines of code with a single nested line with the weird-looking niche syntax of the language you write in. Of course, this approach will confuse the readers, which leaves them with more questions than understanding what you want to deliver. But who cares – The important is you are feeling like a genius right? (Nope)

Overengineering a simple solution will not prove you are a genius. It just verifies the fact that you are not understanding the human factor in software development but rather undermines code quality and maintainability.

3. “Let’s guess what this variable means”

For me, one of the most difficult parts of being a programmer is thinking of the name of variables. Good naming variables or functions can easily tell the story to readers about what they are doing. In contrast, bad naming causes it harder to read and even takes longer to understand.

Reading code with poorly named variables is like playing a guessing game where readers have to take all the clues that you are scattered over the source code and piece them together just to understand what you want to do in the feature.

Of course, usually, your bad naming behavior will be stopped during the coding review but let’s be honest: why start the argument that takes time when you can simply just follow the naming convention?

4.Duplication, duplication, and duplication

What is important should be shouted out three times. Repeated code can be tempting and maybe you think your code is so supreme that it should exist in multiple places around the entire project. However, just thinking of the consequences when one day the feature’s requirements change and you are in charge of updating those “supreme” codebases?

I am telling you what will happen then: you are likely to miss one or two places of the copied code which is then forced to scan again and fix the second or may third round. This I do not even mention the headache of multiple people joining the task to scan and fix the problem. The time and effort required for this task are not to be underestimated.

Abstractions are challenging and time-consuming but it is worth your time to spend on future maintenance.

Best practices to build the clean code culture

1. Clear definition of clean code

The first and foremost step when you want to create something is to have a clear definition of it. Structuring in source code is a wide area and so it is important to list out how clean the code should be taken care of seriously among members of the development teams to share the same understanding of what constitutes clean code and what goal you want to achieve.

Inspire on popular coding best practice patterns can be good resources for you to define your own version of clean code such as SOLID, DRY (Don’t Repeat Yourself), and KISS (Keep It Simple, Stupid), etc….

2. Code reviews

What is the intent of your code? Show me!

Developing a culture needs community interaction and a code review session is one of those. Usually, a code review activity should have the involvement of two members of the development team where one of them is not the code’s author. Managers of development teams should encourage their developers to code review and send feedback before any changes are delivered to production. Through those activities, a combination of these goals can be achieved:

Code quality: People are more careful when sending code to review because they know someone will watch and if the quality is not good then they can be humiliated.
Detect defect: A study of the Cisco Systems Programming team has revealed that a review of 200-400 LOC over 60 to 90 minutes should yield 70-90% defect discovery.
Learning opportunity: When joining reviewing session, both reviewers and the author can learn from each other the solution for a better way to ensure adherence to coding standards.

3. Continually Improve codebase through refactoring

It is a lie to say that the code we deliver will always be perfect. Sometimes, there are moments when the deadline forces us to rush to release one final feature before the scheduled date comes. And these are the time our code mostly will not be in the best shape. Just sometimes, sloppy codes are inevitable. But this is not meaning that you should ignore or tolerate them.

If you find yourself in a situation where clean code is challenging with time and cannot dedicate enough resources to it, just prioritize the demanding feature ahead but keep notes or comments where you leave unstructured code for future refactoring.

Additionally, a regular checkup can be worth a try to keep the code clean and reduce the impact of possible rotten code. Remember, even when you do not always achieve perfection in delivering code, a mindset of striving for a cleaner codebase can be helpful for the productivity of your team in the long time run.

Every time you are in an area of the code doing work, always leave the code a little cleaner, not a little messier, than you found it. - Uncle Bob

4. Enforcing coding standard

Although a clean code delivery mindset should be trained and improved continually between developers, we are humans who are born to make mistakes. Because of that, Guarantee the code generated by humans is perfectly aligned with coding standards or not is challenging. Therefore, in order to achieve consistency in coding style throughout the system require further implementation of automation tools for detecting common mistakes so that they can provide developers with quick feedback as soon as possible without waiting for human interaction to detect the problem.

Common used automated tools to identify bad practices you can consider using like Pylint for Python, ESLint for JavaScript, etc… if you are using CI/CD then consider integrating those tools into your pipeline to check for coding standard violations during development workflow.

5. Reward Clean Code achievements

For a human to get motivated and drive into action, there are two ways: through necessities or rewards. The same behavior can be applied to clean code best practices to encourage the success rate of structured code that got delivered and reduce the violation of coding standards.

Recognizing and appreciating developers for their effort to keep delivering clean and structured code can help them take pride in their work which then improves and propagate positive culture to the whole organization.

How much clean code is enough?

While it seems clean code should be a go-to approach that every software developer should follow, it is obvious that always keeping the code clean in every line you write can lead to the headache of burnout because of perfectionism behavior. Nothing is perfect and so in your project, there is always something not right and if you too much focus on immediately fixing the little detail that makes you unhappy – you are likely to miss the deadly which can trade with monetary compensation.

In reality, the concept of how “clean” your code is can vary and depend heavily on your team’s agreement. While keeping the code structured is important, one should consider other factors which can affect the project’s success such as time constraints, resource availability, specific requirements, and the collective skills of team members.

Try seeking the balance between other factors with keeping the code clean and should avoid too focus on perfectionism. Instead, if you see something not clean enough but acceptable to deliver, consider leaving comments for future refactoring. Finally, all I want to say is:

“A great software should be adaptable and prepared for future changes in both the business and its definition.”

To get the most out of this article, feel free to complete these challenges 👇:

Does your organization strive to deliver a clean coder culture or not? If yes, what is the current approach that keeps developers on track with clean coding of your area?
Do you believe that clean code is solely the responsibility of individual developers, or should it be a collective effort within a team or organization? Why?

Single Sign On protocols: SAML vs OpenID Connect

June Dang — Fri, 23 Jun 2023 15:01:00 +0000

Single Sign On (SSO) is a centralized authentication solution that allows users only use a single login and credential to access multiple applications that trust the SSO protocols within the system. This solution is more and more get implemented by organizations since it improves user experience when working with a system that has multiple applications that share the login user data.

Two of the most common protocol that implemented SSO is SAML (Security Assertion Markup Language) and OpenID Connect (OIDC). At first look, they are both performing the same functionality but they are quite different. Each will fit the specific requirement of your organization and distinguishing between them is crucial if you want to pick one that aligns with your organization’s needs.

In this article, we will discover the difference between SAML and OpenID Connect by exploring their commons, their unique characteristics, and what requirements fit each of them. After this article, we expect you to have the needed information to decide between choosing SAML or OIDC for your SSO service.

How SSO works?

Typically, SAML and OpenID Connect are both SSO protocols and so they share the same behavior of Single Sign On authentication flow. At its backbone, SSO works by forming a trusted relationship between applications – known as service providers and SSO authentication portals – known as identity providers. The SSO authentication flow can be illustrated by the diagram below:

How Single Sign On (SSO) works?

The user enters domain 1.
Domain 1 redirects the user to the SSO server for an authentication request. The user enters the login credential and requests authentication. This step may require multi-factor authentication (like OTP code) for security purposes.
After successfully verifying the user, the SSO system generates a unique token to represent the user’s login session.
The user then being redirected to Domain 1 along with the authentication token. Domain 1 then uses the token to communicate with SSO to check if this token is valid. This is the step where we will implement using SSO protocols like SMAL or OIDC.
SSO server returns to the service provider whether the token is valid or not.
If the SSO system tells Domain 1 that the token is valid, then Domain 1 can trust the user and return protected resources to render into view.
If the user navigates to Domain 2 which is within the same system, the same behavior as above. Domain 2 redirects the user to SSO for authentication.
This time SSO noticed that the user already logged in and so return the token without having to enter the credential again. The user being redirected back to Domain 2
Domain 2 accepts the authenticated token and returns protected resources.

How SAML works?

The Security Assertion Markup Language is the standard for transferring authentication data between two factors: the identity providers and the service provider. SAML is based on markup language and supports XML to transfer data.

SAML is using the legacy browser-based approach for authentication which is an HTTP POST request and redirects to the authentication site. After the authentication process is completed, A SAML assertion will be sent from the identity provider to tell the service provider that a user is logged in and signed.

SAML assertion contains all the necessary data for the service provider to confirm who is logged in, what is the authentication source, the assertion’s valid time,etc…

How OIDC works?

OpenId Connect is the SSO authentication protocol that extends the OAuth modern web authentication using RESTfuls API by exchanging JSON Web Tokens (JWTs) to share login information between applications. And like SAML Assertions, JWTs contain all the needed data information for the service provider to validate with the identity provider whether the requested user is valid or not.

OIDC is simple and straightforward to implement because it is based on familiar web components like API and JSON data so that developers can easily adapt. Furthermore, OIDC is extremely flexible and scalable in authentication flow that supports multiple authentication flows like: Authentication code flow, Implicit flow, and Hybrid flow. Because of that, OIDC can both support browser-based and mobile-based authentication.

The Differences between SAML and OIDC

Feature	OIDC	SAML
Technology	Extends the OAuth authentication flow and exchange data using JSON format and RESTful API	Based on the XML messaging format
Authentication flow	Supports vary of authentication flows: Authorization code, Implicit, Hybrid	Only supports POST redirect request
Complexity	Easy to implement and understand	Can be more complex due to XML format
Use cases	E-commerce applications, social networks, mobile authentication	Enterprise SSO, federated identity
Data exchange	Using JSON Web Token	Using SAML Assertion

Conclusion

In this article, we have learned about how the SSO system works and the difference between its two popular protocols: SAML and OIDC.

SAML is based on markup language and supports XML which is more complex than OIDC. In contrast, OIDC extends the modern authentication model OAuth and supports familiar RESTful API with JSON format to exchange data that is easy to understand and implement.

To get the most out of this article, feel free to complete these challenges 👇:

What is the SSO authentication protocol your organization currently uses?
What is your favorite login method?

What is Single Sign-On and Why do organizations should use it?

June Dang — Mon, 12 Jun 2023 08:30:00 +0000

Imagine one day you just bought a new laptop and have to run all the necessary setup before making it work as you expect. Now because all the setting on this laptop is new, you have to manually sign in to countless websites and applications you use daily. This process is tedious and can take hours to get all the things done, not to mention the headache of managing multiple long and forgettable passwords you use to log in to those sites.

Lucky for you, Single Sign On (SSO) was born to solve this problem and make your life more convenient. But what is SSO and Why does it help you solve the above problem? Let’s discuss this topic in today’s article.

What is Single Sign On(SSO)?

Single Sign On is the centralized authentication service that allows users to use a single login credential to access all the applications within the system. This means, users only have to log in once and all the access to other applications is automatically signed without manually signing in again.

SSO works by performing a single authenticate domain for the initial login of users and then establishing trusted connections with the marked signed-in user by exchanging a signed certificate between SSO and applications. When a user goes to on domain that necessitates login to continue he then automatically is redirected to the authentication domain. If he has already signed in to one of the applications within the system then SSO will share that information with the requested application. And as a result, the user can access the service without the need to log in again.

How organizations can benefit from the use of SSO

Usually, organizations tend to implement multiple internal services for their specific purposes. And sooner or later they all face one challenge:

Many services should share the same authentication information between them. Then because the login information is the same, the authentication process should be considered simple enough for users to easily work when navigating between domains within the system.

Implementing the authentication process using SSO is crucial in this scenario. By having a central domain for authentication, SSO not only solves the problem of sharing login data between applications but also improve overall productivity by reducing the time-consuming of login multiple time for users.

Furthermore, SSO is centralized means that organizations have a single point to manage and monitor their security data like user access, role control, etc… The centralized nature of SSO simplifies the process of monitoring and investigating security events.

Best practices for implementing SSO

The implementation of SSO may vary based on the need of your system and your organization. There are many SSO providers that each fit a specific purpose, two of the most common SSO protocols out there is SAML (Security Assertion Markup Language) and OpenID Connect.

Here is the checklist for you to consider when implementing SSO:

Objectives: Define clearly the purposes of your SSO and the goal you want to aim for when implementing it like: What problems do you want to solve using SSO? Which type of users your organization serves?
Infrastructure: Do you host your SSO service on-prem or through a cloud service provider?
Security: Which services do you enable using the SSO solution? Multi-Factor Authentication may be a good approach for an extra security layer.
User management: Consider having a broader Identity and Access Management (IAM) Strategy from the SSO base which helps manage overall access control, role-based access, user provisioning, and user life-cycle.
Scalability: Your SSO plan should consider the accommodation to grow within your system over time.
Accessibility: To allow communication between backend services, check if you need to have API for your SSO service.

Challenges you will face when implementing SSO

Convenience for users like that but SSO still has its drawback such as:

Security risk: Once an attacker takes control of your account, he can grant access to all of your daily applications that your account has access to. A Multi-Factor Authentication solution should be implemented to reduce the risk of account stealing.
Role-Based Access Control and Flexibility: If you have multiple applications and each of them require a unique access policy. Then, SSO may not be the right way since it has limited control over access roles for individual applications.
Single failure point: SSO is a centralized authentication service means it is not designed for fault-tolerant purpose and so it can easily to vulnerable and become compromised which result in users losing access to all the applications within the system. Monitoring failure service should be considered to prevent any failure in the system.

Conclusion

In conclusion, Single Sign On is a great technology for organizations to solve the challenge associated with the user experience of accessing multiple applications within an organization’s system. And although has some drawbacks like security risk and single failure points, implementing SSO with best practices such as Multi-Factor Authentication and Monitoring System can help you overcome those concerns.

To get the most out of this article, feel free to complete these challenges 👇:

Does your organization use SSO for the authentication process? If not, do you consider recommend to use it?
If yes, what is the SSO implementation you are currently using?

How to get out of coding monkey and become a software engineer?

June Dang — Fri, 09 Jun 2023 12:27:33 +0000

We as developers are love to code - that's a good thing. However, too much focus on technical in the business aspect maybe not that great. Nowadays, standing out as a developer within an organization requires more than just core technical skills. And if not recognize this aspect, one can easily falling into the trap of the infinite loop of mindlessly taking orders and coding without further growth.

In your opinion, what additional skills do developers need beside technical perspective to become software engineers?

It requires more than just coding for a software engineer

June Dang — Thu, 08 Jun 2023 03:30:00 +0000

If you’re a developer like me, it’s likely that you have a deep passion for coding and problem-solving. You can spend hours engrossed in your work, sitting in one place, contemplating complex problems, and using your coding skills to find solutions. This is when you enter your focus zone and experience your most productive sessions.

However, the life of a programmer is never easy. You might believe that your code will change the world, but the reality often falls short of our lofty expectations. As developers, we understand how to write code and we excel at it. But those who can write good code while also bringing value and effectively communicating with clients are the ones who shine.

“But the company pays me for my code, doesn’t it clear I should focus on technology?”

You might argue. It’s natural for developers to be passionate about technology and coding. We constantly strive to learn more about new technologies and frameworks. As a result, we often rush into the coding process without considering the business and human aspects involved.

But from a business perspective, your code is merely a tool that helps clients achieve their goals. It takes more than just your code to help clients reach their business objectives. You need to understand the bigger picture, the purpose behind the project, and how your code fits into the client’s overall strategy.

The mistake of beginners

At first, when you are just a beginner and trying to learn your first programming language, things are so difficult then when you have to follow the tutorial, start the project then trying to write and understand each line of code. Remember back then, everything is all about coding – and you didn’t pay much attention to clean code practices.

Then, you land your first job and everything changes quickly. You are driven into the existing codebase where all complex business logic and internal-enterprise framework are there for you to explore. You now have to learn and understand all this logic while trying to add some lines of code and hoping they will not break anything.

And the story does not end there. When you finished the task and are ready to deliver the code. The compiler suddenly throws the warning at your face saying: “This function only allows x lines of code”. Oh great! So now you are not only forced to understand the codebase, but you also must follow your company’s coding policies in order to keep all the source code as a whole.

New developers often become overwhelmed and frustrated when transitioning from learning basic programming skills to entering the real world of enterprise development. They never thought being a software engineer will be that hard.

But the harsh truth is, this is how software engineers belike and the core of our job is not writing code. Our role requires us to solve real problems using code as our tool.

Every developer knows how to build stuff. But the one who can build programs that bring tangible values is called software engineer

How to survive and become a professional software engineer?

Coding styles, scalability, and readability

Often, when you are a junior developer. Your job is to make the code work and that’s all. And that mindset will stick with you for a while (at least in your first year as a developer). Typically, junior developers don’t often follow common coding conventions.

Junior developers tend to focus more on technical aspects rather than human cooperation and communication.

So what can we learn from mature developers who understand their code not only for machines to run but also straightforwardly that allow anyone can understand?

Good software engineers think differently from beginner developers. The code they write will always follow clean code conventions, straight directly to the business point while keeping them on readability and maintainability.

The biggest mindset between a coder and a software engineer is that the engineer knows deeply about cooperation and their code should be responsible for the bigger purpose that serves business value and help people who work with the codebase easy to understand and maintain it.

Macro vision

Tasks assigned to junior developers tend to be simple that have a low impact on the whole system. They lack the macro vision of the whole system level and thus don’t often bring any design or architecture solution.

Meanwhile, a software engineer has the mindset of craftsmanship. They know behind every successful system is a good design from the architecture. Experienced software engineers approach their work with a holistic perspective. They consider the long-term implications of their code and how it fits into the larger system. They aim to create clean, modular, and scalable solutions that align with the overall architecture. Furthermore, as they have more knowledge about how each architect’s solution work and runs, they are more actively contributing and bringing better solutions to help improve the performance and quality of the whole system.

Communication and cooperation

Besides programming skills, the distinction between an immature developer and an expert software engineer can be observed in how they collaborate with their team members.

Junior developers are inexperienced and lack knowledge from a business perspective behind the tasks that are assigned to them. Typically, this can lead to frustration at first for them and sometimes leads to silly questions after the meeting is finished. As a result, they often rely on more experienced team members to clarify and discuss the requirements further.

A software engineer knows what meeting they are attending, and what discussion they are following and can ask the right questions that validate and complete the requirements. This helps client consolidate their assumption requirements while bringing a clearer understanding for the development team to effectively implement the desired features.

An expert software engineer recognizes the value of effective communication and actively engages in discussions to ensure alignment between the client’s needs and the development team’s understanding. They can extract the necessary information from meetings, proactively seek clarification, and contribute insights that drive the project forward.

Shift the mindset

While all the technical aspects one beginner developer can easily learn and understand from time to time, having a mindset from a coder to an engineer can drastically improve your career. So consider the following points:

Pay attention to your purpose: Before driving into code anything, stop for 5 minutes and ask yourself: “Why am I implementing this feature? What value does it bring to the clients”.
Embrace Legacy Code: Don’t criticize the old code, if it works well and serves its purpose, there may not be an immediate need for quick changes. Instead, focus on maintaining and improving the codebase time over time.
Keep your code changes manageable: When modifying code, it’s important to keep the changes small and at least as impact as possible. This approach makes code reviews more manageable and ensures that changes can be easily shipped to production.
Pool of solutions: There is rarely a single, straightforward “correct: solution. Consider some alternative solutions in case the first attempt fails.
Consistency code: Consistent and well-structured code makes collaboration easier and enhances the maintainability of the project. Paying attention to code quality while following the organization’s coding standards is crucial.
Continues learning: Technology is huge. Therefore having a mindset of the mindset of continuous learning, and staying updated with the latest tools, frameworks, and best practices should be embraced.

Conclusion

While any developer can write code and create software. A good developer has an engineering mindset that extends further than just the technical aspects. He understands cooperation to solve problems should be taken care of while using his skills and experience to bring value to clients through system-level decisions.

And while Junior developers may not yet fully grasp the business value and focus more on the technical factors. Continually learning and following an engineering mindset over time can both enhance their technical and cooperation skills effectively.

Getting Started with Docker Containers: Basic Commands for Building and Deploying Your Application

June Dang — Mon, 29 May 2023 13:54:51 +0000

In our last article, we have discovered what is Docker, how your system benefits from it, and how it works. In the following article, we will discuss the implementation of Docker with hands-on example code from creating Docker Image using Dockerfile to basic commands to run a simple to-do-list application on Docker.

To get the most out of the context of this article, feel free to read my previous article to get a brief understanding of what is Docker and its architecture.

About Docker

Before diving into hands-on examples, for people who first visit this post or people who want to re-check their knowledge of Docker, let’s first check again what Docker Container is.

Docker is a containerization platform that allows applications and their dependencies to be bundled into lightweight containers that can run consistently across different environments. Among all containerization technologies, Docker grow as the best option for developers and enterprises to containerize their applications due to the following factors:

Ease of use: Docker has a user-friendly and easy-to-learn interface that helps manage containers without too much worrying about remembering all the necessary commands making it accessible for both developers and administrators.
Portability: Docker supports all popular OS like Windows, MacOS, and Linus. Furthermore, you can easily run Docker in any environment from the data center to the cloud.
Large Ecosystem: Docker has a massive user base and ecosystem which support all your needed packaged containers through accessing Docker Hub public registry.
Lightweight: Be leverages OS level kernel, Docker does not require OS on each bundled application to run which improves server performance with better start-up time.
Isolation & Security: Each Docker container is highly isolated from the others allowing applications decoupled and run with better security.

Install Docker

Before involve running any Docker commands, you will need Docker to be installed on your local machine. If your system already has Docker, feel free to skip this part.

Install Docker on Linux

Update your package manager to ensure it is in the latest state:

sudo apt update

Now you can install Docker using apt command:

sudo apt install docker.io

Then you can check whether Docker is installed successfully by running the command:

sudo docker --version

Install Docker on Windows and MacOS

For Windows and MacOS, you can download the Docker Desktop at the following link.

Set up your first Docker project

Now your machine is ready to run with Docker, in the rest part of this article, we will work on a to-do-list application that uses ReactJS and build using NPM (node package manager). If you are not familiar with these terms, don’t worry since this tutorial doesn’t require experience with those.

Firstly, you will need the source of the application, start cloning it from the git repository by using the command:

git clone https://github.com/jimmy706/docker-getting-started.git

Now go to the directory of the project: cd docker-getting-started

If everything when well, your project folder now will look like this:

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         5/26/2023   9:36 PM         10 .dockerignore
-a----         5/26/2023   9:12 PM         124 app.py
-a----         5/26/2023   9:34 PM         367 Dockerfile
-a----         5/26/2023   8:57 PM         14 requirements.txt

We will see further information about Docker setup in the Dockerfile, use any text editor to open the Dockerfile and you can see the following content:

# Base image
FROM python:3.11.3-slim-buster

# Set working directory
WORKDIR /app

# Copy the entire application
COPY . .
RUN pip install --no-cache-dir -r requirements.txt

# Expose the application port
EXPOSE 5000

# Set environment variables
ENV FLASK_APP=app.py
ENV FLASK_RUN_HOST=0.0.0.0

# Start the application
CMD ["flask", "run"]

Here is the explanation of what is written in this file:

We first start with the base image which is Python in version 3.11.3-slim-buster – A smaller image size python version that can reduce your built-in image size.
We then set the working directory inside the container to /app
Next, we copy all the contents in the project file, excluding the files that are listed on .dockerignore file.
We then run the install command to download all required dependencies for running the app.
We tell Docker the port of the Flask application will run. In this case, is port 5000.
We set environment variables for the Flask application. In this example, we set FLASK_APP to app.py (the entry point of the Flask app) and FLASK_RUN_HOST to 0.0.0.0 to make the Flask app externally accessible.
Finally, we tell Docker that we want to run the flask command to start the application.

Build the Docker Image

Now once you understand what instruction we want Docker to do in Dockerfile, you can run the following command to build the application into a Docker Image:

docker build -t docker-getting-started:1.0.0-SNAPSHOT .

The docker build . command will build a new Docker Image when it found the Dockerfile inside your project. Then the -t flag will tell Docker that you will name the created image docker-getting-started with version 1.0.0-SNAPSHOT.

Wait a few seconds for Docker to download dependencies and bundle the application, you then can check if the image is created using the command: docker images

REPOSITORY              TAG              IMAGE ID       CREATED         SIZE
docker-getting-started  1.0.0-SNAPSHOT   630ee222e82c   6 minutes ago   136MB

Run the Docker Image

The final step is to start your Docker Image using docker run command:

docker run -p 5000:5000 --name hello-app docker-getting-started:1.0.0-SNAPSHOT

The above command map the exposed port 5000 of the virtualized container to your real port on your local computer.

We will name the running container hello-app for easier to track it.

Let’s check if our application is up and running using docker ps. If everything when well, you will see the following information:

CONTAINER ID   IMAGE COMMAND CREATED STATUS PORTS NAMES
9d5f37a9c5d7   docker-getting-started:1.0.0-SNAPSHOT   "flask run" 25 minutes ago   Up 2 seconds   0.0.0.0:5000->5000/tcp   hello-app

Then you can go to your http://localhost:5000 to see the result:

Remove the running container

You can now run the simple application using Docker. To stop the application you can run the command: docker stop hello-app

Then you can easily remove this container by running the following command:

docker rm hello-app

Check again if the container is stopped using docker ps and now you can see your container will not display on the terminal.

That’s it for the tutorial, thank you for reading. I hope this one can help you understand basic Docker fundamentals. If you like this article, feel free to like and share it to spread more knowledge.

Efficient System Deployment with Containerization: How your system benefits from Docker Containers?

June Dang — Sun, 21 May 2023 12:16:24 +0000

Continuing from our previous article on the evolution of software deployment, we now turn our attention to the remarkable benefits brought about by containerization—a concept that has revolutionized the tech world. Containerization has been used for a while now from its buzz to describe a system virtualized environments to run applications, offering unparalleled flexibility and lightweight execution.

In this story, let’s we will discuss one of the most popular tools used in the containerization realm: Docker Containers. We will unravel what is Docker, why you should use it, and the key concepts of Docker.

Understanding Containerization

With the people who first time come to this article and are not yet clear about what containerization is, here I will give some brief explanation before we head into other sections.

Containerization is a technique that bundles an application and its dependencies into a single virtualized unit called the container. By abstracting at the operating-system level, containerization only requires a small number of resources to run while bringing better control over the virtualized environment you want to bundle.

Docker Container?

Among all containerization technologies, Docker grow as the best option for developers and enterprises to containerize their applications due to the following factors:

Ease of use: Docker has a user-friendly and easy-to-learn interface that helps manage containers without too much worrying about remembering all the necessary commands making it accessible for both developers and administrators.

Portability: Docker supports all popular OS like Windows, MacOS, and Linus. Furthermore, you can easily run Docker in any environment from the data center to the cloud.
Large Ecosystem: Docker has a massive user base and ecosystem which support all your needed packaged containers through accessing Docker Hub public registry.
Lightweight: Be leverages OS level kernel, Docker does not require OS on each bundled application to run which improves server performance with better start-up time.
Isolation & Security: Each Docker container is highly isolated from the others allowing applications decoupled and run with better security.

Why use Docker?

You now have a brief understanding of containerization and Docker Containers but may not yet be convinced to use Docker Container for your application deployment process. So let’s have a short story to explain and convincing why you should try Docker for your deployment process.

Imagine you have two applications that are developed both in Java with different versions: one in Java 8 and one in Java 11. Now you want to deploy these 2 applications to your server for testing purposes but facing the issue that one machine barely manages to run two versions of a programming language. You can think of one of the following solutions:

Using 2 physical machines to run different Java versions.
Run two different virtual machines on a single physical server.

Both options seem to solve your problem but are bulky and not very cost-effective. Instead, a better third option is you only need a Docker to run two containers, each with a different installed version of Java. This approach eliminates the need for multiple physical machines or resource-intensive virtual machines without too much worrying about the cost and the performance of your application.

Docker key concepts

To have a further understanding of how Docker improves your system deployment process, let’s deep dive into the architecture and the core concepts of Docker.

Docker architecture

Docker follows client-server architecture with consists of three main components working together to bring the ability of containerization and help manage containerized applications:

Docker Daemon: The Docker daemon, called dockerd, runs as a background process on the host machine. It listens to requests sent from Docker Client to manage and control objects like images, containers, networks, and volumes.
Docker client: This component acts as a command line interface for users to communicate with Docker. Through the Docker client, users can execute a wide range of operations, such as creating and managing containers, building and pushing images, configuring networks, and more.
Docker registry: Docker registry serves as a repository for storing Docker images where the Docker daemon can retrieve required images for running containers. Docker Hub is the public Docker registry which allows anyone can use. Alternatively, organizations can set up their own private Docker registry for enhanced security and control over image distribution.

Docker components

Docker Image: A Docker Image is a package that included code, runtime environment, dependencies, and libraries needed to run your application. An Image can be created using instruction that is defined in a Dockerfile.
Container: A Docker Container is an instance created from Docker Image that runs on a host machine. Each container is an encapsulation of the application and its dependencies, providing a consistent and reproducible execution environment. Containers run in isolation from others to ensure applications’ reliability and portability across different environments.
Dockerfile: To create a Docker Image, you need to instruct Docker what is the running environment, dependencies, how the code will run, how the application folder be structured, and what version of your application be like. All this related information of your Image is defined in a Dockerfile.
Docker Compose: In some cases, you need to run a bunch of applications like in a microservice network, and need a way to chain them together as multiple Docker Images. Docker Compose can help you achieve this. It is a tool used for defining and managing multi-container Docker applications which allows you to specify the services, networks, and volumes required for your application in a YAML file
Volumes: By default, data inside containers is not persistent and so any changes made are lost when the container is stopped or deleted. To prevent this happen, you can use Docker Volumes to persist data generated by containers or share data between containers
Docker Networking: Each container is isolated from others and the outside world. So if you want to connect to them or make them communicate with each other you need a Docker Network. Docker Networking enables you to define networks, assign containers to networks, and expose container ports to make services accessible.

Conclusion

Containerization is a game-changer that helps developers easier to manage deployed applications by providing a lightweight and flexible environment. Among all containerization technologies, Docker is one of the best options to containerize your application due to its ease to use and largely supported ecosystem.

Originally published at junedang.com on May 21, 2023.