DEV Community: Md Kaif Ansari

How I Replaced Axios With `fetch` Without Breaking the App

Md Kaif Ansari — Thu, 02 Apr 2026 10:42:11 +0000

This migration did not happen because I woke up one day and decided to become a minimalist monk of HTTP clients.

It happened because of the Axios compromise story.

According to the Fireship video summary that pushed me to take this seriously, attackers allegedly compromised the project maintainer's npm account and published malicious Axios versions. Those versions reportedly pulled in a rogue dependency called plain-crypto-js, which is exactly the sort of package name that sounds fake even before it ruins your week.

From the summary, the malicious package used a post-install script as a RAT dropper. It would detect the OS, download a second-stage payload from a command-and-control server, establish remote access, and then clean up after itself to avoid leaving obvious evidence in security audits.

That is an insane sentence to write about a package manager.

So yes, this migration started because of a security concern, but also because npm packages have been losing trust lately in a very "are we serious right now?" kind of way.

So I removed it.

Not in a dramatic, "delete it and pray" kind of way. More in a calm, boring, production-safe kind of way. Which, honestly, is the better kind of dramatic.

Also, sorry Fireship for using your YouTube thumbnail.

Why I Did This Now

The security angle was the whole reason this moved from "nice cleanup idea" to "do it now."

Based on that Fireship summary, the practical advice was:

check package.json for the affected Axios versions
check node_modules for plain-crypto-js
if compromised, do not just delete the file and move on
roll API keys and tokens immediately
follow proper incident cleanup guidance, like the kind Step Security documents

That last part is important. If a machine is compromised, deleting one sketchy package is not a victory lap. That is just the beginning of a worse conversation.

In my case, the safest and cleanest move for the project was simple: remove Axios entirely and replace it with something tiny that I control.

The Goal

I did not want a huge rewrite.

I did not want to touch every API call in the app.

And I definitely did not want to replace Axios with "just raw fetch" and then spend the next two days fixing things that Axios had been quietly doing for me all along.

So the real goal was simple:

Replace Axios with a small internal client built on top of fetch, while keeping the same developer experience for the app.

The Important Realization

A lot of people say, "Why not just use fetch? It already returns promises."

That part is true.

But Axios was doing a few useful things for us:

It handled a base URL
It serialized JSON requests nicely
It rejected on failed responses
It let us return response.data directly
It gave us a clean place to normalize errors

fetch gives you the raw ingredients. Axios gives you the sandwich.

So instead of rebuilding all of Axios, I only rebuilt the tiny slice of it that this project actually used.

That was the key decision.

Step 1: Audit What the App Was Really Using

Before changing anything, I checked how axios was being used across the project.

The result was better than I expected: all usage was already going through one wrapper file.

That meant I didn’t have to go on a treasure hunt through 47 random components yelling "who imported axios directly?"

The app mostly relied on:

api.get(...)
api.post(...)
api.patch(...)
api.delete(...)

And the wrapper was already doing two important things:

unwrapping the API response envelope
converting server errors into a custom ApiClientError

That made the migration way easier, because I didn’t need Axios compatibility. I just needed behavior compatibility.

Big difference.

Step 2: Keep the Same API Surface

Instead of changing the whole app, I created a small internal client with the same shape:

api.get(...)
api.post(...)
api.patch(...)
api.put(...)
api.delete(...)
api.request(...)

Everything still returns promises.

So the rest of the code didn’t need to change its mental model at all.

React Query still works the same.
Mutations still work the same.
Error handling still works the same.

The app basically says, "cool story," and keeps moving.

Step 3: Build a Thin `fetch` Wrapper

The core implementation lives in lib/api-client.ts.

That file handles the boring but important stuff:

joining baseURL with request paths
adding query params
merging headers
automatically JSON-stringifying request bodies
calling fetch
parsing JSON responses
rejecting on non-2xx responses
converting API errors into ApiClientError

This is the kind of code nobody posts on social media, but it’s exactly the kind of code that saves you from pain later.

Which is basically backend romance.

Step 4: Preserve Existing Error Behavior

This part mattered a lot.

The app already expected a custom error class with:

message
code
status

That’s how some UI states worked, especially for share pages with cases like:

revoked link
expired link
not found

If I had changed the error shape, the UI would not have exploded loudly. It would have broken politely, which is honestly worse.

So I kept the exact same error contract.

That way the UI could keep doing:

if (apiError?.code === "EXPIRED") { ... }

No changes needed.

No "small follow-up fix" at 1:30 AM.

Step 5: Leave Upload Progress Alone

One thing I did not touch was the upload flow that uses XMLHttpRequest.

Why?

Because file upload progress with browser fetch is still not as straightforward as people wish it were. And this project already had working upload progress with XHR.

So I kept it.

Not everything needs to be rewritten just because we are already in the file pretending to be productive.

Sometimes the best engineering choice is to leave the working part alone.

Step 6: Migrate Imports, Then Remove Axios

Once the new client was ready, I updated imports from the old Axios wrapper to the new internal client.

After that, I removed axios from package.json and refreshed the lockfile.

That order matters.

You don’t pull the ladder away before checking whether you’re still on the roof.

Step 7: Validate Like a Responsible Adult

After the migration, I ran:

tests
TypeScript
a production build

That last one is especially important. A migration is not done when the code "looks right." It’s done when the app actually builds and behaves correctly.

