DEV Community: Anthony Nwaizuzu

🚀 Cube: The Automation Platform That Actually Gets Developers

Anthony Nwaizuzu — Mon, 23 Mar 2026 10:12:23 +0000

The Automation Nightmare We All Live Through 🌙

It's 2 AM. Sarah, your lead developer, is staring at her laptop for the third night this week. The customer onboarding script she wrote 6 months ago just broke because Stripe updated their API. Again.

Meanwhile, in the marketing department, Tom is trying to set up a simple "welcome email sequence" in Zapier. He hits a wall - he needs to check if the user's subscription tier matches their company size. Zapier can't handle that logic. He opens a ticket to engineering. The backlog is now 3 weeks long.

Sound familiar? This is the automation trap that every team falls into:

The Developer Trap: You write custom scripts. They work great. Until they don't. APIs change, dependencies break, the original developer leaves, and suddenly your business-critical automation becomes a ticking time bomb.

The No-Code Trap: You start with Zapier/Make.com because it's "easy." But the moment you need real logic, custom integrations, or proper error handling, you're back to begging developers for help.

The Enterprise Trap: You spend $50,000+ on an "enterprise solution" that requires a dedicated team, 6-month implementation cycles, and more meetings than actual automation.

We've all been there. The frustration is real. The wasted hours are real. The broken business processes are very, very real.

Let's Be Honest About Automation Tools 😅

You know the drill. You try to automate something and end up with:

Option A: Zapier/Make.com

"Great! I can connect Gmail to Slack!"
5 minutes later: "Wait, I need custom logic. Time to beg a developer for help..."
Result: Back to square one, but with a subscription bill

Option B: Write Custom Code

Developer spends 3 days building a Python script
Works perfectly for 6 months
API changes, script breaks, developer left the company
Result: Business-critical automation is dead

Option C: Enterprise "Solution"

6-month implementation cycle
Dedicated team required
Costs more than your entire marketing budget
Result: Nobody wants to use it

What If Automation Was Actually... Nice? ✨

Cube is different. We built it for developers who are tired of the automation BS.

🎯 For Developers, By Developers

Instead of fighting with limited UI builders or writing endless boilerplate code, Cube gives you visual workflows that just work. No more 200-line error handling functions or retry logic nightmares.

🔧 The Developer Dream Stack

Cube gives you what you actually want:

HTTP Requests That Don't Suck

✅ Built-in retry logic (no more try/catch hell)
✅ SSRF protection (security team will love you)
✅ Template variables (use data from previous steps)
✅ Multiple auth methods (Bearer, Basic, custom headers)

Webhooks That Actually Work

✅ HMAC signature validation (enterprise-grade security)
✅ Rate limiting built-in
✅ Automatic logging and monitoring
✅ No more "why isn't this firing?" debugging sessions

Flow Control That Makes Sense

Remember those nested if/else statements that gave you headaches? Cube turns complex logic into simple visual nodes that anyone can understand.

🚀 Real Power, Zero Boilerplate

Cube handles all the stuff you hate writing:

Error Handling & Retries

Remember spending hours writing retry logic with exponential backoff? Cube handles all of that automatically. Just set the retry count and walk away.

Scheduled Tasks Without Cron Headaches

Tired of managing crontabs and hoping they don't conflict? Cube gives you visual scheduling that just works.

Monitoring That Actually Helps

✅ See exactly which step failed
✅ Input/output data for each node
✅ Execution time tracking
✅ One-click replay of failed executions

The Cube Difference: Developer-Focused vs. App-Focused 🎭

Feature	Zapier/Make	Custom Scripts	Cube
Custom Logic	❌ Very limited	❌ Manual work	✅ Visual + Code
API Integration	❌ Pre-built only	✅ Everything	✅ Everything + Easy
Error Handling	❌ Basic	❌ Manual work	✅ Built-in
Monitoring	❌ Basic logs	✅ DIY only	✅ Built-in
Setup Time	✅ Minutes	❌ Days/Weeks	✅ Seconds

Real Scenarios Where Cube Shines 🌟

Scenario 1: E-commerce Order Processing

Before Cube:
300+ lines of Python code, error handling for 5 different APIs, database connections, email templates, Slack notifications, retry logic, logging, monitoring setup, deployment scripts... you get the idea.

With Cube:

Add webhook trigger (Shopify)
Add HTTP request (inventory API)
Add email node (customer confirmation)
Add Slack node (team notification)
Add condition node (if order > $100, tag as VIP)
Deploy

Time saved: 2 weeks → 30 minutes

Scenario 2: User Onboarding Pipeline

Before Cube:

Multiple Lambda functions
Step Functions for orchestration
CloudWatch for logging
SNS for notifications
$200+ monthly AWS bill

With Cube:

Visual workflow
Built-in monitoring
Self-hosted (your infrastructure)
$0 additional cost

Scenario 3: API Integration Hell

Before Cube:
"Just need to call this API..." 3 hours later you've implemented OAuth 2.0 flow, token refresh logic, rate limiting, error parsing, retry logic, logging, tests, and documentation.

