DEV Community: Chukwuebuka

CRUD Operations

Chukwuebuka — Wed, 02 Apr 2025 08:26:02 +0000

What is CRUD, and Why is it Important?

CRUD stands for Create, Read, Update, and Delete—the fundamental operations for managing data in any application, database, or API. These operations are essential when developing applications that interact with persistent data.

In my previous articles, I have limited the use of technical jargon to make concepts easier to understand and avoid unnecessary confusion.

I believe most people are familiar with e-commerce platforms like Amazon, AliExpress, or eBay, so I will use these platforms as examples to explain CRUD operations practically.

CRUD operations are the backbone of various applications, including web, desktop, mobile, and enterprise software. No matter how complex a program's computations are, it ultimately relies on CRUD operations in some form. Every application either creates, reads, updates, or Deletes data. I have yet to come across a program that doesn’t involve at least one of these operations.

Now, let’s dive into it! 🚀

Create Operation in CRUD
The Create operation, also known as a POST request in HTTP, is used to insert new data into a database or any other storage system used by an application.

Using an e-commerce platform as an example, suppose you're an Amazon seller and want to publish a new product. You log into your account (which itself involves creating a session) and then create a product by providing the required details.

For instance, we define a Product class in Java:

public class Product {
    private Long id;
    private String name;
    private Double price;
    private Integer quantity;
    private String category;
    private String imageUrl;
}

The developers expose an API endpoint that accepts a POST HTTP request containing product details. The server processes the request and stores the product in the database. This entire process represents the Create operation in CRUD (Create, Read, Update, Delete).

Even when you order items from these platforms, all these processes are known as the creation process in CRUD.

READ Operation

The READ operation in CRUD is used to retrieve data from a database or storage system.

For example, on Amazon, when you visit the homepage and see product listings, the website performs a READ operation to fetch and display stored product information. Similarly, searching for a product or clicking on a specific item also triggers a READ operation, retrieving the relevant details from the database.

This operation is performed using the HTTP GET method.

Another great example of this is the SELECT query on the database.
So if you are familiar with SQL queries, whenever you run a SELECT query, you are doing a READ operation.

UPDATE Operations

The UPDATE operation in CRUD is used to modify existing data in a database or storage system. This is often done using HTTP methods like PUT (which replaces the entire resource) or PATCH (which updates specific fields).

Imagine you are an Amazon seller, and you want to change the price of a product you listed. When you go to the seller dashboard and edit the product price, Amazon performs an UPDATE operation through its code to modify the price field in its database.

If you update the entire product details, the system might use a PUT request. If you only update the price, it might use a PATCH request.

SQL Example If an Amazon seller wants to update a product’s price in a MySQL database, the SQL query might look like this:

UPDATE products SET price = 19.99 WHERE product_id = 1234;

DELETE Operation

The DELETE operation in CRUD is used to remove data from a database or storage system. Once a record is deleted, it is no longer accessible unless recovery mechanisms (like soft delete or backups) are in place.
This operation is done using the HTTP DELETE method.

Imagine you are an Amazon seller, and you want to remove a product listing from your store. When you click "Delete Product", Amazon performs a DELETE operation to remove that product from its database.

If an Amazon seller wants to delete a product with product_id = 1234, the SQL query might look like this:

DELETE FROM products WHERE product_id = 1234;

System Security Concepts

Chukwuebuka — Fri, 21 Feb 2025 17:41:43 +0000

In this article, we’ll dive into some essential concepts of system security. While we won’t cover every aspect, our primary focus will be on applications designed for web or mobile platforms. These principles are often applicable to other systems as well, such as embedded systems, but our main emphasis will remain on the previously mentioned areas.

Before we go into much detail on the topic, let’s understand what System Security is about:

Also as a reminder, from my last post, I use system and application as the same thing.

“System security ensures that information is accessed, transmitted, and maintained securely, reaching only authorized individuals, without being altered or disrupted.”

Now that we know the definition, let’s start looking at the concepts that ensure this is true in our system. And I will speak about them in no particular order.

The next two concepts are fundamental to a secure system. However, people sometimes don’t know the key differences, and I will explain them using clear examples.

Authentication.

Authentication is the concept that verifies user identity and ensures that the information provided by the person trying to access our system (Username and Password) is correct. Like I can say I am Mr. John Doe, the system checks to confirm I am telling the truth using the set means of identification.

Let’s use an event as an example. Most events are strictly by invitation. When you get to the venue, you see the security personnel at the gate, and they ask you for your invitation card or mail, or whatever was used. Let’s say the invitation has a QR code. When it is scanned, your name and other information pop up. You get registered or checked in, and a tag is given to you.

