Forem: Papan Sarkar

Prototyping just went from "Hours" to "Minutes." ⚡️

Papan Sarkar — Fri, 05 Dec 2025 17:19:32 +0000

I remember when setting up a clean, responsive dashboard meant wrestling with boilerplate code for half a day.

Today, I challenged Google AI Studio to build a fully functional Personal Finance Dashboard using React, Tailwind CSS, and Recharts.

The result? A stunning, dark-mode UI with "Bento Grid" layout and glassmorphism effects—generated in under 120 seconds. 🤯

Why this matters for developers: It's not about AI replacing us. It's about "Velocity to V1." Instead of spending 4 hours on the UI shell, you spend 2 minutes generating it, and the next 3 hours and 58 minutes on the actual logic and backend architecture.

The Reality Check: Yes, this is a frontend prototype. It still needs a secure backend, auth, and database. But the visual heavy lifting? Done.

I shared the full breakdown and code in my latest YouTube Short.

What you see here is a Frontend Prototype (the interface). It looks great, but to turn this into a real, working app, you still need: A Backend (Logic to handle transactions). A Database (To actually save user data). Authentication (Secure login/signup).

The Reality: AI is an amazing tool to speed up the design and boilerplate code, but you still need to understand programming to connect the pieces and make it secure! Use this to prototype fast, not to skip learning the basics.

🚀 Need to turn your idea into a working product fast? Check out how we build high-performance MVPs at Yestoideas

🚀 Supabase Connection Scaling: The Essential Guide for FastAPI Developers

Papan Sarkar — Fri, 14 Nov 2025 18:24:55 +0000

Building a scalable FastAPI backend requires mastering database connections. When using Supabase (PostgreSQL), choosing the wrong connection method is the fastest way to crash your server under load. This guide clarifies the critical difference between Transaction Mode and Session Mode to help you choose the right path for high performance.

🔒 The Connection Pooler: Your Database’s Gatekeeper

Every Supabase project includes a Connection Pooler (Supavisor/PgBouncer). Its job is to efficiently manage traffic between your many client applications and your limited database resources.

The “Lobby” (Max Client Connections): This is the high limit (e.g., 200 on Nano). It’s the total number of clients that can connect to the pooler.
The “Tellers” (Pool Size / Backend Connections): This is the low, resource-intensive limit (e.g., 15–20 on Nano). It’s the number of actual PostgreSQL processes available to run queries.

The core challenge is enabling hundreds of clients in the Lobby to efficiently share just 20 Tellers.

1. Transaction Mode: Lightning-Fast Exchange (Port 6543) ⚡

Transaction Mode is the mandatory choice for scalable, high-concurrency web APIs.

How it Works: A client (your FastAPI endpoint) borrows a Teller only for the duration of a single transaction or query. The moment the transaction commits, the Teller is immediately released back to the pool for the next waiting client.
Analogy: The Express Lane at a bank. You quickly finish your one task, and the Teller is free instantly.
Advantages: Maximizes throughput and concurrency. A few connections can handle a high volume of requests because no connection is ever held idle.
When to Use: Default mode for all general-purpose web traffic, serverless functions, and short-lived tasks.
Supabase Port: 6543.

2. Session Mode: The Dedicated Teller (Port 5432) 🔑

Session Mode is a stateful mode designed for compatibility and long-running tasks.

How it Works: A client connection permanently holds a specific backend connection (Teller) for the entire duration of the client’s session, even when the client is idle. The connection is only returned when the client disconnects.
Analogy: The Personal Banker. You keep the banker until your entire long meeting is over, making them unavailable to others.
Advantages: Provides Full PostgreSQL Compatibility for features that require persistent state.
When to Use: Database migrations, admin tools, debugging, or complex background jobs that rely on setting session variables (SET TIME ZONE) or using temporary tables.
Supabase Port: 5432 (the default PostgreSQL port).

🛑 The Critical Pitfall: Running FastAPI in Session Mode

If your FastAPI backend connects on Port 5432, your entire application operates in Session Mode, leading to three major stability risks:

Rapid Limit Exhaustion: Your application effectively ignores the 200 client limit and is capped by the 20 Pool Size. If 21 instances or users connect, the 21st is blocked, even if the first 20 are idle.
Memory Overload: Holding 20+ persistent connections on a small instance (like Nano) quickly exhausts the server’s limited RAM, forcing the database into a read-only state to prevent a crash.
Connection Leakage: Any connection not cleanly closed by FastAPI will remain stuck, eventually using up all 20 backend connections permanently.

