DEV Community: Amburi Roy

Scalability: Vertical, Horizontal, and Hybrid Scaling

Amburi Roy — Mon, 22 Jan 2024 10:39:14 +0000

Vertical Scaling or Scale-Up means adding more power (CPU, RAM, etc.) to your servers.

Horizontal scaling or Scale-Out allows you to scale by adding more servers to your pool of resources.

Vertical Scaling (Scale-Up):

When to Use: Typically employed when the traffic is low.
Why Use: Simplicity is a key advantage. It involves adding more resources (CPU, RAM, etc.) to existing servers to handle increased load.
Limitations:
- Finite Scalability: It's not possible to scale up infinitely due to hardware limitations.
- Single Point of Failure: If the single server hosting your application fails, the entire system might go down.

Solution to Limitations: Horizontal Scaling (Scale-Out):

When to Use: Especially useful when the system needs to handle a higher volume of traffic.
Why Use: Involves adding more servers to distribute the load, providing better fault tolerance and scalability.
Advantages:
- Redundancy: Multiple servers distribute the load, reducing the risk of a single point of failure.
- Scalability: Easier to scale by adding more servers horizontally.
Challenges:
- Complexity: Managing multiple servers can be more complex than a single, powerful server.
- Cost: Scaling out might involve more initial setup costs.

Choosing Between Vertical and Horizontal Scaling:

Consideration Factors:
- Cost: Vertical scaling may become more expensive as you reach hardware limits.
- Flexibility: Horizontal scaling provides more flexibility to adapt to changing workloads.
- Redundancy: Horizontal scaling offers better redundancy.

Hybrid Scaling:

Combined Approach: In many cases, a combination of vertical and horizontal scaling is used to achieve optimal performance and efficiency. Increasing the resources of individual servers (vertical scaling) and adding more servers (horizontal scaling) when necessary.

Understanding the trade-offs and choosing the right scaling strategy depends on factors like the nature of your application, traffic patterns, budget constraints, and more.

Cool Tool: ASDF — A single solution for managing versions

Amburi Roy — Sun, 21 Jan 2024 02:08:08 +0000

There are various version management tools and managers employed in the software development industry, each tailored to specific programming languages or frameworks. Here are some popular version managers:

NVM (Node Version Manager): NVM serves as a version manager for Node.js, allowing developers to easily switch between different versions of Node.js.
RVM (Ruby Version Manager): RVM is a version manager designed for the Ruby programming language. It enables developers to handle multiple Ruby environments on the same machine.
Pyenv: Pyenv functions as a Python version manager, simplifying the installation and management of different Python versions and facilitating easy switching between them.

However, the version manager I consider the best is ASDF (Another System Definition Facility). ASDF is a versatile version manager that transcends traditional boundaries, offering a unified approach to version control for a diverse range of programming languages and tools. With ASDF, developers can say goodbye to the hassle of juggling different version managers for each language or framework.

One of ASDF's key strengths lies in its seamless integration with various ecosystems.

Monolith, Microservices, Mono-Repo

Amburi Roy — Sun, 21 Jan 2024 02:00:42 +0000

What is a Monolith?

A Monolith is a single, self-contained software application or system containing all the necessary code and data to perform its functions.

What's the problem in Monolith?

Lack of Scalability: Monoliths can be challenging to scale because all components are tightly coupled, making it difficult to scale specific functionalities independently.
Limited Agility: Making changes or updates to a monolithic application can be slow and risky, as a single codebase may require extensive testing and downtime.
Maintenance Complexity: As monolithic applications grow, they become increasingly complex and challenging to maintain, leading to higher maintenance costs and longer development cycles.
Technology Lock-In: Monoliths often use specific technologies and frameworks, making adopting new technologies or tools difficult without major rewrites.
Lessened Fault Isolation: A failure in one part of a monolithic application can affect the entire system, making it harder to isolate and address issues without impacting the entire service.

How do you solve those problems?

Microservices is an architectural approach in software development where a complex application is decomposed into independently deployable, small, and loosely coupled services that communicate over networks, promoting flexibility and scalability.