There was one unrelated build issue caused by sandboxed Google Fonts fetching, but once that was allowed, the production build passed cleanly.

So the migration wasn’t just theoretically correct. It was actually verified.

A rare and beautiful moment in software.

What I Ended Up With

Now the app has:

no direct Axios dependency
a small internal HTTP client
the same promise-based developer experience
the same API error handling behavior
no large-scale call site rewrite

Which is exactly what I wanted.

This is one of those migrations that sounds dramatic when you describe it out loud:

"I replaced Axios with a custom fetch client."

But in practice, the best version of this job is the boring version.

No broken flows.
No weird regressions.
No emergency patch.
No Slack message that starts with "quick question."

npm Trust Is Weird Right Now

The funniest and least funny part of modern JavaScript is that half the ecosystem is brilliant, and the other half feels like we are all three typo packages away from a cybersecurity documentary.

I still love JS and TS. I really do.

In fact, JavaScript and TypeScript played a huge part in making one of my biggest dreams come true: buying a MacBook as a teenager.

That still means something to me.

So this is not me doing the dramatic "JavaScript is dead" speech from the back of the conference room.

But it is me saying I have a very keen plan to move more critical parts of my stack to Go or Rust sooner rather than later.

Not because JS/TS failed me.

More because the supply-chain circus around npm keeps reminding me that reducing unnecessary dependencies is just good survival instinct now.

Final Thought

I didn’t replace Axios because fetch is cooler.

I replaced it because the dependency no longer made sense for this project, and the app only needed a very small subset of what Axios was providing.

So instead of dragging around a whole library, I kept the useful behavior, dropped the unnecessary dependency, and made the system simpler.

Which, in my opinion, is the nicest kind of refactor:
less code, fewer dependencies, same behavior, zero chaos.

That’s the dream.

And if one small migration also means one less reason to trust a random install script with my machine, even better.

Multitasking, A NIGHTMARE !

Md Kaif Ansari — Fri, 13 Mar 2026 23:51:07 +0000

Every person/developer muti-task in day to day life, to get huge promotion, to complete all the task in limited time, to work on something new or follow up with pending task in while working on on their primary work, and at age of AI it quite easy for anyone to do so.

A NIGHTMARE ?

So I'm super good at muti-tasking and also enjoy doing so, as small amount of time, with huge dopamine HITS, every task and a intention behind it, and for dev it ended up been getting insentives for it, if they are working for unpaid work, they might need appreciation or global recognition for their work !

As a student I felt the same so I started working on multiple things to showcase on my portfolio and flex in public.
But the problem started when I felt into the Mutitask HELL, where we do a lot of work, ended up spending a lot time into something that made sense to me.

But after doing some analyzation of that time, was nothing but shallow work of 100 of project that nobody cares.

What I feel I'm doing and What I ended up doing

I felt like I've touched 5 repos today, managed my social media profiles, watched some learning content in YT and ended my with a lot of dopamine hits.

Reality: I touched 5 repos but only solved some UI bugs and design changes, Yes I managed by social media but was just commenting on other's post and doom scrolling, and some low dopamine hunt. Yes I watched YT content but some short vid, but short content, didn't learned something which was game chnager, nor something which would actully matterns. And called it DAY !

If we think more about the tasks/commits we are making entire day, it was just waste of precious time.

The reason why mutitasking become the nightmare !

The solution

If you recognize that you are stuked into muti-tasking HELL and it's becoming fruitful, then it's mattern of concern!

But the good thing about this is you know it's not working for you.
So just transform the way you work everyday.

The real changes that WORKS !

Changes that worked for me, and helped me becoming the better version of myself, the top contributor in one of the open source organization ,building my own component library and doing gihub farming.

Paperflow:

Github:

Proof:
And merged more the 50 prs in an open source org

I'll not just write the entire book of actionable items with story, rather some bulletpoint that actually works

Maintain a set of todos before starting the day, follow up with the updates you have done so far, and things which are rest, priotise items based on your priority. (You can use any platform that works well for you, and you are comforble using it, I used notion and it worked super well for me)
Try doing one task at a time, and diving deeper into it, once you master the art of deep work and increment task accordingly. (Research proves building focus on a task after small distraction takes 25 mins)
Isolate yourself in a room, notification OFF and phone somewhere hidden from your eyes
Try to complete the entire todo in the day, which you planned with some focus deep session.

NOTE: make sure you have feasible todos, not like completing the entire syllabus today, or building the entire SAAS product in one go, which is not feasible.

CAUSION: I'm not an intellectual nor someone from FAANG, I'm just a undergrad student, who build incredible product and try to accomplish as much as I could in my age. So these are just my bare thoughts.

If you like the article, drop a comment and stay conncted some cool article are in my todos,

Till then PEASE !

Why Owasp BLT ? Contribution from 5 to 50+ prs !

Md Kaif Ansari — Sat, 07 Mar 2026 16:40:02 +0000

It was the time when I thought to get some open source contribution after I was done from my internship. I was heavily into TS/JS ecosystem and started finding projects for the same.

So I went to gsocorganizations.dev to find some organization, then I just applied the filter for web and started scrolling. Most of the orgs were either too big to get started or had zero activity; you know the type, last commit 8 months ago, issues with no responses.

Then I saw OWASP BLT.

