DEV Community

Cover image for Turning My Social Media Automation Scripts into a Clean OOP Architecture 🚀
Bharath Kumar_30
Bharath Kumar_30

Posted on

Turning My Social Media Automation Scripts into a Clean OOP Architecture 🚀

#python #oop #webdev #programming

Today was one of those “this will make my project actually look like real software” days.

Until now, my Social Media Post Automation System was working — but honestly, the code looked like a collection of separate scripts. I had individual programs for:

  • LinkedIn posting
  • Facebook posting
  • Instagram posting
  • Telegram group messaging

Each one worked, but everything was independent. If I wanted to run them together, I had to manually trigger each script. Not exactly the “one-click automation platform” vision I had for my project.

So today’s task was simple (but also slightly scary):
convert everything into an Object-Oriented Architecture.

Why I Needed OOP

My guide suggested something important:
Instead of writing platform code everywhere, each platform should be its own service class.

That way the system becomes easier to manage and scale.

The new structure looks like this:

social_automation/
│
├── main.py
│
├── services/
│   ├── linkedin_service.py
│   ├── facebook_service.py
│   ├── instagram_service.py
│   └── telegram_service.py
│
└── manager/
    └── social_manager.py
Enter fullscreen mode Exit fullscreen mode

Each platform handles its own logic, and a central manager coordinates everything.

This is actually how many real automation tools are structured.

Creating Service Classes

Instead of writing everything inside one file, each platform now has its own class.

For example, LinkedIn became something like this:

class LinkedInService:

    def __init__(self, access_token, author_urn):
        self.access_token = access_token
        self.author_urn = author_urn

    def post(self, text):
        # send post request to LinkedIn API
        pass
Enter fullscreen mode Exit fullscreen mode

Now the LinkedIn logic lives in one clean place.

I repeated the same idea for:

  • FacebookService
  • InstagramService
  • TelegramService

Each one knows how to talk to its platform API.

The Automation Manager

This was the most interesting part.

Instead of manually calling each platform, I created a SocialMediaManager.

class SocialMediaManager:

    def __init__(self, linkedin, facebook, instagram, telegram):
        self.linkedin = linkedin
        self.facebook = facebook
        self.instagram = instagram
        self.telegram = telegram

    async def post_all(self, message):
        self.linkedin.post(message)
        self.facebook.post(message)
        self.instagram.post(message)
        await self.telegram.send_message(message)
Enter fullscreen mode Exit fullscreen mode

Now my system finally behaves like a real automation platform.

One call:

manager.post_all("Hello world!")
Enter fullscreen mode Exit fullscreen mode

And the post goes everywhere.

Connecting Everything with FastAPI

The backend now uses FastAPI to trigger the automation.

The API endpoint looks something like this:

@app.post("/post")
async def post(message: str = Form(...)):
    await manager.post_all(message)
    return {"status": "posted"}
Enter fullscreen mode Exit fullscreen mode

So the flow is now:

User
 ↓
Web Interface
 ↓
FastAPI Endpoint
 ↓
SocialMediaManager
 ↓
Platform Services
 ↓
LinkedIn | Facebook | Instagram | Telegram
Enter fullscreen mode Exit fullscreen mode

Seeing the architecture finally come together was pretty satisfying.

What I Learned Today

A few takeaways from today's work:

• OOP makes projects much easier to organize
• Service-based architecture keeps platform logic separated
• A manager/controller layer simplifies automation
• Designing architecture early saves a lot of headache later

Also… debugging async Telegram code while Instagram waits for media processing definitely tested my patience today 😅

What’s Next

Now that the architecture is ready, the next steps for the project are:

  • Add a dashboard UI
  • Allow selecting which platforms to post to
  • Store credentials securely
  • Add post history

The goal is still the same:

Write one post → publish everywhere.

Slowly getting there.

If you're building automation tools or integrating multiple APIs, I'd love to hear how you structure your projects.

Top comments (1)

Collapse
 
klement_gunndu profile image
klement Gunndu •

The SocialMediaManager pattern is a solid step. One gotcha I ran into with similar designs — make the post methods async across the board, otherwise one slow API blocks the whole chain.