DEV Community: Anurag Patil

URL Shortener Microservice using FastAPI and PostgreSQL

Anurag Patil — Sat, 25 Nov 2023 11:10:29 +0000

Hello everyone !
Been a long time that I have made my hands dirty on some projects.

Currently, am getting to know basics of microservices and how to implement them.

For a beginner perspective, I have came up with a short microservice which involves all the aspects we need while deploying a microservice.

It includes the following concepts:

Database Integration
Code Linting
Design Principles
Clean Code
Configuration Management
Dependency Management
Documentation
API Testing
Containerization

I have tried to include as much as I can for a beginner to understand the basics of it in a simple way.

Please go through the code here.

Let me know if you find it helpful in the comments.

Feedbacks and suggestions are always welcomed !!!
Happy Learning !

Introduction to Documentation and Code Linting

Anurag Patil — Tue, 07 Nov 2023 05:40:56 +0000

This blog mainly focuses on two concepts which are a bit underrated. One is code linting and other is live documentation.

Let's first understand the meaning of these two concepts before we dive into the implementation.

Linting

Linting is the process of running a program that will analyse code for potential errors.
Simply put, it is the process of checking the source code for Programmatic as well as Stylistic errors. This is most helpful in identifying some common and uncommon mistakes that are made during coding.
A Lint or a Linter is a program that supports linting (verifying code quality). They are available for most languages like JavaScript, CSS, HTML, Python, etc..
Running a lint program over your source code, helps to ensure that source code is legible, readable, less polluted and easier to maintain.
It helps you find :
1. formatting discrepancies
2. find non-adherence to coding standards and conventions
3. pinpoint possible logical errors in your program

Linting tools usage:

Linting tools can be configured with other tools like git pre commit hook and husky, to ensure that the linting is done of the code that is being committed to a certain repository.
This will make sure that coding standards are maintained and code is formatted and language specific best practices are adhered before code is committed to the repository.
Engineers will be able to make the commit only if the said coding standards are met.

ruff - An extremely fast Python linter and code formatter, written in Rust.

Documentation - https://pypi.org/project/ruff/

Documentation using MakeDocs

    “Code is more often read than written.”

    — Guido van Rossum

Whenever you are using a library, you look for examples or official documentation on how to do something specific.
Software documentation is a crucial part of a working software.
Documentation is crucial because it can assist users understand how to use your software, it can provide developers and other technical stakeholders with information about the technical aspects of your software.
Well-written software documentation can help improve the overall quality and user experience of your software.
Makedocs helps you in creating "auto-generated documentation". It links your information between code and documentation pages.
Using Makedocs, you can create project documentation with less efforts conveniently and effectively.

Implementation

I have created a sample project which helps you in understanding the basics of code linting and live documentation.

Source Code : encode_decode

Documentation : Encode Decode Docs

The documentation is always live and you can access it anytime.

Please go through the following resources that will help you in understanding the concepts and the implementation better.

Happy Learning !!!

Acronyms used in Software Design Practices

Anurag Patil — Thu, 10 Aug 2023 12:32:07 +0000

While working in the field of software engineering or software development for several years, we come across some acronyms or say technical jargons which we are totally unaware of.

We often listen to these in the technical discussions with your Architect or in the Code Reviews.

We also been told to follow clean coding practices or principles, follow some good practices or coding and design standards if given.

Here, in this blog, I will try to make you aware of some acronyms which are used more often in the industry while working. I have tried to keep it short and concise. People often get bored reading lengthy posts. :P

I have tried to make this easy-peasy for you so that you can remember them and implement in your day-to-day activities. Also, to help you be the smart guy in the room !! ;)

One of my favorite lines I came along is :

Code represents knowledge. By giving meaning to certain parts of the code, we are identifying and labeling that knowledge.

DRY/OAOO

DRY stands for Don't Repeat Yourself and OAOO stands for Once and Only Once.

These are self explanatory which says that you should avoid code duplication at all costs.

In code, whatever it may be, should be written only once and in a single place.
If there are any modifications to be done in the future, they should be done in that specific location ( here location means class or function or module ).
Failure to do so is a sign of poor software design.
Code duplication affects maintainability. Some of its cons are:

It is error-prone.
It is expensive.
It is unreliable.