Honestly my first reaction was, what even is this? A bug logging tool with BACON tokens and a leaderboard? Sounded like someone mixed a bug bounty platform with a gamified Reddit. I was skeptical. But the repo had recent commits, open issues with responses, and the maintainer (Donnie) was actually replying to people. That was enough for me to at least clone it.

The First PR — Small But It Counts

I spent the first few days just reading the codebase. BLT runs Django on the backend, has a Cloudflare Workers API layer called BLT-API, a Chrome extension, a Flutter app, and about 30+ other sub-repos. It's not a small project.

My first PR was tiny. A small bug fix; nothing fancy. I wasn't even sure it would get noticed. But it got reviewed, commented on, and merged within a couple days. That was the moment I thought okay, this is actually active, people are paying attention here.

That one merged PR basically hooked me in.

Going Deeper — BLT-API and the D1 Migration

After a few more small PRs I started digging into BLT-API; the Cloudflare Workers layer. This is where things got interesting and also where I spent most of my time.

The project was in the middle of migrating from a traditional database setup to Cloudflare D1 (basically SQLite at the edge). Nobody had fully done it yet. I looked at the codebase, figured out what was missing, and just started doing it.

The D1 migration ended up being a bigger chunk of work than I expected — schema design, migration files, bugs API, user schema, 2FA auth with Mailgun, domain routing. At some point I realized I had context on this entire layer that very few other contributors had.

That's kind of how it happens with open source. You don't plan to become the person who knows X. You just keep pulling threads until suddenly you're the one explaining it to others.

Talking to Donnie

One thing that kept me going was that Donnie was actually there. Not just merging PRs silently — actually talking, discussing direction, pushing back when something didn't make sense.

I remember one conversation where I brought up whether we should migrate to wrangler@latest and clean up some of the utility functions. I laid out both sides; old version is stable and working, new version is cleaner for contributors but we might break things. He just said "I like this improvement" and we went from there.

That kind of back and forth made it feel less like contributing to a repo and more like actually building something with someone. That changes how you approach the work.

5 PRs to 50+

Looking back at how it went from 5 to 50+ PRs; it wasn't a strategy. I didn't sit down and think "I'm going to contribute a lot." It was more like every time I fixed something I found two more things that needed fixing. And every time I went deep on one layer I found connections to other layers I wanted to understand.

BLT is genuinely a weird project in the best way. It has a bug bounty platform, blockchain rewards, a PR readiness checker, an AI code review bot, a Slack bot, a web scanner agent; all as separate repos that loosely connect. Once you start understanding how it fits together it's hard to stop.

By the time I had 50+ PRs merged across 10+ repos I realized I wasn't just a contributor anymore, I actually understood the system. Not just one part of it, the whole thing.

That's when I started thinking about GSoC.

Why BLT Specifically

There are bigger projects. More popular ones. Ones with better documentation and easier onboarding.

But BLT had something most of them didn't; room to actually build things. Not just fix typos or update dependencies, but design and implement real features. The kind of work where you're making decisions that actually affect how the platform works.

If you're looking for an open source project to contribute to and you want to go from zero to genuinely understanding a real production system; BLT is worth the initial confusion. Push through the first few PRs, get into the codebase, find the thing that interests you and go deep on it.

The BACON tokens are optional. The learning isn't.

Built a LinkedIn Automation Tool and Survived 206 Commits Later 🫠

Md Kaif Ansari — Fri, 12 Sep 2025 11:16:57 +0000

yo devs! 👋

so we just launched our first product (post0 - a LinkedIn automation tool) and honestly, the technical journey has been absolutely WILD. thought i'd share how we went from "let's just build a simple app" to accidentally creating a distributed nightmare that somehow actually works now lol

the "simple" beginning

started with what every student does - a good old monolith. one repo, one deployment, one massive headache waiting to happen. we were young, naive, and thought "microservices are just corporate overengineering" 🤡

post0-app/
├── frontend/
├── backend/
├── workers/
└── database/

seemed simple enough right? WRONG.

when everything went to sh*t

about 3 months in, our CI/CD started taking 20+ minutes. deployments were breaking constantly. one bug in the posting logic would take down the entire frontend. classic monolith problems hitting us like a truck.

the breaking point was when i pushed a "small fix" to the posting service and accidentally broke user authentication for 2 hours 💀

the great migration (aka going full microservices)

said f*ck it and decided to split everything up:

current architecture:

posting-service (24 commits) - handles all the LinkedIn API magic
notification-service (7 commits) - push notifications and email stuff
frontend (162 commits) - next.js app that looks decent
prisma-service (13 commits) - shared database schemas

event-driven with pub-sub model:

// when user schedules a post
await pubsub.publish('post.scheduled', {
  userId,
  postContent,
  scheduledTime,
  platform: 'linkedin'
});

// posting service picks it up
pubsub.subscribe('post.scheduled', async (data) => {
  await scheduleLinkedInPost(data);
  await pubsub.publish('post.status.updated', { ... });
});

the pain points (aka where we cried)

prisma schema syncing nightmare

sharing prisma schemas across services is... interesting. we tried:

git submodules (hell no)
npm packages (version hell)
monorepo (back where we started?)

ended up with a separate prisma-service repo that publishes schema updates. not perfect but works.

vercel + github orgs = 💸

vercel doesn't deploy org repos on free tier. had to setup github actions to build and deploy:

name: Deploy Frontend
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Deploy to Vercel
        uses: amondnet/vercel-action@v20
        with:
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.ORG_ID }}

azure deployment chaos