Scalability: Microservices allow individual components or services to be scaled independently.
Agility: Microservices are smaller, decoupled services that make it easier to add new features, fix bugs, and update code without affecting the entire system, reducing the risk of errors and downtime.
Maintenance: With microservices, each service has its own codebase and development teams to focus on specific requirements.
Technology Diversity: Microservices enable the use of different technologies, languages, and frameworks for each service.
Fault Isolation: Since Microservices are loosely coupled codebases, if one service fails or experiences issues, it typically doesn't affect other services.

What's the problem with Microservices that the Mono repo solved?

A Mono Repo is a software development practice where all the source code for multiple projects or components of a software application is stored in a single, unified version control repository. In a monorepo, code for different services, libraries, or modules is organized and managed together rather than split into separate repositories as in a traditional multi-repo setup. This approach can simplify code sharing, version control, and dependency management across the various parts of a software project.

The charm of the Mono repo is to bring several loosely coupled code bases into one place and make it easily manageable.

Complexity: (out of sight, out of mind) Microservices manage numerous codebases, dependencies, and deployment pipelines, leading to increased complexity. A monorepo simplifies code management by consolidating all code into a single repository, making tracking changes, managing dependencies, and maintaining consistency easier.
Versioning and Dependency Hell: Coordinating versions and dependencies across multiple microservices can be challenging. A monorepo allows for centralized version control and simplified dependency management, reducing the risk of version conflicts and compatibility issues.
Testing and Integration: Integration testing between microservices can be complex and time-consuming. A monorepo enables more straightforward integration testing since all components reside in the same codebase, simplifying the testing process.
Code Sharing and Reusability: A monorepo facilitates code sharing and reusability across different application parts, promoting efficient development practices and reducing code duplication.

Advantages:

Easy Collaboration: All code is in one place, making it easier for developers to work together on different projects.
Easy Grant Access: It's easy to give developers access to the code they need without worrying about managing multiple repositories. Easy to understand boundaries, which is who's responsibility – If you decide to create reports based on which team owns it.
Easy to Understand Boundaries: It's easy to see who is responsible for which code because everything is in one place.
Clone One Repo: Developers only need to clone one repository, which simplifies their workflow. However, individual cloning could also be done in one directory. In that case, you all have to follow which branch you are currently in actively. In case of any changes that can potentially have lots of changes in several repositories, it could be not easy to track. In that way, mono repo could be a bright and shining option.
Simplified Dependency Management: It's easy to manage dependencies in a monorepo because everything is in one place. Also, shared dependency management has a huge advantage — it solves the problem of incompatible or not matching versions. It's straightforward to manage dependency in the mono repo – because you can put everything in one place and share that in several projects. Imagine only one composer.json shared by rosetta and every Erasys PHP library. That would be simplified.
Easy Refactoring: Monorepos make it easier to refactor code because developers can see all of the code affected by their changes. This can help to reduce the risk of introducing bugs.
Discovery: It can be easy to discover code in a large monorepo. Other than that, discovery and searching could be done in GitLab

Disadvantages

Coupling: If not managed carefully, a monorepo can lead to tight coupling between different projects. However, “Clone one repo” brings a problem that rosetta and other PHP libraries would be a bit coupled. If you didn't consider the subsequent feature integration, you might gradually tighten the coupling between libraries, eventually bringing the issues with Monolith. The problem is when the sprint is not focused on a single goal – Which is very usual. Also, systematic rebasing and conflict resolution could be induced in the mono repo in daily practice.
More Complex CI/CD Pipelines: Pipelines must be intelligent enough to know which tests should be executed and what should be built.
Performance: Monorepos can be slow and challenging to build and test.
Cloning a Huge Repository: Monorepos can be very large, making it slow and difficult for developers to clone.
Broken Master Situation: If the master branch of a monorepo is broken, it can prevent developers from releasing new features or bug fixes. Suppose something is broken in the master; 2 developers are working on that, and one is ready to deploy a new feature in another project. Which should go first? Is it okay to merge a new feature on a broken master? Potentially, a broken master can put a hold on releasing a feature because those 2 repositories are not in one mono repo.
Code Review Becomes Crucial: It's important to have good tooling in place to manage a monorepo effectively. This can include tools for dependency management, code review, and continuous integration and delivery.

All these problems are not unsolvable, but you might need to change quite a bit of our existing system to accommodate the Mono repo.

Most commonly used Git command shortcuts

Amburi Roy — Sun, 21 Jan 2024 01:57:26 +0000