This is what authentication is about, anyone who presents this information in our case “QR code”, we see if it is what our system is expecting, if the information comes up, then we sign the person in (grant access) and provide a tag for the person.

Authorization

Authorization is the concept that applies after you have been authenticated (granted access), it now determines your access level.

Using our event example, you have entered the event hall, where you will sit is determined by the tag you have. In a system, someone who has read-only access won’t be allowed to create in the system, so if your seat level is in the middle of the event hall, you won't be allowed to sit in front. This concept of authorization leads us to our next concept role-based access.

Role-Based Access Control

Role-based access control (RBAC) is a concept where people's roles determine what they access in your system. This means people have access to resources based on the role they have in your system. Using our event example again, someone who is part of the security or organisers has an access level that permits him/her to go to multiple places in the event center including backstage, in the RBAC system, people can have one or more roles and those roles determines what they see, and action they perform in the system.

This concept is important when you are building a multiple-actor system. For example Hospital management system, what a doctor sees, will be different from what the patient is seeing.

The doctor sees information on all the patients under him, while the patient sees only their information and upcoming appointments. A receptionist could see only the scheduling and billing information but not medical records. Things like this keep information safe and can be achieved using RBAC.

Encryption

Encryption concept ensures data security during transmission and storage by converting it into unreadable formats. If the system gets hacked or data leaks, important personal pieces of information like passwords or health-related data won’t be in plain readable text.

It’s interesting to know that this is not a computer-age concept, Julius Caesar was reported to use some level of encryption to send messages to his Generals, even when the enemy arrests the messenger, they can’t make sense of the message being transmitted.

His encrypted method is known as The Caesar Cipher which is simple to replace each letter of the alphabet with the letter occurring three positions later or 23 positions earlier in the alphabet: A becomes D, B becomes E, X becomes A, and so forth. You can read more about this. This method is not a safe option anymore.

We can achieve encryption today by leveraging many existing software or codes, like JWT, JASYPT Encryptor, and many others.

What this means is when you pass your message like “Hello, I am the author of this article.”, these encrypting tools convert it to something like this “gXe3mi8CAlXoVpwfCkr0hSLhYZ1FeizkRmAntcZQPA41FAKsGLDEPvk7/KleCv+T”. This way only the person with the secret key will be able to decrypt your message and make sense of it. By the way, I used this online tool to create the encryption above https://www.devglan.com/online-tools/jasypt-online-encryption-decryption you too can go play with it.

I hope this article was helpful to you in understanding these concepts if you have any questions, please feel free to drop them in the comments section and I will answer them.

Do you want to learn about System Design? I think this is a great article for you to get started with.

Chukwuebuka — Fri, 03 Jan 2025 12:46:33 +0000

System Scalability

Chukwuebuka ・ Jan 2

#softwareengineering #systemdesign #100daysofcode #softwaredevelopment

System Scalability

Chukwuebuka — Thu, 02 Jan 2025 15:52:32 +0000

I am currently reading one of the best books on the topic of System Design. I have always wanted to read this book, but for some reason, I keep putting it aside. I picked the book up again and have been committed to reading it for over a month now. The name of the book is Designing Data-Intensive Applications by Martin Kleppmann.

I will be picking up what I learned in the book and other places about System Scalability and sharing it in simple English, so anyone can understand it.

One of the core aspects of building a system people will use and trust is designing our system with its scalability in mind. I will be using System and Application interchangeably throughout this article.

Before we go further, what is System/Application Scalability?

In a simple term, scalability is a term we use to describe a system that will not crash or have reduced performance when loads are increased on it.

For example, we have an E-commerce website with an average concurrent usage of 10,000 people. What will happen to our application when it’s the festive period, more people are shopping on our system, and up to 100,000 people are on it simultaneously? The term for this can be increased load.

How do you manage this load, so your system can still provide the needed services as normal, even though more people are using it now?

Will people have to wait longer for the system to respond? Will the server go down (crash) because the load placed on it is beyond what it can currently hold?

The author suggests we ask ourselves 2 important questions when thinking about system scalability.

“1. If the system grows in a particular way, what are our options for coping with the growth?” and...

“2. How can we add computing resources to handle the additional load?”

Based on the questions above, the author proposed we don’t jump into making recommendations but rather do what he called Describing the Load and the Performance.

Describing Load:

To better understand how to scale a system, you have to know the current load the system takes only then can you answer the growth question of What happens if our load doubles?

Load in terms of System/Application can be described as the number of times functions are being used or our server resources are being utilised. The author has a suggestion for how we can determine what works for our specific system.

“The best choice of parameters depends on the architecture of your system:

it may be requests per second to a web server, the ratio of reads to writes in a database, the number of simultaneously active users in a chat room application, the hit rate on a cache, or something else. Perhaps the average case is what matters for you.” — Martin Kleppmann