With Cube:

Add HTTP Request node
Set auth type to "Bearer Token"
Paste token
Done

The Bottom Line: Stop Wasting Time on Boilerplate ⏰

Every hour you spend writing:

Error handling code
Retry logic
Logging infrastructure
Monitoring dashboards
Authentication wrappers
API integration boilerplate

Is an hour you're NOT spending on:

Features your users actually want
Performance improvements
Security enhancements
Code that makes your product better

Cube eliminates the boring stuff so you can focus on the important stuff.

Ready to Actually Enjoy Automation Again? 🚀

Get started in 5 minutes:

🎯 Sign In/Sign Up and Build your first workflow with Cube
🎉 Wonder why you ever did it any other way

The result: You'll build automations 10x faster, with better error handling, monitoring, and security than you'd ever implement yourself.

🎯 TL;DR

Problem: Most automation tools are either too limited (Zapier) or too much work (custom code)
Cube solution: Visual workflow builder + developer power + built-in best practices
Result: Build complex automations in minutes, not weeks
Bonus: You get all the enterprise features without the enterprise price tag

Stop fighting with automation tools. Start building things that matter. 🎉

P.S. Cube is currently in MVP and we'd love your feedback! What features would you like to see? Let us know and help shape the future of automation.

How i spent my Christmas break!!

Anthony Nwaizuzu — Thu, 08 Jan 2026 02:14:50 +0000

Anthony Nwaizuzu

Jan 8

If Swagger Works but Your SDK Fails, Your SDK Is Lying

#fastapi #python #sdk #database

Comments 2

2 min read

If Swagger Works but Your SDK Fails, Your SDK Is Lying

Anthony Nwaizuzu — Thu, 08 Jan 2026 02:11:38 +0000

I spent hours debugging my backend, my database, and my auth logic — only to discover none of them were broken.

The Setup

I was building a feature flag / runtime config service.(just a fun thing to do during the holidays)

The idea was simple:

Backend exposes config values per environment
SDK fetches them at runtime
Same token, same environment, same key

Swagger UI worked perfectly.

The SDK?

ConfigNotFoundError: config not found in environment 'development'

Step 1: Trust Swagger First

Swagger wasn’t lying.

It showed:

The request
The headers
The resolved environment
The correct response

Mistake #1: The SDK Route Didn’t Match the API

If you're not careful you can literally spend days trying to figure out what the issue is and meanwhile all you had to do is make sure both routes are the same

The backend exposed this route:

GET /api/v1/sdk/configs/{key}

But my SDK was building URLs like this:

/api/v1/config/{key}

The annoying part is when it happens, it comes with No expection, No warning, just a clean 404

Lesson
Your SDK must match your backend routes character for character.

Mistake #2: Key Normalization Was Inconsistent

This part sounds ordinary, right?......just make sure you don't forget about it. If it requires you setting a reminder to do it, please do because i don't think you will want to shed invisible tears...lol

Configs were stored as:
FEATURE_CHECKOUT_ENABLED

But SDK users could pass:
"feature_checkout_enabled" "Feature_Checkout_Enabled "
That caused:

Cache misses
False “not found” errors
Inconsistent results

Used:

Before API calls
Before caching
Before comparisons Normalize input once — and enforce it everywhere.

What This Experience Taught Me

Swagger is your contract
SDKs lie by omission
Route mismatches are silent killers
Normalization prevents phantom bugs
If Swagger works, your backend is innocent

The Rule I Follow Now

Swagger first. SDK second. Database last.

Every time!!!

Hello Guys, Check out my latest article after a long time away

Anthony Nwaizuzu — Sun, 28 Dec 2025 16:41:12 +0000

Anthony Nwaizuzu

Dec 28 '25

That Dreaded Alembic NotNullViolation Error (and How to Survive It)

#psqlalchemy #alembic #postgres #database

Comments 1

2 min read

That Dreaded Alembic NotNullViolation Error (and How to Survive It)

Anthony Nwaizuzu — Sun, 28 Dec 2025 16:40:16 +0000

What Happened?

Imagine you have a table called organizations full of precious data. You decide:

Hey, let’s add a new column called plan!

Sounds harmless, right? Wrong. You add it as NOT NULL, meaning every row must have a value. But wait… your table is already filled with rows. PostgreSQL looks at them and says:

Why It’s Not Your Fault

This isn’t a bug in Alembic or SQLAlchemy. It’s PostgreSQL protecting your precious data. Adding a NOT NULL column to existing data without a default is basically like asking someone to fill out a survey you didn’t give them in advance. They don’t know what to answer, so they freak out.

How to Fix It

You’ve got a few ways to make PostgreSQL happy again:

Option 1: Give it a Default

op.add_column(
    'organizations', 
    sa.Column('plan', sa.String(), nullable=False, server_default='free')
)

Existing rows get a value ('free') automatically.
After the migration, you can remove the default if you like.
Quick, painless, and everyone’s happy.