I often rely on a set of Git command shortcuts that are widely used and find them quite convenient. Admittedly, it took me some time initially to become accustomed to them.

List of shortcuts:

alias g='git' — Simplifies the Git command as 'g'.
alias gs='git status' — Quickly check the current Git repository status.
alias ga='git add' — Prepares changes for the next commit.
alias gaa='git add .' — Adds all changes in the working directory to the staging area.
alias gc='git commit -m' — Commits changes with a specified commit message.
alias gca='git commit -am' — Adds and commits all changes in one step with a commit message.
alias gco='git checkout' — Switches to a different branch or commit.
alias gcb='git checkout -b' — Creates and switches to a new branch.
alias gbd='git branch -d' — Deletes a specified branch.
alias gba='git branch -a' — Lists all branches, including remote branches.
alias gbr='git branch' — Lists local branches.
alias gpl='git pull' — Fetches changes from a remote repository and merges them into the current branch.
alias gph='git push' — Pushes changes to the remote repository.
alias gpho='git push origin' — Pushes changes to the 'origin' remote repository.
alias gl='git log --oneline' — Displays a simplified log of commits.
alias gla='git log --oneline --decorate --graph --all' — Displays a detailed and graphical log of all commits.

Does Status Code `405` occur during a `GET` request?

Amburi Roy — Mon, 09 Oct 2023 13:30:58 +0000

TLDR

Status Code 405: It indicates that the HTTP method used in the request is not allowed for the requested resource.
GET Requests: A 405 status code should not occur during a standard HTTP GET request, as GET is meant for retrieving resources and is widely supported by web servers.
Exceptions: Server behavior can vary, so there might be situations where a GET request receives a 405 status code due to server configuration or resource constraints.
Advice: If you encounter a 405 status code for a GET request, investigate server configuration and consult API documentation to ensure correct usage.

What does status code 405 mean?

A status code of 405 typically indicates that the HTTP method used in the request is not allowed for the requested resource. In most cases, it's associated with HTTP methods like POST, PUT, DELETE, or PATCH being used on a resource that only allows GET requests.

Does Status Code `405` occur during a `GET` request?

For a standard HTTP GET request, a status code of 405 should not occur unless there's a misconfiguration or an unusual server setup. GET requests are typically used for retrieving resources and are widely supported by web servers for most resources.

However, it's important to note that server behaviour can vary, and there might be situations where a specific server or API returns a 405 status code for a GET request due to its configuration or the specific constraints of the resource. In such cases, it's essential to consult the API documentation or server documentation to understand the reasons for this response and how to use the API correctly.

Wrap-Up!

Typically RESTful APIs and web services, a 405 status code for a GET request is not expected behaviour. If you encounter such a situation, it's a good idea to investigate the server configuration and consult the API documentation to ensure that you are making the correct request.

Does Status Code `405` occur during a `GET` request?

Amburi Roy — Mon, 09 Oct 2023 13:30:31 +0000

TLDR

Status Code 405: It indicates that the HTTP method used in the request is not allowed for the requested resource.
GET Requests: A 405 status code should not occur during a standard HTTP GET request, as GET is meant for retrieving resources and is widely supported by web servers.
Exceptions: Server behaviour can vary, so there might be situations where a GET request receives a 405 status code due to server configuration or resource constraints.
Advice: If you encounter a 405 status code for a GET request, investigate server configuration and consult API documentation to ensure correct usage.

What does status code 405 mean?

Does Status Code `405` occur during a `GET` request?

Wrap-Up!

Design Principles

Amburi Roy — Mon, 11 Sep 2023 11:42:26 +0000

Design principles are fundamental guidelines and concepts that help guide the creation and evaluation of products, systems, or solutions. They are essential for various fields, including graphic design, web design, industrial design, architecture, and more.

Software design principles are a set of guidelines that help developers to make a good system design. There are 8 design principles,

💋 KISS (Keep It Simple, Stupid)

Amburi Roy ・ Sep 11 '23

#kiss #keepitsimpleandstupid #architecture #designpatterns

🧺 DRY (Don’t Repeat Yourself)

Amburi Roy ・ Sep 11 '23

#dry #designpatterns #architecture #softwaredevelopment