deploying 4 separate services to azure container instances while maintaining secrets, environment variables, and not going broke as students = pure chaos

what we learned (the hard way)

start simple, split when it hurts - monolith wasn't wrong initially, we just grew out of it
event-driven architecture is beautiful but debugging async flows at 3am is not
shared schemas are hard - there's no perfect solution, pick your poison
free tiers have limits but github actions + some creativity goes far
commit often - 162 commits in frontend repo saved our ass multiple times

current status: somehow working ✨

all services deployed on azure
frontend on vercel (through our CI/CD hack)
pub-sub events flowing smoothly
users actually scheduling LinkedIn posts without everything exploding

the real talk

was it overengineered for a student project? probably.
did we learn a ton about distributed systems, event-driven architecture, and deployment hell? absolutely.
would we do it again? honestly... yeah, but with better planning 😅

if you're building something similar, my advice: start with the monolith, split when you feel the pain, and don't be afraid to make mistakes. that's literally how you learn this stuff.

anyway, we're live on product hunt today if you want to check out what came out of this beautiful disaster: [link]

what's your biggest architecture fail? drop it in the comments, let's suffer together 🫡

tech stack for the curious:

next.js + typescript (frontend)
node.js + express (services)
prisma + postgresql
azure pub/sub + container instances
github actions (CI/CD)
vercel (frontend hosting)

Post0

ps: if you're also a student dealing with deployment nightmares, my dms are open. let's cry together 😭

Nodedash: A Simple and Scalable Node.js Backend Template

Md Kaif Ansari — Sat, 22 Feb 2025 14:42:07 +0000

Nodedash: A Simple and Scalable Node.js Backend Template

We love building backend applications in TypeScript with Node.js, leveraging features like rate limiting, fast response times, ESLint support, and a well-structured folder layout.

Why Nodedash?

When it comes to Node.js frameworks, Express and Nest.js are the most popular choices. I've been working with Express for over two years now. However, every time I started a new project, I found myself copying the structure from an old project, cleaning it up, and then beginning development. Over time, this became tedious and inefficient.

That's when I thought—why not create an NPM package or a repository where I can set up a reusable schema and clone it whenever needed? This led to the creation of Nodedash.

Nodedash is a simple and scalable Node.js backend template designed to kickstart your projects. It includes essential configurations and middleware, all written in TypeScript.

Features

Basic Express server setup
Environment variable configuration
Common middleware integration (e.g., compression, CORS, helmet, morgan)
TypeScript support
Jest for testing
Prettier for code formatting
Well-structured folder layout for scalability

Prerequisites

Before getting started, ensure you have:

Node.js v14 or higher
npm installed

Installation

Clone the repository:

git clone https://github.com/mdkaifansari04/NODE_BACKEND_TEMPLATE.git

Navigate to the project directory:

cd NODE_BACKEND_TEMPLATE

Install dependencies:

npm install

Usage

Start the development server:

npm run dev

Start the production server:

npm start

The server will be running at: http://localhost:5000

Running Tests

To run tests:

npm test

To run tests in watch mode:

npm run test:watch

To check test coverage:

npm run test:coverage

Formatting Code

To format the code with Prettier:

npm run format

Project Structure

NODE_BACKEND_TEMPLATE/
├── node_modules/
├── src/
│   ├── api/
│   │   └── v1/
│   │       ├── controllers/
│   │       ├── models/
│   │       └── routes/
│   ├── helpers/
│   ├── middleware/
│   ├── types/
│   ├── validation/
│   └── app.ts
├── .env
├── .gitignore
├── jest.config.js
├── package.json
├── tsconfig.json
├── README.md
└── ... (additional files)

Contributing

I just started this project, and it has a lot of potential to become even more scalable and efficient. Contributions are welcome! Feel free to fork the repository and submit a pull request.

License

This project is licensed under the ISC License.

Github repo
Nodedash

The goal of Nodedash is to create a clean and efficient development environment for Node.js backend projects. Join me in making it better and more developer-friendly!

How to deploy your Typescript backend on Render (Simple steps)

Md Kaif Ansari — Wed, 17 Jul 2024 10:58:18 +0000

Deploying a TypeScript backend on Render can be straightforward if you follow these simple steps. In this guide, I will walk you through the process using a package.json file as an example.

Step 1: Prepare Your `package.json` File

First, ensure your package.json file contains the correct scripts for building and starting your application. Here is an example:

{
  "name": "backend",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "dev": "nodemon",
    "start": "ts-node -r tsconfig-paths/register src/index.ts",
    "build": "tsc",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "axios": "^1.7.2",
    "bcrypt": "^5.1.1",
    "compression": "^1.7.4",
    "cors": "^2.8.5",
    "dotenv": "^16.4.5",
    "express": "^4.19.2",
    "groq-sdk": "^0.5.0",
    "helmet": "^7.1.0",
    "jsonwebtoken": "^9.0.2",
    "mindsdb-js-sdk": "^2.3.0",
    "module-alias": "^2.2.3",
    "mongoose": "^8.4.4",
    "morgan": "^1.10.0",
    "nodemon": "^3.1.4",
    "openai": "^4.52.3",
    "pdf2json": "^3.1.3",
    "prettier": "^3.3.3",
    "ts-node": "^10.9.2"
  },
  "devDependencies": {
    "@types/bcrypt": "^5.0.2",
    "@types/express": "^4.17.21",
    "@types/hapi__joi": "^17.1.14",
    "tsconfig-paths": "^4.2.0",
    "typescript": "^5.5.3"
  },
  "_moduleDirectories": [
    "node_modules_custom"
  ],
  "_moduleAliases": {
    "@src": "./dist"
  }
}

