jevithos

Posted on Jul 23

How I Built a Plugin-Based File Converter with Python

#webdev #python #opensource #architecture

When I started building Converigo, I thought the biggest challenge would be converting files.

I was wrong.

The real challenge wasn't converting a PDF or an image—it was designing a system that could continue to grow without becoming a maintenance nightmare.

At first, adding a new converter was straightforward. A few functions, a couple of routes, and everything worked as expected.

But after adding more formats, I realized the project was heading toward a common problem: the core application was becoming responsible for everything.

That wasn't going to scale.

The Problem

Many projects begin with something like this:

if converter == "jpg_to_pdf":
    convert_jpg_to_pdf(file)

elif converter == "pdf_to_word":
    convert_pdf_to_word(file)

elif converter == "png_to_webp":
    convert_png_to_webp(file)

elif converter == "mp4_to_mp3":
    convert_mp4_to_mp3(file)

There's nothing wrong with this approach when you only have a few converters.

But what happens when you have 20?

Or 50?

Or even 100?

Every new format requires editing the core application.

Every change increases the risk of breaking something that already works.

Maintenance becomes slower.

Testing becomes harder.

Eventually, the converter engine becomes a giant file that nobody wants to touch.

Rethinking the Architecture

Instead of making the application responsible for every conversion, I decided that each converter should be responsible for itself.

The solution was a plugin-based architecture.

Rather than storing every converter inside one large application, each conversion format lives in its own module.

plugins/

├── image/
│   ├── jpg_to_png.py
│   ├── png_to_jpg.py
│   └── webp_to_png.py
│
├── document/
│   ├── pdf_to_docx.py
│   ├── docx_to_pdf.py
│   └── pdf_to_xlsx.py
│
├── audio/
│   └── mp4_to_mp3.py
│
└── video/

This simple separation completely changed the development experience.

A Common Interface

Every converter follows the same interface.

class ConverterPlugin:

    async def convert(
        self,
        source_path,
        target_format
    ):
        pass

Because every plugin behaves the same way, the engine doesn't need to know how each conversion actually works.

It simply discovers the appropriate plugin and executes it.

Adding support for another file format becomes much easier.

No huge refactoring.

No giant switch statements.

No complicated routing logic.

Just add another plugin.

Why This Works Better

Moving to a plugin-based architecture immediately brought several advantages.

Easier Maintenance

Each converter is isolated.

Fixing a PDF converter doesn't affect image converters.

Better Testing

Every plugin can be tested independently.

Regression testing becomes much simpler.

Cleaner Code

Instead of one massive conversion engine, responsibilities are clearly separated.

Finding bugs is easier.

Reviewing pull requests becomes faster.

Better Scalability

Adding a new converter is mostly independent work.

As the project grows, the architecture grows with it.

Lessons Learned

One thing surprised me during development.

The hardest part wasn't writing conversion logic.

It was designing an architecture that would still feel clean after adding dozens of converters.

Looking back, spending extra time on architecture early saved much more time later.

Good architecture doesn't make software more complicated.

It makes future development much simpler.

What's Next

The plugin system is still evolving.

Some improvements I'm currently working on include:

More conversion formats
Better validation
Performance optimization
Batch conversion
Public API
AI-powered recommendations

The goal is simple.

Adding a new converter should require as little effort as possible while keeping the existing system stable.

Final Thoughts

Building software isn't only about solving today's problem.

It's also about making tomorrow's changes easier.

A plugin architecture won't be the right solution for every project, but for a growing file conversion platform, it has proven to be a practical and maintainable approach.

I'm curious how other developers would approach this challenge.

Would you choose a plugin system, microservices, or something completely different?

I'd love to hear your thoughts in the comments.

If you're interested in the project, you can check out Converigo:

🌐 https://converigo.com

I'm always happy to hear feedback, suggestions, and ideas for improving the platform.

If you've built a plugin-based architecture before, I'd love to know what worked well for you.

DEV Community