YAGNI (You Aren't Gonna Need It)

Amburi Roy ・ Sep 11 '23

#yagni #designpatterns #architecture #softwaredevelopment

🪨 SOLID Principles

Amburi Roy ・ Sep 11 '23

#solidprinciples #architecture #softwareengineering #designpatterns

SRP: Single Responsibility Principle
OCP: Open-Closed Principle
LSP: Liskov Substitution Principle
ISP: Interface Segregation Principle
DIP: Dependency Inversion Principle

Why should we follow design principles?

Design principles serve several crucial purposes:

User-Centeredness: They help ensure that the end product or solution meets the needs and expectations of the users. Following design principles can enhance usability and user satisfaction.
Consistency: Design principles promote consistency in the design, which can lead to a more cohesive and professional-looking end result. Consistency aids users in understanding and navigating the product.
Problem Solving: They provide a structured approach to solving design problems. When designers follow these principles, they are more likely to come up with effective and aesthetically pleasing solutions.
Communication: Design principles serve as a common language for designers, allowing them to communicate and collaborate effectively. They help convey design ideas and intentions to team members and stakeholders.
Efficiency: By adhering to design principles, designers can work more efficiently. They don't have to reinvent the wheel for each design project but can instead rely on established guidelines.
Aesthetics: Design principles often contribute to the overall visual appeal and aesthetics of a product or design. They can help create a harmonious and attractive appearance.

How do we keep these principles in mind?

To keep design principles in mind during a project:

Research: Understand the specific design principles that are relevant to your field or project. Familiarize yourself with best practices and examples.
Plan: Incorporate design principles into your initial project planning and brainstorming. Identify which principles are most relevant to your project's goals.
Prototyping: Create prototypes or drafts that reflect the design principles you want to follow. This helps you visualize how they will be applied.
Feedback: Seek feedback from peers or stakeholders, specifically addressing how well the design adheres to the chosen principles.
Iteration: Be prepared to iterate and refine your design based on feedback and your evolving understanding of the principles.
Testing: Test your design with real users if possible to ensure that it meets their needs and expectations.
Documentation: Document the design principles you've followed and how they were applied. This can serve as a reference for yourself and others involved in the project.

How do you understand the principles?

Understanding design principles requires both study and practice:

Education: Start by studying design principles through books, online courses, tutorials, or formal education in design-related fields.
Analysis: Examine existing designs, whether they are websites, products, or other creations. Analyze how design principles are applied in these examples.
Practice: Apply the principles in your own design projects. Practice is essential for gaining a deeper understanding of how to use design principles effectively.
Feedback: Seek feedback from experienced designers or mentors who can help you refine your understanding of design principles.
Stay Updated: Keep up with the latest trends and developments in your field, as design principles can evolve over time.
Experiment: Don't be afraid to experiment with design principles. Sometimes, breaking the rules can lead to innovative and creative solutions.

Wrap-Up!

Ultimately, a combination of theoretical knowledge and practical experience will help you develop a strong understanding of design principles and how to apply them effectively in your work.

💋 KISS (Keep It Simple, Stupid)

Amburi Roy — Mon, 11 Sep 2023 11:36:12 +0000

KISS stands for "Keep It Simple, Stupid."

It suggests that simplicity should be a primary goal when designing systems, solutions, or products.
The principle encourages avoiding unnecessary complexity, intricacies, or overengineering.

Goal:

The primary goal of KISS is to promote simplicity in design and decision-making. It encourages developers, designers, and decision-makers to favor straightforward and easy-to-understand solutions over complex ones.

Advantages:

Ease of Understanding: Simple designs are easier to understand, reducing the cognitive load on developers and users. This leads to improved maintainability and troubleshooting.
Reduced Errors: Simple systems are less prone to errors, making them more reliable and easier to test.
Faster Development: Simplicity often leads to faster development and reduced time-to-market.
Lower Maintenance Costs: Simple designs are easier and cheaper to maintain over the long term.
Scalability: Simple systems can often be scaled more easily, as they have fewer interconnected components to manage.

Disadvantages:

Misinterpretation: The principle can be misinterpreted as advocating for shortcuts or lack of necessary sophistication in certain situations.
Context-Dependent: What is considered "simple" can vary depending on the context and requirements of a project. What is simple for one project may be too complex for another.

📌 Dependency Hell

Dependency hell is a term used to define the problems faced by software developers, publishers, and users in general when a software or a software package is dependent on other software. Dependency hell occurs when software works abnormally or displays errors and bugs due to an integrated software/application/dependencies developed by a third party.

Wrap-Up!

KISS, or "Keep It Simple, Stupid," is a design principle that emphasizes the importance of simplicity in design and decision-making. Its goal is to promote straightforward and easy-to-understand solutions, leading to advantages such as improved understanding, reduced errors, faster development, lower maintenance costs, and scalability. However, it should be applied judiciously, as overly simplistic solutions may not be suitable for all contexts or requirements.

YAGNI (You Aren't Gonna Need It)

Amburi Roy — Mon, 11 Sep 2023 11:22:29 +0000

YAGNI stands for "You Aren't Gonna Need It."

YAGNI (You Aren't Gonna Need It) is a software development principle that suggests not adding functionality or code until it is deemed necessary.

It encourages developers to avoid premature optimization, overengineering, or speculative features.

Example: It basically means that you should not write the same code/configuration in multiple places. If you do that, then you’ll have to keep them in sync; and any changes to the code at one place will require changes at other places as well.

Goal:

The primary goal of YAGNI is to avoid unnecessary complexity and wasted effort by focusing on delivering only what is essential to meet the immediate requirements and needs of the project.

Advantages:

Simplicity: YAGNI promotes simple and straightforward code by discouraging unnecessary features and complexity. This leads to code that is easier to understand and maintain.
Reduced Waste: By avoiding the implementation of features that may never be used, YAGNI reduces the waste of development time and resources on unnecessary work.
Flexibility: YAGNI allows a project to remain flexible and adaptable to changing requirements because it does not commit resources to speculative features.

Disadvantages:

Overlooked Future Needs: In some cases, YAGNI might lead to overlooking legitimate future requirements. It's essential to strike a balance between avoiding unnecessary work and anticipating potential future needs.
Team Communication: Misunderstanding or miscommunication within a development team can lead to disagreements about what is considered "necessary" or "unnecessary."

Wrap-Up!

YAGNI is a pragmatic software development principle that encourages developers to resist the temptation to add features, optimizations, or code that is not currently required by the project. It promotes simplicity, reduces waste, and keeps projects adaptable. However, it should be applied judiciously, taking into account the potential for future needs and ensuring clear communication within the development team.

🧺 DRY (Don’t Repeat Yourself)

Amburi Roy — Mon, 11 Sep 2023 10:58:47 +0000

DRY stands for "Don't Repeat Yourself." It is a principle that encourages developers to avoid duplicating code or logic in their software systems.

📌 This principle states that each small piece of knowledge (code) may only occur exactly once in the entire system. This helps us to write scalable, maintainable, and reusable code.

Goal:

The DRY principle aims at reducing the repetition of code and effort in software systems.
The DRY principle promotes reusability. It makes the code more maintainable, more extensible, and less buggy.

Advantages:

Code Maintainability: DRY code is easier to maintain because there's only one place to make updates or fixes when needed. This reduces the risk of inconsistencies or bugs introduced by changes in multiple locations.
Improved Readability: DRY code is often more readable and comprehensible because it minimizes redundancy. Developers can understand and modify the codebase more easily.
Enhanced Efficiency: Reusing code reduces the development effort. Instead of writing the same logic multiple times, developers can write it once and reuse it throughout the application.
Consistency: DRY code promotes consistency in the codebase, as there's a single source of truth for specific logic or data.

Following are some concepts in software engineering that are based on the DRY principle -

Inheritance and Composition: Both inheritance and composition allow you to write code in one place and then reuse it at other places.
Database Normalization: Database normalization is a design technique used in databases to eliminate redundancy (repetition) of data.

Disadvantages:

Over-Abstraction: Overzealous adherence to DRY can lead to excessive abstractions or premature optimization, which can make the code more complex and harder to understand.
Trade-offs: There can be trade-offs between DRY and other principles, such as readability and performance. Sometimes, duplicating a small piece of code may improve readability or performance without significantly affecting maintainability.

Wrap-Up!

The DRY principle encourages developers to eliminate code redundancy by writing each piece of knowledge or functionality once and reusing it when needed. This promotes code maintainability, readability, and efficiency. However, it should be applied judiciously, as over-optimization or excessive abstraction can lead to complexity and trade-offs.

🪨 SOLID Principles

Amburi Roy — Mon, 11 Sep 2023 10:05:10 +0000

SOLID Principles are a set of five design principles in object-oriented programming and software engineering that aim to create robust, maintainable, and scalable software. They provide guidelines for writing clean, flexible, and modular code.

It is a meta acronym where each letter corresponds to another acronym:

SRP: Single Responsibility Principle
OCP: Open-Closed Principle
LSP: Liskov Substitution Principle
ISP: Interface Segregation Principle
DIP: Dependency Inversion Principle

SOLID Principles: Single Responsibility Principle (SRP)

Amburi Roy ・ Sep 11 '23

#solidprinciples #designpatterns #singleresponsibility #architecture

Definition: A class should have only one reason to change, meaning it should have a single responsibility or job.
Goal: Encourage modular and focused classes, making code easier to understand and maintain.
Advantages: Improved maintainability, readability, and reusability; easier testing.
Disadvantages: Over-applying SRP might lead to excessive class proliferation and complexity.

SOLID Principles: Open-Closed Principle (OCP)

Amburi Roy ・ Sep 10 '23

#solidprinciples #openclosedprinciple #ocp #architecture

Definition: Software entities should be open for extension but closed for modification.
Goal: Enable adding new features without changing existing code, fostering extensibility.
Advantages: Reduced risk of introducing bugs, better code organization.
Disadvantages: Overly adhering to OCP can lead to complex designs.

SOLID Principles: Liskov Substitution Principle (LSP)

Amburi Roy ・ Sep 11 '23

#solidprinciples #lsp #liskovsubstitution #coding

Definition: Objects of derived classes should be substitutable for objects of their base classes without affecting program correctness.
Goal: Ensure behavioral consistency when using derived classes, supporting polymorphism.
Advantages: Polymorphic behavior, easier maintenance.
Disadvantages: Requires careful adherence, can be challenging to implement correctly.

SOLID Principles: Interface Segregation Principle (ISP)

Amburi Roy ・ Sep 11 '23

#solidprinciples #designpatterns #interfacesegregation #architecture

Definition: Clients should not be forced to depend on interfaces they do not use. Keep interfaces small and specific.
Goal: Prevent classes from implementing unnecessary methods, reducing coupling.
Advantages: Better code organization, improved reusability.
Disadvantages: Can lead to more interfaces, requiring careful design.

SOLID Principles: Dependency Inversion Principle (DIP)

Amburi Roy ・ Sep 11 '23

#solidprinciples #designpatterns #architecture #dependencyinversion

Definition: High-level modules should not depend on low-level modules; both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions.
Goal: Reduce coupling, promote modular design, and allow for flexible system changes.
Advantages: Reduced coupling, easier testing, improved maintainability.
Disadvantages: May introduce complexity when designing abstractions.

Wrap-Up!

SOLID principles offer guidelines to create well-structured and maintainable software. While they provide numerous advantages like better code organization, reusability, and extensibility, they may introduce complexity if applied excessively. Careful application of these principles can lead to more robust and adaptable software systems.

SOLID Principles: Dependency Inversion Principle (DIP)

Amburi Roy — Mon, 11 Sep 2023 09:34:38 +0000

🪨 SOLID Principles

SOLID is a list of 5 software engineering principles. It is a meta acronym where each letter corresponds to another acronym:

Without any further ado, let's jump into today's topic:

Dependency Inversion Principle (DIP)

Dependency Inversion Principle (DIP) is one of the SOLID principles of object-oriented programming.

It suggests two main principles:

High-level modules should not depend on low-level modules, but both should depend on abstractions (the Inversion of Control)
Abstractions should not depend on details, but details should depend on abstractions.

Goal: The primary goal of the Dependency Inversion Principle is to reduce the coupling between software modules by promoting a flexible and maintainable architecture. It encourages the use of abstractions and interfaces to decouple high-level modules from low-level implementations.

Advantages:

Reduced Coupling: DIP leads to reduced coupling between different modules or classes in a software system. This makes the codebase more flexible and less prone to ripple effects when changes are made.
Improved Testability: Code that adheres to DIP is easier to test. High-level modules can be tested in isolation using mock objects or test doubles, allowing for more effective unit testing.
Increased Reusability: Abstractions and interfaces foster code reusability. High-level modules can work with different low-level implementations as long as they adhere to the same abstractions.
Ease of Maintenance: DIP makes it easier to maintain the software system because changes to one module are less likely to affect other modules. It promotes a modular and loosely coupled design.

Bad Example:

class PaymentProcessor {
    public function processPayment($amount, $gateway) {
        if ($gateway === 'Google') {
            // Code to process payment with Google gateway
        } elseif ($gateway === 'Apple') {
            // Code to process payment with Apple gateway
        }
    }
}

$paymentProcessor = new PaymentProcessor();
$paymentProcessor->processPayment(100, 'Google');

Here, the PaymentProcessor class directly depends on the specific payment gateway implementations ('Google' and 'Apple'). This high-level module is tightly coupled to low-level details, violating the Dependency Inversion Principle.

Good Example:

interface PaymentGateway {
    public function processPayment($amount);
}

class GooglePaymentGateway implements PaymentGateway {
    public function processPayment($amount) {
        // Code to process payment with Google gateway
    }
}

class ApplePaymentGateway implements PaymentGateway {
    public function processPayment($amount) {
        // Code to process payment with Apple gateway
    }
}

class PaymentProcessor {
    private $gateway;

    public function __construct(PaymentGateway $gateway) {
        $this->gateway = $gateway;
    }

    public function processPayment($amount) {
        $this->gateway->processPayment($amount);
    }
}

$googleGateway = new GooglePaymentGateway();
$paymentProcessor = new PaymentProcessor($googleGateway);
$paymentProcessor->processPayment(100);

Here, we have adhered to the Dependency Inversion Principle by introducing the PaymentGateway interface. The PaymentProcessor class depends on the abstract PaymentGateway interface rather than concrete implementations. This decoupling allows for flexibility and ease of maintenance. Different payment gateways can be added without modifying existing code, making the system more extensible and adhering to DIP principles.

DEV Community: Amburi Roy

Scalability: Vertical, Horizontal, and Hybrid Scaling

Cool Tool: ASDF — A single solution for managing versions

Monolith, Microservices, Mono-Repo

What is a Monolith?

What's the problem in Monolith?

How do you solve those problems?

What's the problem with Microservices that the Mono repo solved?

Advantages:

Disadvantages

Most commonly used Git command shortcuts

List of shortcuts:

Does Status Code `405` occur during a `GET` request?

TLDR

What does status code 405 mean?

Does Status Code 405 occur during a GET request?

Wrap-Up!

Does Status Code `405` occur during a `GET` request?

TLDR

What does status code 405 mean?

Does Status Code 405 occur during a GET request?

Wrap-Up!

Design Principles

💋 KISS (Keep It Simple, Stupid)

Amburi Roy ・ Sep 11 '23

🧺 DRY (Don’t Repeat Yourself)

Amburi Roy ・ Sep 11 '23

YAGNI (You Aren't Gonna Need It)

Amburi Roy ・ Sep 11 '23

🪨 SOLID Principles

Amburi Roy ・ Sep 11 '23

Why should we follow design principles?

How do we keep these principles in mind?

How do you understand the principles?

Wrap-Up!

💋 KISS (Keep It Simple, Stupid)

Goal:

Advantages:

Disadvantages:

📌 Dependency Hell

Wrap-Up!

YAGNI (You Aren't Gonna Need It)

Goal:

Advantages:

Disadvantages:

Wrap-Up!

🧺 DRY (Don’t Repeat Yourself)

Goal:

Advantages:

Disadvantages:

Wrap-Up!

🪨 SOLID Principles

SOLID Principles: Single Responsibility Principle (SRP)

Amburi Roy ・ Sep 11 '23

SOLID Principles: Open-Closed Principle (OCP)

Amburi Roy ・ Sep 10 '23

SOLID Principles: Liskov Substitution Principle (LSP)

Amburi Roy ・ Sep 11 '23

SOLID Principles: Interface Segregation Principle (ISP)

Amburi Roy ・ Sep 11 '23

SOLID Principles: Dependency Inversion Principle (DIP)

Amburi Roy ・ Sep 11 '23

Wrap-Up!

SOLID Principles: Dependency Inversion Principle (DIP)

🪨 SOLID Principles

Dependency Inversion Principle (DIP)

Bad Example:

Good Example:

Does Status Code `405` occur during a `GET` request?

Does Status Code `405` occur during a `GET` request?