Option 2: Three-Step Dance

Add the column as nullable:

op.add_column(
    'organizations', 
    sa.Column('plan', sa.String(), nullable=True)
)

Update existing rows:

UPDATE organizations SET plan = 'free' WHERE plan IS NULL;

Make it NOT NULL:

op.alter_column('organizations', 'plan', nullable=False)

More steps, but more control.
Good if you need custom logic per row.

Option 3: Pre-Migration Prep

Before Alembic touches anything, manually update the table:

Then run your migration.
Old rows are ready, and PostgreSQL doesn’t throw a tantrum.

Moral of the Story

Adding a NOT NULL column to a table with existing rows is like adding a new rule to a crowded party: someone will get upset if you don’t provide a plan. Always think about existing data. Give PostgreSQL a default, update the old rows, or do both.

And remember: Alembic errors might look scary, but they’re really just your database’s way of saying:
“Hey, I love your data too much to let it break. Let’s do this right.”

How to set-up a CI/CD environment on Gitlab using NodeJs

Anthony Nwaizuzu — Wed, 06 Feb 2019 01:16:18 +0000

So I decided to start my first article on dev.to by discussing how to set-up Continuous Integration (CI) and Continuous Delivery (CD), feedback is welcome it helps!

Continuous Integration (CI) is a practice that requires developers to integrate code into a shared repository several times. Each check-in is then verified by an automated build, allowing teams to detect problems to fix early.

Continuous Delivery (CD) is a software engineering approach in which continuous integration, automated testing, and automated deployment capabilities allow software to be developed and deployed with minimal human intervention.

Having a proper CI/CD environment will enable bugs to be caught earlier and developers can review code faster and fix it.

By the end of this article, you will have the basic understanding on how to set up a CI/CD environment on Gitlab.

Step 1: Create a Project on Gitlab

Gitlab is a web-based Git-repository manager, where code can be hosted. Sign up for an account if you do not have one, or log into your existing account if you already have an account. Create a repository, you can name it anything you like, you can also choose to either make the repository public or private. A public repository is accessible to the public through search or direct access using the project’s URL, conversely, a private repository is only accessible to members invited to the repository by the Owner or Maintainer.

Step 2: Setting up your CI environment

To setup a CI environment, you will need to create a file named .gitlab-ci.yml and it should be in the root of your repository.

This file contains a steps by step description on how your project will be built. The Gitlab runner will search for this file in your repository and execute it. GitLab CI looks for this particular file within your repository to determine how it should test the code.

You can create this file through your already created Gitlab project or via your terminal. I will be using terminal in this tutorial. I love my bash commands😏😏

Open your terminal and move to the directory where the project file is located then create a file named .gitlab-ci.yml by doing this:-

$ touch .gitlab-ci.yml

Next we have to edit the .gitlab-ci.yml file so we can create our CI configuration by doing this:-

$ nano .gitlab-ci.yml

The CI configuration will look like this and should be inside your .gitlab-ci.yml file:-

    image: node:latest

    stages:
      - build
      - test

    cache:
      paths:
        - node_modules/

    install_dependencies:
      stage: build
      script:
        - npm install
      artifacts:
        paths:
          - node_modules/

    testing_testing:
      stage: test
      script: npm test

Let’s understand what the above snippet is all about

The configuration file starts by declaring a docker image that allows you to specify a certain version of NodeJS you want to use during build time.

    image: node:latest

Next, we define the different continuous integration process it will run.

    stages:
      - build
      - test

Now we’ve defined the stages, the configuration includes a cache that specifies files that should be saved for later to be used between runs or stages.

    cache:
      paths:
        - node_modules/

Next is install_dependencies, in the process of demonstrating the interaction between stages, we are extracting this step to run its own stage. Typically, running npm install can be combined with the next testing stages.

    install_dependencies:
      stage: build
      script:
        - npm install
      artifacts:
        paths:
          - node_modules/

Lastly, testing_testing declares the command that will run the test suit, Since this is the last stage, it will access what is been produced by the build stage, which are the project dependencies in our case.

    testing_testing:
      stage: test
      script: npm test

Oh yea, testing_testing is just a name I used, you can name it anything you want.

Step 3: Installing Gitlab Runner

Since our repository includes a .gitlab-ci.yml file, any new commits will trigger a new CI run. If no runners are available, the CI run will be set to "pending".

As mentioned, in GitLab, Runners run the jobs that you define in .gitlab-ci.yml. I will be following the instructions here.

Step 4: Register the Gitlab Runner

Next, register the Gitlab Runner by following instructions here.
Running the runner executor on shell is the easiest to setup, so after registration, install and start the service with this commands:

$ gitlab-runner install $ gitlab-runner start

To be sure your runner is running run this command:

$ gitlab-runner status

If you see this: gitlab-runner: Service is running! and the green tick on the project you created on gitlab

Conclusion

Hopefully this article has widen the borders of Gitlab CI/CD and enriched your understanding and like I said earlier feedback is welcome and just in case I missed something kindly notify me.