In the scripts section, you need to have:

start: Command to start your server.
build: Command to build your TypeScript code.

Step 2: Run the Necessary Commands

To deploy your backend, you need to execute three commands in the Render build settings:

Install dependencies:

   npm install

Build the project:

   npm run build

Start the server:

   npm run start

Step 3: Deploy on Render

Now, let's move on to deploying your project on Render.

1. Create a New Web Service

Go to Render and log in to your account.
Click on the "New" button and select "Web Service".

2. Connect Your Repository

Select the repository that contains your TypeScript backend project.
Render will automatically detect the root directory of your project.

3. Configure Build and Start Commands

In the build command section, enter npm run build.
In the start command section, enter npm run start.

Here are the configurations:

Build Command
You have to make sure you install and build your backend in Build Command

Start Command
You have to make sure you start your server from the start command not with nodemon as it is the development mode.

Here I have start": "ts-node -r tsconfig-paths/register src/index.ts on my package.json file.

So I used npm run start

Select you Instance type

I am using free version.

Add environment variable if you have any

4. Deploy

Click the "Create Web Service" button.
Render will start the deployment process. You can monitor the logs to see the progress.

Your deployment will start, if you have configured everything right. It will be deployed successfully.

Final Notes

Ensure that your build and start commands in the package.json file are correctly defined to avoid any issues during the deployment.

Following these steps, you can successfully deploy your TypeScript backend on Render.

ContentAce : A Cool AI-Powered Content Generation Platform 🚀

Md Kaif Ansari — Sun, 07 Jul 2024 21:27:53 +0000

Hey everyone! 😎 I’m super excited to share my journey of creating ContentAce, a platform designed to help you generate content ideas, titles, tags, descriptions, and much more! This adventure started with a spark of curiosity and ended with a functional, feature-rich application. Let’s dive into the details and features of ContentAce and my 5-day coding journey! 🛠️

Day 1: Diving into MindsDB 🏊‍♂️

It all started with a day of deep diving into the MindsDB documentation. 📝 I was curious to see what cool things I could build on top of it. After a few hours of exploring, I realized MindsDB could help me create something really useful for content creators.

Day 2: Planning the Masterpiece 🗺️

The second day was all about planning. I sat down with my trusty notebook and sketched out the entire layout and workflow of ContentAce. From the user interface to the backend APIs, everything was meticulously planned. It felt like setting the foundation for a big project, and I was super pumped! 💪

Day 3: Frontend Frenzy 💻

With the plan in place, I started building the frontend using Next.js 14, React Query, Zustand, and Tailwind CSS. The goal was to make a sleek, user-friendly interface. This part was really fun because I love seeing things come to life visually. 🌟

Day 4: Backend Bonanza 🔧

Next, I moved to the backend. I used Node.js, Express, MongoDB, and a bunch of other tools to build the APIs. Setting up the database and ensuring everything worked smoothly was a bit challenging, but hey, that’s part of the fun! By the end of the day, I had a working backend ready to handle requests. 🎉

Day 5: Interaction Integration 🤝

Finally, it was time to connect the frontend with the backend using React Query and Zustand. This part involved a lot of learning and debugging, but it was totally worth it. Seeing the frontend and backend communicate seamlessly felt incredibly satisfying. I wrapped up the project with a big smile on my face! 😁

Features of ContentAce ✨

ContentAce comes packed with a bunch of cool features:

YouTube Content Ideas: Get creative ideas for your YouTube videos.
YouTube Title Generation: Generate catchy and optimized titles.
YouTube Tag Generation: Suggest relevant tags for your videos.
YouTube Description Generator: Write engaging and SEO-friendly descriptions.
Thumbnail Text Generator: Create attractive text for thumbnails.
Video Script Generator: Produce detailed scripts for your videos.
SEO Optimization Tips: Get suggestions to improve your video SEO.
Engagement Tips: Learn best practices for engaging with your audience.
Email Generators: Generate professional emails, cold outreach, follow-ups, and more.
Blog Generators: Generate blog ideas, titles, and content.

Future Plans 🌈

The journey doesn’t stop here! I have big plans for ContentAce:

More Integrations: Integrate with other platforms like Instagram and Twitter.
Enhanced AI Models: Use advanced AI models for better content suggestions.
User Feedback: Implement user feedback features to constantly improve the platform.
Mobile App: Develop a mobile version of ContentAce for content creation on the go.

Installation Guide 🚀

Ready to try out ContentAce? Here’s how you can set it up:

Clone the Repository:

git clone https://github.com/your-username/contentace.git

Navigate to the Frontend Folder:
```
cd contentace/frontend
```

Set Up Environment Variables:
Create a .env file with the following:

NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=
CLERK_SECRET_KEY=
NEXT_PUBLIC_HOST_URL=http://localhost:5000/api/v1
NEXT_PUBLIC_EMAILJS_SERVICE_ID=
NEXT_PUBLIC_EMAILJS_CONTACT_TEMPLATE_ID=
NEXT_PUBLIC_EMAILJS_FEATURE_TEMPLATE_ID=
NEXT_PUBLIC_EMAILJS_PUBLIC_KEY=