What he is trying to explain here is we should find the scenario that works for our system. For some people, the system they are dealing with is a heavy read system, and for others, it would be a heavy write system, and the strategy will defer.

If your system is a heavy read system, adding a cache could reduce the number of times that a call is made to your database and in turn, reduce the time it takes to get a response.

Knowing what has been said here, let’s quickly look at the different ways we can scale our application, this will cut across many aspects of system scaling.

Vertical Scaling: This is also called scaling up, this is a type of system scaling we do by adding more computing power (CPU, RAM, etc) to what we currently have. This has a lot of limitations, e.g., cost increases, physical server limits, etc.
Horizontal Scaling: Also known as scaling out, it involves adding more machines or computing resources to a system to handle increased demand. Unlike vertical scaling, where you upgrade the resources (CPU, RAM, etc.) of a single machine, horizontal scaling distributes the load across multiple machines. Then we introduce a load balancer to manage these distributed machines, which ensures incoming requests are evenly spread across the available machines, reducing individual system load and enhancing scalability and fault tolerance.
Database Scaling: This is one of the most important aspects of scaling our system. I won’t be able to cover every aspect of this; I will write a full article about it because we have about 5 or 6 ways that we can scale a database alone.
Software Scaling: A system can be scaled by refactoring inefficient code, changing the data structure used, and/or algorithm of the previous implementation.
We can also change the design pattern used in developing the application.
Elastic Scaling: This type of scaling is done by our cloud service providers, most service providers like AWS have an infrastructure (AWS Auto) where your system usage will determine the resources assigned to it.

A quick example would be a live-streaming application. Let’s use a football streaming application as a case study. If on average, the concurrent usage on the platform is 1,000,000 users, and the World Cup final is happening with Messi and CR7 playing in the finals, such a platform will expect to have more concurrent users than they have ever seen.

If their cloud infrastructure is designed to scale elastically, users will likely have a flawless experience because the cloud provider is assigning the needed resources based on demand. After the event has ended, usage will go back to the normal 1,000,000 concurrent users and resources will be reduced to usual.

A recent example would be the Mike Tyson vs. Jake Paul fight; you can search about the challenge Netflix faced the day the fight happened.

What I covered here is just the introduction for the topic, I would suggest getting the book I mentioned or getting a complete course on System Design because as you grow in your career, those are the things that will be expected you know.

If you have any comments, suggestions, or questions kindly leave them in the comment section and I will attend to them.

ACID Properties in a Database Management System (DBMS) Explained in a Simple English.

Chukwuebuka — Fri, 06 Dec 2024 12:46:11 +0000

ACID properties in a Database Management System (DBMS) ensure data stays accurate, reliable, and consistent during transactions, even with multiple users.

ACID stands for:
A — Atomicity
C — Consistency
I — Isolation
D — Durability

Let’s explain each one below.

Atomicity, also called “All or Nothing,” ensures that a transaction's operations are either fully complete or not applied to the database. If any part of the transaction fails, the database rolls back to its original state.

For example, in a banking system:

- Bob has $1000, and Joe has $700.
- Bob transfers $200 to Joe.

This involves two operations marked as success:

- Debit $200 from Bob's account.
- Credit $200 to Joe's account.

If Bob's account is debited, but Joe's isn't credited, the transaction fails. Atomicity ensures both actions succeed together or not at all.
Atomicity ensures transactions are aborted if a failure occurs and rolls back any changes that might have happened or commits the changes if all is successful.

Consistency ensures the database remains in a valid state before and after a transaction.
What this simply means is that before the start of the transaction, if we have a total number of 100, after the transaction, it should also be the same.

Using the banking example above:

- Before the transaction, Bob has $1000, and Joe has $700, for a 
  total of $1700.
- After the transaction, Bob has $800, and Joe has $900. The total 
  remains $1700.

Consistency guarantees that even though individual values changed, the overall state of the database is correct.

Isolation ensures that transactions do not interfere with each other, preserving database consistency. Each transaction should execute independently as if it is the only one running.
Using the banking example:

 - While Bob transfers $200 to Joe, he also spends $200 at a 
   restaurant.
 - If both transactions run simultaneously, they might both read 
   Bob's initial balance of $1000, causing his final balance to 
   incorrectly be $800.

With Isolation, one transaction completes first (e.g., the transfer), updating Bob's balance. The second transaction (e.g., the restaurant payment) then uses the updated balance, ensuring accurate results.

Durability ensures that once a transaction is successfully completed, its changes to the database are permanent, even in the event of a system failure.

Using the banking example:

- After Bob's payment to the restaurant is confirmed, the database 
  securely saves the change.
