The Adventures of an Indie Hacker: Learning to Choose Frameworks the Funny Way

Building a SAAS application with the latest tools and technologies is like diving into a candy store, but sometimes, it’s like going through a haunted house. As an indie hacker, I’m one of those curious developers who can’t resist exploring new languages, frameworks, and tools. I mean, who doesn’t want to stay updated and hip with the latest tech, right? Using languages and web-framework based on surveys like this and this for building applications would make me feel good and updated. But little did I know, it’s like walking through a maze full of twists and turns, and it can give you a headache.

Learning to Choose Frameworks the Hard and Hilarious Way

My primary app right now is Hellokea. It’s like a Swiss Army Knife for indie hackers, with all the features to market their products with ease. But building it is no piece of cake, especially when you’re a one-person band. I’ve tried two different frameworks to build it, and boy, what an adventure it was.

Phoenix Framework - Like a Phoenix Rising from the Ashes

If you’re from a Ruby on Rails background, you’ll love Phoenix. It’s like Rails, but with a twist. But the lack of libraries for doing tasks makes it hard to build web applications on your own. As an indie hacker, you want to get things done fast. That’s why I stopped development with Phoenix. But hey, if the ecosystem gets rich with all the libraries, I’ll go back to Phoenix like a phoenix rising from the ashes.

Nodejs Wonderland - Welcome to the Mad Tea Party

No one can deny that Nodejs is a treasure trove of third-party libraries and frameworks. So, I jumped right in and started building applications with Express, Postgres, and Vue. The backend was handled by Express and Postgres, while VueJs took care of the frontend. It all looked so tempting and easy to use. I’ve had some experience with Vuejs before, and let’s just say it’s quite expressive and quicker to build things than my morning cup of coffee.

The best part of the javascript world is the vast array of libraries and tools available. For handling tons of inbound emails for the helpdesk system, I found Haraka to be a battle-tested email framework that did the job perfectly. One could easily add a plugin to handle certain tasks and hook that up with your stack. With all this, it was a cakewalk.

But then came the upgrade. When it comes to upgrading the javascript ecosystem, it’s like crossing your fingers and hoping for the best (at least for me). You never know what’s going to break. Sure, you could say that about almost all frameworks, but with Node, I made the mistake of choosing heaps of libraries for quickly building Hellokea. Upgrading every single library you’ve used is a tedious task. And, it didn’t stop there. I also had to update my frontend Vuejs. Finally, I just got tired and lost interest. Lesson learned - don’t go down the rabbit hole of too many libraries.

Python and Django - The Holy Grail

Finally, my hunt ended with Python and Django. It’s like finding the Holy Grail after going through a long quest. With its rich libraries and tools, building Hellokea is like walking in the park. So if you’re an indie hacker like me, take my advice and stick with what works.

Why Django?

Choosing Django has been one of the best things I’ve done in my development journey! With almost all the built-in features I needed for this project, including authentication, views, middleware, and admin, Django has made my life so much easier. It’s like having a trusty sidekick that takes care of all the heavy lifting!

What’s even better is that Django’s built-in features make updating projects a breeze. No more worrying about compatibility issues with third-party libraries, because Python has an extensive library collection that works perfectly with Django.

And speaking of libraries, I’ll be writing more tech posts soon on some amazing ones, like BeautifulSoup and inbound email handling. Stay tuned for some serious geeking out!

The whole helpdesk system is now complete, and it’s purely built with Django and Htmx. So, if you want to save yourself from the maze of twists and turns while building an application, choose Django! Trust me; it’s like having a superhero by your side, always ready to save the day!

If you are reading this article, I believe, it’s safe to assume you have at least a basic knowledge of what caching is.  Hellokea is built using the Django framework. At the time of this post, our front end is also built and managed using Django.  We are pretty happy to use Django’s admin feature for posting our blog posts and other resources. Most of the time, the website loads with a decent speed passing all Google’s page insights. There are times when loading the front page of the website could take a couple of more milliseconds when the servers are busy serving our users. This is where caching shines.

Redis and Cache

Redis is our primary go-to server for caching, WebSockets and queuing. For processing backend tasks, Celery along with Redis is used for queuing tasks. We are still in the early stage of development serving very few customers, and managing different caches is kind of an overkill. Every single operation is allocated a different Redis database. For eg: Celery queues use Redis Database 1, WebSockets uses Redis database 2 and so on.  Django cache is fantastic at handling multiple cache settings. Configuring cache in Django is through the settings file.

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.redis.RedisCache',
        'LOCATION': 'redis://127.0.0.1:6379/1',
    }
}

The above snippet is a sample for using Redis Cache in Django. In our case, we use multiple caches like

CACHES = {
   'public_website': {
        'BACKEND': 'django.core.cache.backends.redis.RedisCache',
        'LOCATION': 'redis://127.0.0.1:6379/1',
    },
    'sockets': {
        'BACKEND': 'django.core.cache.backends.redis.RedisCache',
        'LOCATION': 'redis://127.0.0.1:6379/2',
    },
    'feed': {
        'BACKEND': 'django.core.cache.backends.redis.RedisCache',
        'LOCATION': 'redis://127.0.0.1:6379/3',
    },
} 

To access any of the caches, all you have to do is either use the cache_view decorator per view basis or do it manually.  Now, let’s take a real-world scenario as an example. This website page you are reading uses thecache_view decorator to store the computed blog post information in the Redis database on 1 which is  public_website.  The website is cached for a minimum of 15-30 minutes depending on the page. What happens when we have to update the page? We have to clear the cache and update it with the latest data from the database.  The interesting part here is clearing the cache.

Clearing caches

Though cache could improve the speed of the website, there would be a scenario where you have to invalidate the cache data to get an updated one. Django makes this so enjoyable. A classic example is when creating or updating a page or a blog post on the website. When updating or creating, override the model save method, assuming you are managing it through admin, to invalidate the cache.

from django.core.cache import caches

public_cache = caches["public_cache"]
public_cache.clear()

The snippet clears all the cache associated with the public_website. It’s totally up to your logic to decide on invalidating the cache. Generally, pages which are rarely updated could easily be cached for a very long period of time thereby reducing the database hits. We do have actions in the admin panel to clear caches if there are any changes to pages.