Start the Frontend:
```
npm run dev
```
Navigate to the Backend Folder:
```
cd ../backend
```

Set Up Environment Variables:
Create a .env file with the following:

PORT=5000
MONGO_URI=
SECRET_KEY=
GROQ_API_KEY=
MINDSDB_API_KEY=
MINDSDB_BASE_URL=http://127.0.0.1:47334/api/projects/mindsdb/models/contentace/predict

Start the Backend:
```
npm run dev
```

Ensure MindsDB is Running:

# Create and configure your MindsDB model
CREATE MODEL contentace
PREDICT sentiment
USING
engine = 'minds_endpoint_engine',
model_name = 'mistral-7b',
prompt_template = 'You are an AI model that works on system prompt: {{systemPrompt}} and give a descriptive answer to the given question: {{question}}';

And that’s it! You’re all set to explore and use ContentAce! 🌟

Conclusion 🎉

Building ContentAce was an amazing journey filled with learning and excitement. I’m thrilled to share this platform with you all and can’t wait to see how it helps you create awesome content. Stay tuned for more updates and features.

Happy content creating! Feel free to ask any doubt or suggest some features that I can add into it 🚀✌️

Task Unity- Achieve More Together

Md Kaif Ansari — Mon, 17 Jun 2024 21:34:46 +0000

Task Unity: Revolutionizing Task Management and Collaboration

In today's fast-paced world, effective task management and seamless collaboration are key to achieving success in any organization. Introducing Task Unity, a cutting-edge task management tool designed to empower teams with multifunctional admin and user dashboards, fostering transparent communication and maximizing productivity.

Introduction

Managing tasks and collaborating efficiently can be challenging, especially for growing teams. Task Unity aims to address these challenges by providing a comprehensive solution that streamlines task assignments, encourages teamwork, and offers clear insights into task progress and performance. With a robust tech stack and user-friendly interface, Task Unity is set to transform the way teams work together.

Key Objectives

Task Unity is built with the following key objectives in mind:

Efficiency: Streamline task assignments for clarity and effectiveness.
Collaboration: Encourage seamless communication and teamwork.
Transparency: Provide clear insights into task progress and performance.
Productivity: Empower individuals and teams to achieve peak productivity.

Prerequisites

Before diving into Task Unity, ensure you have the following prerequisites installed on your system:

Node.js: Download Node.js
npm (Node Package Manager): Ensure the latest version by running npm install npm@latest -g
MongoDB: Download MongoDB

Core Functionality

Task Unity offers a range of features designed to enhance task management and collaboration:

User Authentication: Secure login using JWT.
Admin Dashboard: View, edit, delete, and add users; assign tasks; chat with users.
User Dashboard: View assigned tasks, mark tasks as completed, chat with admin.
Profile Management: Update user profiles.
Task Management: Detailed task tracking and progress updates.
Communication: Built-in chat feature for seamless communication between admin and users.
Search Functionality: Quickly find tasks and users.
Responsive Design: Accessible on various devices with dark and light mode options.

Installation

Setting up Task Unity is straightforward. Follow these steps:

Clone the repository:

   git clone https://github.com/Mdkaif-123/Task-Unity.git

Navigate to the backend folder and install dependencies:

   cd Task-Unity/backend
   npm install

Navigate to the frontend folder and install dependencies:

   cd ../frontend
   npm install

Set up your backend .env file:

   MONGO_DB_URL="mongodb://127.0.0.1:27017/taskUnityDB"
   AUTH_SECRET_KEY="thisistheauthsecretkeyforauthenticationpurpose"

Set up your frontend .env file:

   REACT_APP_HOST="http://localhost:8000"

Run the backend server:

   cd ../backend
   npm start

Run the frontend server:

   cd ../frontend
   npm start

Technology Stack

Task Unity leverages a powerful technology stack to deliver an exceptional user experience:

Frontend: React, Tailwind CSS, Material Tailwind, Chart.js, Flowbit Components, React Router, Multi Avatar.
Backend: Node.js, Express, MongoDB, JWT.

For more information on these technologies, refer to their documentation:

Future Scope

Task Unity is constantly evolving, with exciting future enhancements planned:

AI Bot Integration: Enhance task management with AI-driven insights and automation.
Email and Notification Features: Stay updated with task progress and important notifications.
Super Admin Functionality: Enable advanced admin controls and website customization.
Courses Platform: Offer training and resources for users to improve their skills.

Conclusion

Task Unity is more than just a task management tool; it's a platform designed to revolutionize how teams collaborate and achieve their goals. By simplifying task management and fostering transparent communication, Task Unity empowers teams to reach new heights of productivity and efficiency. Join us on this journey to redefine teamwork and productivity.

For more details and to get started with Task Unity, visit our GitHub repository and live demo.

Zapher - Hub for Interactive Discussions

Md Kaif Ansari — Sat, 15 Jun 2024 07:41:58 +0000

Introduction

Welcome to Zypher, your gateway to learning and mastering various technologies while contributing to an exciting open-source project! Whether you're new to software development or looking to expand your skills, Zypher offers a robust platform built on modern technologies like Next.js, MongoDB, and Clerk. This blog will serve as your comprehensive guide to getting started with Zypher, providing resources and steps to kickstart your journey effectively.

Getting Started with Zypher

What is Zypher?

