DEV Community

Cover image for Building Static Social Media Connect Pages & Fixing OOP Errors in My Automation Project
Bharath Kumar_30
Bharath Kumar_30

Posted on

Building Static Social Media Connect Pages & Fixing OOP Errors in My Automation Project

Today was one of those “small work but big progress” days in my Social Media Post Automation System project.

Instead of writing more backend logic, I focused on two important things:

  • Creating static HTML pages for social media connections
  • Fixing OOP structure issues in my automation code

Simple tasks… but they helped clean up the project architecture a lot.


Why Static HTML Pages?

My system connects with multiple platforms:

  • LinkedIn
  • Facebook
  • Instagram
  • Telegram

Each platform needs API credentials and setup steps, and during testing I realized something:

Every platform has its own setup process and documentation.

So instead of mixing everything into one messy page, I created separate static HTML pages for each platform.

Now each page shows:

  • Step-by-step setup instructions
  • Required API credentials
  • Input fields for tokens / IDs
  • A connect button

Basically a mini setup guide inside the project UI.


Example: Instagram Connect Page

For example, the Instagram page explains how to:

  1. Convert the account to Instagram Business
  2. Connect it to a Facebook Page
  3. Create an app in Meta Developers
  4. Enable Instagram Graph API
  5. Generate a Page Access Token
  6. Find the Instagram Business ID

Then users can enter credentials directly in the page.

Simple, clear, and much easier for testing.


Fixing My OOP Structure

Another thing I worked on today was cleaning up my Object Oriented Programming structure.

Earlier my automation scripts were written like separate programs:

  • One script for Telegram
  • One for Instagram
  • One for Facebook
  • One for LinkedIn

That worked, but it wasn't scalable.

So I started reorganizing everything into service classes.

Example structure:

services/
 ├── linkedin_service.py
 ├── facebook_service.py
 ├── instagram_service.py
 └── telegram_service.py
Enter fullscreen mode Exit fullscreen mode

Each platform now has its own class with functions like:

post()
connect()
validate_credentials()
Enter fullscreen mode Exit fullscreen mode

Then a manager class controls everything.

SocialMediaManager
        |
        ├── LinkedInService
        ├── FacebookService
        ├── InstagramService
        └── TelegramService
Enter fullscreen mode Exit fullscreen mode

Now my automation system can simply call:

manager.post_to_selected_platforms()
Enter fullscreen mode Exit fullscreen mode

Much cleaner.


Debugging the OOP Errors

While converting everything into classes, I hit a few classic beginner problems:

  • Missing class imports
  • Async errors with Telegram
  • Incorrect method calls
  • Variables not being passed correctly

Nothing dramatic… just the usual “why is this not working?” moments 😅

After fixing those issues, the system finally started running smoothly again.

And honestly, debugging like this teaches more than writing the code itself.


What I Learned Today

A few small but useful lessons:

  • Separate UI setup pages make integrations easier to manage.
  • OOP structure helps organize multi-platform automation.
  • Debugging errors is normal when restructuring code.
  • Even simple HTML pages can improve project usability.

Sometimes progress isn't about writing hundreds of lines of code.

Sometimes it's just cleaning things up so the system makes sense.


What’s Next?

Next steps for the project:

  • Integrate all platforms into one posting dashboard
  • Allow selecting platforms before publishing
  • Improve UI design
  • Deploy the automation system

Slowly but surely, the automation platform is coming together.

And yes… still powered by a lot of coffee and debugging sessions. ☕


Thanks for reading!
If you're building automation tools or API integrations, I'd love to hear about your experience too.

Top comments (2)

Collapse
 
pannous profile image
pannous

Great progress, Bharath! The move from standalone scripts to service classes is the right direction. A few architectural suggestions:

1. Define a common interface (Abstract Base Class)

This enforces a contract so the manager never needs to know which platform it talks to (Strategy Pattern):

from abc import ABC, abstractmethod

class SocialMediaService(ABC):
    @abstractmethod
    async def connect(self) -> bool:
        """Authenticate with the platform."""

    @abstractmethod
    async def post(self, content: str, media: list[str] | None = None) -> dict:
        """Publish content. Returns response with post ID."""
Enter fullscreen mode Exit fullscreen mode

2. Make the manager generic

With a shared interface, the manager never needs modification when you add a new platform:

class SocialMediaManager:
    def __init__(self):
        self.services: dict[str, SocialMediaService] = {}

    def register(self, name: str, service: SocialMediaService):
        self.services[name] = service

    async def post_to_selected(self, platforms: list[str], content: str, media=None):
        results = await asyncio.gather(*(
            self.services[p].post(content, media)
            for p in platforms if p in self.services
        ), return_exceptions=True)
        return dict(zip(platforms, results))
Enter fullscreen mode Exit fullscreen mode

Notice return_exceptions=True — one failing platform won't kill the others.

3. Async from the start

Telegram's API is inherently async (python-telegram-bot v20+). Mixing sync and async is the #1 source of pain. Make every service method async, even if the SDK is sync — just wrap with asyncio.to_thread:

class LinkedInService(SocialMediaService):
    async def post(self, content, media=None):
        return await asyncio.to_thread(self._sync_post, content, media)
Enter fullscreen mode Exit fullscreen mode

4. Credentials — externalize

Have each service load config from env vars or a single credentials.json, not hardcoded. Makes testing with dummy credentials easy too.

Good luck with the unified dashboard — this architecture makes multi-platform selection almost trivial.

-- Karsten / Pannous

Collapse
 
bharath_kumar_30_vog profile image
Bharath Kumar_30

Thank you so much for the detailed feedback! This is really helpful. I’m still learning and moving from basic structure to a more scalable architecture, so your suggestions on using an abstract base class and making everything async make a lot of sense. I’ll definitely try to refactor my services and manager based on this approach. Also, thanks for pointing out the credentials handling — I’ll improve that as well.😃