- Even if the system crashes (e.g., due to a power outage), the 
  payment remains recorded, and Bob's updated balance is preserved.

This guarantees that completed transactions are not lost.

I hope this explanation simplifies the concept for you. If any part is still unclear or you’d like further clarification, feel free to let me know in the comments. I’d be happy to explain further. Thank you!

Solid Principle in Simple English

Chukwuebuka — Thu, 28 Nov 2024 12:55:05 +0000

This article was inspired by a conversation with my mentee, a Software Engineering student in Canada. After explaining the basics of Object-Oriented Programming (OOP) to him, I asked him to read about SOLID principles.

As expected, he came back with questions. The discussion that followed made me realize the need to explain SOLID principles in simple terms. That’s what I aim to do here—to make this essential topic in software development easier to understand for everyone.

The SOLID principles, created by Robert C. Martin (aka Uncle Bob), are a set of best practices for designing software. Simply put, they guide you in building scalable and maintainable systems. While they aren’t the only way to design software, following these principles can help ensure your system grows smoothly as demand/requirements changes.

Let’s dive into SOLID, an acronym where each letter stands for a key principle:

S: Single Responsibility
O: Open-Closed
L: Liskov Substitution
I: Interface Segregation
D: Dependency Inversion

Single Responsibility Principle (SRP):

This principle states that a class should have only one reason to change, meaning it should have a single, well-defined responsibility or job within the software system.

Think of a washing machine in your house. A washing machine should only wash, not also paint or cut. Similarly, a class should have a single, well-defined purpose.

Mixing responsibilities like this can lead to bugs and make your code harder to debug and maintain. Keeping each class focused on a single task ensures cleaner and more scalable code.

Open-Closed Principle (OCP):

This principle says a class should be open for extension but closed for modification.

In simple terms, you should be able to add new features to existing code without changing its original functionality.

Let's say you initially built a robot that can walk. Later, you want to add jumping ability. The wrong way would be to go back and change the original walking code. Instead, you should design your code, so new movements can be added without touching the existing walking functionality.

So Closed for modification means “Existing code doesn’t need to change”
Open to extension means “You can include new functionalities by extending the existing code”

Liskov Substitution Principle (LSP):

This principle means that a child class should be able to do everything its parent class can do.

In Object-Oriented Programming (OOP), when a new class (child) is created (extended) from an existing one (parent), the child class should be a proper replacement.

Think of it like substituting players in a football game. If one player is replaced, the substitute should at least know how to play football—not hockey or basketball. This ensures the system works as expected when the child class is used in place of the parent.

Just like how a substitute player must understand the rules and basic skills of football.
A subclass must maintain the expected behaviors of its parent class.
The substitute might play differently (striker vs defender) but must fulfill the basic requirements of being a footballer.
If you put in someone who can't play football at all, it breaks the game (violates LSP).

Interface Segregation Principle (ISP):

This principle says a class should only depend on the interfaces it actually uses.

In simple terms, it’s better to have many smaller, specific interfaces than one large, general-purpose one.

For example, if both robots and humans are workers in your system, they have different needs. Humans eat, sleep, and work, while robots only work. Instead of forcing both to use the same interface (with eat, sleep, and work methods), create separate interfaces for each.

Why does this matter?

Avoids bugs (e.g., a robot trying to "eat").
Makes the code easier to understand.
Reduces unnecessary dependencies.
Keeps the system flexible and easier to maintain.

The goal is to create small, focused interfaces tailored to each class's needs.

Dependency Inversion Principle (DIP) :

This principle states: “Depend on abstractions, not concretions.”

In simple terms:
High-level modules should not directly depend on low-level modules.
Both should depend on abstractions.
Example:
Imagine you're building a system to notify buyers when their order is processed.

Without DIP: Your OrderProcessor directly depends on EmailSender, making it hard to add other notification types like SMS.

With DIP: Create a NotificationSender interface with an abstract method for sending notifications. Then, implement this interface for different types, like EmailSender and SMSSender. Now, OrderProcessor only depends on the interface, making it easy to switch or add new notification types.

Benefits of this approach:

Decoupling: The OrderProcessor is no longer tightly coupled to a specific notification method.

Flexibility: You can easily add new notification types by creating new classes that implement the NotificationSender interface.

Scalability: Adding a new notification type (like WhatsApp or Push Notification) becomes trivial.

Testability: You can easily mock the notification sender for unit testing and if something breaks, you can easily debug it.

Summary
I hope this explanation was easy to understand! If you have any questions, feel free to drop them in the comments, and I’ll be happy to help.

Next, I plan to share code examples of these concepts to make them even clearer and more relatable. Stay tuned!