Zypher is a dynamic web application designed to foster interactive discussions and community engagement. It leverages Next.js 14 for server-side rendering, MongoDB for data storage, and Clerk for authentication, ensuring a secure and efficient user experience. As you embark on your journey with Zypher, here’s how you can dive in and start contributing:

Prerequisites

Before diving into Zypher, it’s essential to have a basic understanding of web development fundamentals:

HTML/CSS: Familiarity with building web pages and styling elements.
JavaScript (ES6+): Understanding of JavaScript for client-side interactions and asynchronous programming.
Git and GitHub: Basics of version control and collaborative development using Git and GitHub.

If you’re new to these concepts, don’t worry! There are plenty of resources available online to help you get up to speed.

Setting Up Your Development Environment

To start contributing to Zypher, follow these steps to set up your development environment:

Install Node.js and npm: Ensure Node.js is installed on your machine to run JavaScript applications. npm (Node Package Manager) will help manage dependencies.

Node.js Installation Guide

Clone the Zypher Repository: Clone the Zypher repository from GitHub to your local machine using Git.

   git clone https://github.com/your-username/zypher.git
   cd zypher

Install Dependencies: Install project dependencies using npm.

   npm install

Configure Environment Variables: Set up environment variables for Clerk authentication and MongoDB connection strings. Refer to the project’s README or documentation for specific instructions.
Run the Development Server: Start the development server to see Zypher in action locally.

   npm run dev

Explore the Codebase: Take some time to explore the project’s structure, understand how components are organized, and familiarize yourself with the code conventions followed.

Learning Resources

To effectively contribute to Zypher and enhance your skills, here are some valuable resources categorized by the technologies used:
JavaScript (ES6+): Understanding of JavaScript for client-side interactions, asynchronous programming, and familiarity with React for building interactive UI components.
Git and GitHub: Basics of version control and collaborative development using Git and GitHub, essential for managing project versions and contributing to open-source projects.

Next.js:
- Next.js Documentation
- Learn Next.js
MongoDB:
- MongoDB Documentation
- MongoDB University
Clerk:
- Clerk Documentation
- Clerk Quick Start Guide
Upload Thing:
- Clerk Documentation
- Clerk Quick Start Guide
Web Development Basics:
- MDN Web Docs
- W3Schools

Additionally, we will be hosting a seminar focused on mastering Next.js, a powerful React framework for building server-side rendered applications. This seminar will provide hands-on experience and insights into leveraging Next.js features to enhance Zypher's functionality and performance.

Contributing to Zypher

Now that you have set up your development environment and familiarized yourself with the technologies, you’re ready to contribute to Zypher:

Pick an Issue: Visit the GitHub repository’s issue tracker and find an issue labeled “good first issue” or one that aligns with your skills and interests.
Work on the Issue: Fork the repository, create a new branch for your changes, and implement the solution. Follow best practices for coding and maintain clean, readable code.
Submit a Pull Request (PR): Once your changes are ready, push them to your forked repository and submit a pull request to the main Zypher repository. Provide a clear description of your changes and reference the related issue.
Review and Iterate: Be open to feedback from maintainers and other contributors. Iterate on your code based on feedback to improve its quality and alignment with project standards.
Celebrate and Learn: Once your PR is merged, celebrate your contribution to Zypher! Take the opportunity to learn from the review process and continue growing as a developer.

Conclusion

Congratulations on taking the first step towards contributing to Zypher! This blog has equipped you with the necessary resources and steps to get started effectively. Remember, open-source contributions are not just about code; they’re about collaboration, learning, and making a meaningful impact on projects and communities. Join us in building the future of interactive discussions with Zypher!

Happy coding and happy contributing!

Building in public - A simple guide

Md Kaif Ansari — Sat, 16 Mar 2024 10:08:59 +0000

Building in public is a very peculiar concept that many people are not familiar with. However, by the end of this article, you will understand what "Building in public" means and how it can benefit you in the long term.

What does building in public mean ?

It involves sharing your thoughts, activities, practices, methods, and resources with the world regarding the development of your products or services. This allows others to benefit from your experiences and also gain insights from them.

Getting insights is not just the goal of sharing your activity in public but sharing consistent content will lead to multiple opportunities out there.

Here are some listed below :

Recognition: Sharing your activities publicly can make you known as an enthusiastic individual passionate about technology, opening up opportunities for you.
Brand Popularization: Generating excitement for upcoming products or MVP launches is crucial for creating a brand image, attracting attention, and introducing the product to potential supporters during the creation process.
More Opportunities: Consistently updating platforms like Twitter and LinkedIn can put you in the spotlight for hiring managers, increasing your chances of getting more opportunities.
Easy Referrals: Having a portfolio of your work available can make it easier for you to receive referrals.
Expand Your Network: Building in public helps you connect with a wider range of people globally, leading to more opportunities.

and many more..

How can I start my own journey?

Here are the steps on how you can begin your journey of building things in public.

1. Set up your Social Media

This step is quite obvious, but social media is the primary platform through which you can share your journey of building things. So, create an account on some popular social media platforms. You might wonder why you should share your personal information. Well, all hiring managers and company CEOs are present on these platforms, so having your account there can be a significant advantage.

2. Post / Share Content

Just creating an account on social media is not sufficient; you should be very active by sharing posts or useful content that will benefit people worldwide.

This could include:

Sharing your experiences and learnings of using web technologies through blog posts or YouTube videos
Sharing popular book summaries
Discussing mistakes you made in the past
Sharing insights on "How to contribute to open source"
Documenting your project building process
Sharing your insights about large open source projects

