Some people should understand this, fr😭

@devwitheyob
#TechVibe #Gumball

I literally forgot how fun it was watching Cartoon Network growing up.

I'm watching Gumball, and it's fire. I feel like we're the last generation that truly got to experience growing up with cartoons like this before this TikTok era. 😊

@devwitheyob
#TechVibe #nostalgia #cartoon

I think tenant isolation should be enforced in both the application and the database.

The application handles business logic and permissions, but the database should be the last line of defense. If a developer forgets a tenant_id filter or introduces a bug, RLS(Row Level Security) still prevents data from another tenant from being returned. Also every developer has to remember to put that where filter and that is risky

The performance cost of RLS is usually minimal with proper indexing, and the extra security is worth it. Most production SaaS systems use this, application-level authorization + database-level RLS. It's much safer than relying on the application alone.

@devwitheyob
#TechVibe #MultiTenant #databases #Security

Article of the day

Docker layer caching

One of Docker's biggest performance optimizations is layer caching.

Every instruction in a Dockerfile (FROM, COPY, RUN, etc.) creates a new image layer. When you build the image again, Docker doesn't blindly execute every instruction, it checks whether it can reuse previously built layers.

For example, consider this Dockerfile:

FROM node:22

WORKDIR /app

COPY package*.json ./

RUN npm install

COPY . .

CMD ["npm", "start"]

On the first build, Docker executes every instruction. But if you only change server.js and rebuild, Docker reuses all the cached layers up to RUN npm install and only rebuilds the final COPY . . layer. This means your dependencies aren't installed again, making the build significantly faster.

However, if you modify package.json, Docker must rebuild the COPY package*.json layer, the RUN npm install layer, and every layer after them. A change to one layer invalidates that layer and all subsequent layers.

This is why Dockerfile order matters. Place instructions that change rarely (like installing dependencies) near the top, and instructions that change frequently (like copying your application source code) near the bottom. A well-structured Dockerfile can reduce build times from minutes to just a few seconds during development.

Read Full article 👉 [ LINK ]

@devwitheyob
#TechVibe #ArticleOfTheDay #Docker #Caching #DevOps

Who is gonna be my last guest😁

Let's go to 2k🔥

@devwitheyob
#TechVibe #subs

Start reading the terms and conditions when u signing up, guys😁

@devwitheyob
#TechVibe #random

When you're trying to impress with your tech, but it failed😁

@devwitheyob
#TechVibe #random

Article of the day

Advanced git

Before pushing to main, make it a habit to sync your branch with the latest changes by rebasing on top of main. This helps you resolve conflicts early and keeps your commit history clean. If your branch has a lot of small "fix" or "oops" commits, use an interactive rebase to squash them into a few meaningful commits. A clean history makes reviewing code and debugging much easier later.

Before every push, review your changes with git diff and scan for anything that shouldn't be in the repository, such as API keys, tokens, passwords, or temporary debugging code. Then run your tests locally to make sure nothing is broken. Catching an issue before it reaches the remote repository is always easier than fixing it after deployment.

If you've rebased your branch, avoid using git push --force. Instead, use git push --force-with-lease, which checks whether someone else has updated the remote branch before overwriting it. Finally, tag important releases with versions like v1.0.0 or v2.1.0. Release tags make it easy to identify deployments, track changes between versions, and roll back quickly if something goes wrong in production.

read more advanced git concepts 👉 [ LINK ]

@devwitheyob
#TechVibe #git #ArticleOfTheDay

Git in CI

CI runners clone your repo on every job. For a 200 MB monorepo with 50k commits and 10k refs, a naive git clone burns 30-60 seconds per job before any test runs. Across a 40-job pipeline that is 30 minutes of pure clone wait per pull request. The fix is not "throw a faster runner at it", it is matching the clone strategy to what each job actually needs.

Shallow clone is the lazy fix. It downloads only the most recent commits, skipping history.

git clone --depth=1 https://github.com/org/repo.git

read more advanced git concepts 👉 [ LINK ]

@devwitheyob
#TechVibe

Git in CI

While shallow clones (depth=1) are fast, they break commands that rely on Git history like git log, git blame, git merge-base, changelog generators, and release tools.

A better option is a partial clone, which downloads the commit history but only fetches file contents when they're actually needed. This keeps history available while making clones much faster and smaller.

# Download history, fetch file contents on demand
git clone --filter=blob:none https://github.com/org/repo.git

# Skip blobs larger than 1 MB
git clone --filter=blob:limit=1m https://github.com/org/repo.git

For medium and large repos, especially monorepos, partial clones can significantly reduce clone time and disk usage without losing access to Git history.

read more advanced git concepts 👉 [ LINK ]

@devwitheyob
#TechVibe #git #GitInCI

Prompt of the day

"Build Windows 12 and make no mistake"

LOL😁

@devwitheyob
#TechVibe #random