🛠️ The Essential Code Fix: Disable Prepared Statements

The migration to Transaction Mode (Port 6543) requires a vital code change because it breaks a common optimization feature: Prepared Statements.

The Conflict: Prepared statements are an efficiency feature that involves storing a pre-compiled query plan on a specific session (backend connection). When Transaction Mode swaps the connection, the new connection cannot find the stored plan, causing the frequent and fatal prepared statement “…” does not exist error.
The Solution: You must configure your Python database driver or ORM (like SQLAlchemy with asyncpg) to explicitly disable prepared statements by setting the cache size to zero.

Python/FastAPI Configuration (SQLAlchemy + Asyncpg)

This code snippet is the necessary modification when pointing your FastAPI backend to Port 6543.

from sqlalchemy.ext.asyncio import create_async_engine
from sqlalchemy.pool import NullPool 

# ⚠️ Change port to 6543
DATABASE_URL = "postgresql+asyncpg://user:pass@host.supabase.co:6543/postgres" 

engine = create_async_engine(
    DATABASE_URL,
    # Use NullPool: Let the external pooler (Supavisor) manage connections, not the app.
    poolclass=NullPool, 
    connect_args={
        # CRITICAL: Disables statement caching, fixing the Transaction Mode conflict
        "statement_cache_size": 0, 

        # Ensures asyncpg also respects the cache being disabled
        "prepared_statement_cache_size": 0, 
    },
)

Note: If using the pure psycopg3 driver, you would typically pass prepare_threshold=None to the connection pool configuration.
Conclusion

For a scalable FastAPI application on Supabase, always start with Transaction Mode (Port 6543) as your default for all API traffic. This choice maximizes concurrency and efficiency. Reserve Session Mode (Port 5432) only for specialized, stateful tasks like migrations or admin scripts. The main takeaway: Enable Port 6543 and disable prepared statements to unlock optimal scalability and prevent stability issues.

Dynamic Serializers in Django

Papan Sarkar — Wed, 17 Apr 2024 18:24:08 +0000

Dynamic serializers are extremely useful to make flexible APIs.

Why do we need dynamic serializers

Flexibility: It provides flexibility. We often run into issues, where we need a serializer but not all the fields from that serializer. In that case dynamic serializers are especially useful to use subsets of data.

Code Reusability: No need to write multiple serializers anymore, a single dynamic serializer can achieve various needs.

Performance: If we only pick the fields we need, it will immensely improve the overall performance.

While it has good advantages, it comes with few complexities as well. It can make debugging a little difficult and we can come across with errors if we do not follow good practices and test all kind of edge cases.

Implementation:

class DynamicSerializer(ModelSerializer): 

    """
    A ModelSerializer that takes an additional 'fields' 
    argument that controls which fields should be displayed. 
    """


    def __init__(self, *args, **kwargs): 

        fields = kwargs.pop('fields', None) 

        # Instantiate the superclass normally 

        super(DynamicFieldsModelSerializer, self).__init__(*args, **kwargs) 

        if fields is not None: 

            # Drop any fields that are not specified in the `fields` argument. 

            allowed = set(fields) 
            existing = set(self.fields.keys()) 
            for field_name in existing - allowed: 
                self.fields.pop(field_name)