3. Engage with the community

Engaging with the community involves not only posting content but also interacting with others' posts, asking questions, commenting with your suggestions, and sharing your thoughts. This is how you will get noticed by people.

You can also summarize content, add your perspective, and comment on posts. Consistently engaging with a specific person's posts will create a strong connection, and if you ask for help, they will likely be available to assist you.

You can also engage in resolving issues within any organization. This can lead to recognition by the organization's mentor, and if you meet the organization's criteria, you might even receive an offer letter, although this is quite rare.

NOTE: You contribution to open source should not be README update !

You can make in even further by participating in any local meetups, events, fest or hackathons this is also help you expand you connection.

4. Showcase your work

This is the stage where people begin to notice you. Start sharing your projects and accomplishments on social media and other platforms.

Whether it's personal projects, announcements, or blog posts, the goal is to establish your presence in the community.

Keep in mind

The larger your social media presence, the more opportunities you are likely to attract!

Another strategy is to transform a blog post into a video tutorial or a video tutorial into short and engaging Tik Toks or reels. Aim to create a substantial amount of content.

4. Develop a routine

While it may be easy to create content or write a blog post occasionally, consistently posting and creating content can become monotonous. However, if you stop, you risk losing all the progress you have made so far.

Strive to post once or twice a week. Establish a schedule and stick to it.

We don't necessarily need a massive audience of thousands or millions; even a few hundred followers can be valuable. Make it a habit to create content whenever you have the opportunity, whether it's videos or other forms of content.

Habits of TOP 1% Developer

Md Kaif Ansari — Fri, 12 Jan 2024 20:45:40 +0000

I have some insights to share on achieving success as a developer. Although I am only 19 years old, I have accomplished significant results by following certain principles. These have helped put me ahead of over 99% of the people in my circle.

1. Maintain a checklist of things to do

In life, we have many things to accomplish but often fail to attempt them or even forget about them. To help with this, we should maintain a checklist of todos or similar tasks, which will be highly beneficial in the long run.

2. Surround yourself with smart people

As the saying goes, "It is not your environment, it is you." The quality of your mind, the integrity of your soul, and the determination of your will decide your future and shape your life. To achieve success, it's important to surround yourself with smart, like-minded people who can inspire and motivate you.

3. Get out of your comfort zone

It's easy to live life on our terms, but it's much harder to lead a disciplined life with a consistent schedule. Most successful people follow a disciplined routine and dedicate 100% to their work without making excuses. Breaking out of your comfort zone means pushing your efforts to the breaking point.

These are the insights that have worked for me so far. As a new member of the community, I welcome your constructive criticism, which will help me improve.

DEV Community: Md Kaif Ansari

How I Replaced Axios With `fetch` Without Breaking the App

Why I Did This Now

The Goal

The Important Realization

Step 1: Audit What the App Was Really Using

Step 2: Keep the Same API Surface

Step 3: Build a Thin fetch Wrapper

Step 4: Preserve Existing Error Behavior

Step 5: Leave Upload Progress Alone

Step 6: Migrate Imports, Then Remove Axios

Step 7: Validate Like a Responsible Adult

What I Ended Up With

npm Trust Is Weird Right Now

Final Thought

Multitasking, A NIGHTMARE !

A NIGHTMARE ?

What I feel I'm doing and What I ended up doing

The solution

The real changes that WORKS !

Why Owasp BLT ? Contribution from 5 to 50+ prs !

The First PR — Small But It Counts

Going Deeper — BLT-API and the D1 Migration

Talking to Donnie

5 PRs to 50+

Why BLT Specifically

Built a LinkedIn Automation Tool and Survived 206 Commits Later 🫠

the "simple" beginning

when everything went to sh*t

the great migration (aka going full microservices)

the pain points (aka where we cried)

prisma schema syncing nightmare

vercel + github orgs = 💸

azure deployment chaos

what we learned (the hard way)

current status: somehow working ✨

the real talk

Post0

Nodedash: A Simple and Scalable Node.js Backend Template

Nodedash: A Simple and Scalable Node.js Backend Template

Why Nodedash?

Features

Prerequisites

Installation

Usage

Start the development server:

Start the production server:

Running Tests

Formatting Code

Project Structure

Contributing

License

How to deploy your Typescript backend on Render (Simple steps)

Step 1: Prepare Your package.json File

Step 2: Run the Necessary Commands

Step 3: Deploy on Render

1. Create a New Web Service

2. Connect Your Repository

3. Configure Build and Start Commands

4. Deploy

Your deployment will start, if you have configured everything right. It will be deployed successfully.

Final Notes

ContentAce : A Cool AI-Powered Content Generation Platform 🚀

Day 1: Diving into MindsDB 🏊‍♂️

Day 2: Planning the Masterpiece 🗺️

Day 3: Frontend Frenzy 💻

Day 4: Backend Bonanza 🔧

Day 5: Interaction Integration 🤝

Features of ContentAce ✨

Future Plans 🌈

Installation Guide 🚀

Conclusion 🎉

Task Unity- Achieve More Together

Task Unity: Revolutionizing Task Management and Collaboration

Introduction

Key Objectives

Prerequisites

Core Functionality

Installation

Technology Stack

Step 3: Build a Thin `fetch` Wrapper

Step 1: Prepare Your `package.json` File