YAGNI (You Ain't Gonna Need It)

Sometimes, while developing a software we think of the future enhancements or requirements and try to make the code future-proof. As a result, we create solutions that are complex or create abstractions which are hard to maintain.
After sometime, we get to know that these requirements are not required at all and we end up piling the unnecessary code. And sometimes, due to this the code which we actually need for our current requirements does not work at all.
Feels like a waste of time right ?
YAGNI principle tells us that , do not try to perform futurology or future-proof code.
While designing your system, make sure that you are only addressing your current requirements in such a way that it can be easily modified later on.
Do not over-engineer !!!
Do not develop or design more than what is necessary.

KIS/KISS (Keep It Simple / Keep It Simple, Stupid )

You may have come across this term many times. This principle very much relates to our previous point.
This principle says that implement minimal functionality which correctly solves your problem.
In other words, satisfies your current requirement and does not complicate it more than what is necessary.
This principle is what we need to keep in mind at all levels of abstraction. While designing a microservice on a higher-level or defining a function or writing a particular line of code.
At a code level, it simply means using the smallest data structure that fits the problem statement.

EAFP/LBYL

EAPF stands for Easier to ask Forgiveness than Permission while LBYL stands for Look Before You Leap.
EAPF tells us that we write our code so that it performs some execution directly. If the code does not work, we will catch the exception and try to execute some corrective logic on the except block.
We often see this approach used by many developers.
It goes something like this.

try:
    # your running code
except SomeMeaningfulException as e:
    # corrective actions

LBYL principle is exactly opposite to that of EAPF.
In this approach, we check what we are about to use or perform.
For example, before opening a file in the program, we want to check if that file actually exists in the given path or not.
Both of the principles makes sense in a particular code or action. EAFP is more acceptable as it is easier to pick at the first glance.
I would suggest to pick up the EAFP when in doubt.

So these are the most common principles you will come across while developing a software and we should take utmost care that these principles are being followed.

Some of them you make come across while implementing Design Patterns in your system.

I hope am able to deliver this topic in a simple and in an effective way. Feedbacks and suggestions are always welcomed.

Happy Learning !!!

Design Patterns in Python : Factory method

Anurag Patil — Fri, 28 Jul 2023 07:12:55 +0000

Design Patterns represent an idea, not a particular implementation. By using it, you can make your code more flexible, maintainable, reusable and scalable.

Design Patterns are reusable programming solutions that have been used in various real-life contexts. There are several categories in Object-Oriented Programming, depending on the type of problem it addresses and the type of solution it helps to build.

They are split into 3 categories :

Creational
- Deals with different aspects of object creation.
Structural
- Proposes a way of composing objects for creating new functionality
Behavioral
- Deals with the communication or interaction of objects

Am going to discuss one of the creational design patterns here which is the Factory method.

I have tried to make this as simple as possible so that the novice programmers will also be able to understand what actually are design patterns and why there are used or recommended.

Lets get started.

Introduction

It is used for providing convenient and better alternatives for object creation.

In this factory design pattern, the client (means the client code) asks for object creation without knowing where the actual object creation is happening or where is it coming from or which class is used to generate that object.

This makes it easier to track the objects getting created instead of making the client take care of the direct class instantiation process ( directly creating the object from the class).

This design pattern helps us in decoupling or separating the logic of object creation from the logic that uses it.

When to use it

If you realise that you cannot track the objects created by the application because there are too many objects created at different places, you should consider using factory method.
Most useful use case is defining a method which returns the database instance creation based on the type of database used.
Whenever there is a change happening, we can change it in a single function and there is no need to change the code which uses that object.
One more important use case is the improvement in the memory allocation and its performance.
At every object creation, memory is allocated. If the object is not used somehow for some time, the allocated memory is just a wasteful allocation. Also, extra memory allocation happens when any new object is created.

Below is a small illustration of the above use case.

class A:
    ...


if __name__ == "__main__":
    a = A()
    b = A()
    print(id(a), id(b))

which gives the below output. It shows 2 different memory allocation happened.

Even if we need the object "a" to execute some actions, "b" will still be created and allocated memory; which is not convenient.

Implementing factory pattern

I have tried to illustrate the factory pattern using a really simple program. You can try to refactor your existing code or write a new one taking reference to this example.

Okay, so lets create an abstract class first which will keep the program consistent.

from abc import ABC, abstractmethod


class Animal(ABC):
    @abstractmethod
    def make_sound(self):
        pass

Now, lets create two classes which can inherit the Animal properties.

class Dog(Animal):
    def __init__(self):
        self.name = "Mike"

    def __str__(self):
        return self.name

    @property
    def make_sound(self):
        return "bow wow"

class Cat(Animal):
    def __init__(self):
        self.name = "Alexa"

    def __str__(self):
        return self.name

    @property
    def make_sound(self):
        return "meow"

We will now create a factory method which returns an instance of either Cat class or a Dog class depending upon the animal type we give as an argument to the function.

def animal_invoke_factory(animal: str) -> Animal:
    animal_type = animal.lower().strip()

    if animal_type == "cat":
        result = Cat
    elif animal_type == "dog":
        result = Dog
    else:
        raise ValueError(f"Unable to find {animal}")

    return result()

Am creating a wrapper function around the animal_invoke_factory() function. It also handles the exception raised by the animal_invoke_factory() function.

def get_animal(animal: str) -> Animal:
    factory_obj = None

    try:
        factory_obj = animal_invoke_factory(animal)
    except ValueError as error:
        print(error)

    return factory_obj

Below main() function calls the get_animal() function with the appropriate parameters.

def main():
    animal = get_animal("cat")
    print(f"{animal} says {animal.make_sound}")

Code Repo

Please find the entire code here.
Factory Design Pattern

That's it !
We are able to implement the factory pattern in a most simple way possible.

I have tried to make it simple to understand and visualize the concept.
Please let me know your reviews/feedbacks or any suggestions you have.

Happy Learning !!!

Pub-Sub Architecture using FastAPI and Redis

Anurag Patil — Mon, 17 Jul 2023 08:07:31 +0000

I have tried to implement Redis as a message broker using FastAPI. Its a simple implementation to give a headstart for the event driven architecture.

Below is the high-level view for what I have implemented.

Clone the repo from here and give it a shot.

Please feel free to go through it and let me know your suggestions.
Hope to get some positive response as its my first ever post on any community platform so far ..:)

Happy Learning !!!