# Example usage in a view 
class UserSerializer(DynamicFieldsModelSerializer): 
    class Meta: 
        model = User 
        fields = '__all__' `


# In your view 
serializer = UserSerializer(user, fields=('id', 'username', 'email'))

Conclusion:

Dynamic serializer is powerful tool in Django, especially for large and complex projects.

Proper implementation and thorough testing are important to achieve good and optimised results.

Don't write queries inside serializers in Django!

Papan Sarkar — Sat, 13 Apr 2024 14:36:06 +0000

Why?

It should focus data conversion and validations only. Don't write database logic on this.
Not efficient and bad performance. It will create lots of queries
You can not reuse it
Very hard to test
Readability is gone

I can share the alternatives if you want! Let me know

Do's and Don'ts in Django

Papan Sarkar — Fri, 12 Apr 2024 17:34:42 +0000

Do’s

Use meaningful variables: We should use clear, concise, and self-explanatory variables, functions, and classes name.

DRY: Don’t Repeat Yourself. We should reuse code as much as possible. Once you are done with the code, take 10 minutes to think what the possibilities are to improve it further and make it optimal.

Use Django features: On daily basis, we receive unique requirements which is consist of unique business logic for those cases we often write flexible code to solve a problem, which is fine but again it might not be the optimal solution. So again, take 10 minutes extra to research how could you have done this differently keeping a standard approach and solution.

Quick related note: It is very normal to think of a custom solution first, however it helps or comes to your head. No one solves a problem in the first go with the best possible solution and standards. It is always the next set of iteration which makes the difference.

Do a security check: Always do a security check once you are done with a task. Think of edge cases which can eventually create a problem. If needed get on a call with someone and share your thoughts and understanding, you will get more clarity with another set of eyes.

Follow PEP8: Since so many people are working on the same code, and we are trying to make it more readable and understandable. It is especially important that we make use PEP 8 style guide for Python code.

Don’ts

Do not write Complex Queries on serializers: Avoid writing complex queries on serializers or any serializer methods. Prefetch data in views instead.

Don’t write generic views all the time: Generic views are super useful and powerful but do not use it when it is not required. If the requirement is simple and straightforward write Functional views instead.

**Don’t keep unlimited access to endpoints (Rate Limiting): **Implement rate limiting to protect APIs.

Don’t write nested serializers: Nested serializers can produce inefficient queries and effect performance. Create different endpoints for these cases or change the data structure.

Don’t write business logic inside views or serializers: It is one of most important things to consider when building a huge project consists of lots of business logic. Business logic should be written in service layer, model property methods etc.

Take a Ten Minute Walk: A Codewars kata solution By Papan Sarkar

Papan Sarkar — Wed, 07 Oct 2020 08:41:24 +0000

Take a Ten Minute Walk: A Codewars kata solution
In this article, I'll explain a kata solution from Codewars. This kata(problem) is authored by JKphobic. And here is the kata
link:https://www.codewars.com/kata/54da539698b8a2ad76000228/train/python

Problem:
You live in the city of Cartesian where all roads are laid out in a perfect grid. You arrived ten minutes too early to an appointment, so you decided to take the opportunity to go for a short walk. The city provides its citizens with a Walk Generating App on their phones -- every time you press the button it sends you an array of one-letter strings representing directions to walk (eg. ['n', 's', 'w', 'e']). You always walk only a single block for each letter (direction) and you know it takes you one minute to traverse one city block, so create a function that will return true if the walk the app gives you will take you exactly ten minutes (you don't want to be early or late!) and will, of course, return you to your starting point. Return false otherwise.

Note: you will always receive a valid array containing a random assortment of direction letters ('n', 's', 'e', or 'w' only). It will never give you an empty array (that's not a walk, that's standing still!).

First of all, we need to understand the problem. Then we will see what it's input and of course what kind of output it wants from us.

If you read the problem twice or thrice, you'll see a few things like what things we need to keep in our minds. Like :

The walk has to be for 10 minutes.
You need to return to the starting point
Every list item (each letter) or single block represents one minute

Let's convert these instructions into code and make small segments of the whole solution code:
So,

if len(walk) == 10 //True
else // False

We'll create two variable and initialize to 0 to track our walk, ns (North-South) and ew (East-West) -

ns = 0
ew = 0

For every single block we walk, respectively we'll increment and decrement with 1

if we move in n direction then ns += 1
if we move in s direction (coming back) then ns -= 1
if we move in e direction then ew += 1
if we move in w direction (coming back) then ew -= 1

And then finally we will check we returned to our same position or not

if ns == 0 and ew == 0 //True
else //False

Let's combine all this:

# Python Solution
def is_valid_walk(walk):
    ns, ew = 0, 0
    if len(walk) == 10:
        for i in walk:
            if i == 'n': ns+=1
            if i == 's': ns-=1
            if i == 'w': ew+=1
            if i == 'e': ew-=1
    else:
        return False
    return ns == 0 and ew == 0

//Javascript solution
function isValidWalk(walk) {
    let ns = 0, ew = 0; 
    if(walk.length === 10){
      for (let i of walk) { 
        if (i == 'n') ns += 1; 
        if (i == 's') ns -= 1; 
        if (i == 'e') ew += 1; 
        if (i == 'w') ew -= 1; 
      } 
    }
    else
      return false
      return ns === 0 && ew === 0; 
  }

Now it's time to some other best and clever solutions:
Most upvoted:

def isValidWalk(walk):
    return len(walk) == 10 and walk.count('n') == walk.count('s') and walk.count('e') == walk.count('w')

Second one:
def isValidWalk(walk):
    if (walk.count('n') == walk.count('s') and 
        walk.count('e') == walk.count('w') and
        len(walk) == 10):
            return True
    return False

I hope it was helpful and useful. Please let me know your thoughts. Thank You for reading.

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." - Martin Fowler