DEV Community: Joel Jaison

I Let AI Agents Run My Friend Group and Honestly It Is Going Great

Joel Jaison — Mon, 29 Jun 2026 13:47:18 +0000

I Built AI Agents That Plan Weekends So My Friends Don't Have to Reply in WhatsApp

There is always that one group chat.

Every Thursday someone sends,

"Guys... weekend plans?"

Then nothing.

Three people read it. Two forget about it. Someone finally replies on Saturday afternoon asking if the plan is still happening. By then everyone has already made other plans or decided staying home sounds better.

It happens every single week.

I don't blame my friends. We're all busy. Work, college, deadlines, family stuff. Planning something with four or five people somehow ends up feeling like a full time job.

Even if someone actually tries, the questions never stop.

Which movie?

Which theatre?

Who's vegetarian?

Who's free after six?

What's everyone's budget?

Is this place too far?

By the time you've answered everything, the weekend is basically over.

After watching this happen for months I had one thought.

What if everyone had someone to do the planning for them?

Not another chatbot sitting in a group chat throwing random suggestions around.

An actual personal AI agent.

One agent per person.

" width="800" height="640">

It knows your preferences, your budget, your schedule, the places you've hated before, and it argues on your behalf while you're busy doing something else.

The agents negotiate with each other.

You come back later.

There's already a plan waiting.

That became Pakt.

This is how I built it.

Pakt — Plan without the Pain

Your AI agent negotiates with your friends' agents so you don't have to. Pick an activity, add friends, and get back a real plan — venue, time, and budget — without the group-chat back-and-forth.

pakts.tech

Why "Pakt"?

The name came surprisingly early.

It's based on the word pact, a mutual agreement between people.

That's exactly what the app is trying to create.

Friends don't need another recommendation engine.

They need help reaching an agreement.

Changing the C to a K made it a little more memorable.

It also works nicely as a verb.

"Let's Pakt tonight."

That sounded good enough to stick.

The First Decisions

Before writing any code I spent a surprising amount of time deciding what not to build.

The hackathon required using AWS databases, so I had three options.

Aurora PostgreSQL.

Aurora DSQL.

DynamoDB.

For a chat application where multiple AI agents constantly write messages, DynamoDB felt like the obvious choice.

High write throughput.

Simple schema.

And one feature that ended up becoming the backbone of the entire application.

DynamoDB Streams.

The Multi Agent Problem Nobody Warns You About

Whenever people talk about multi agent systems, they usually focus on making agents smarter.

Better prompts.

Better tools.

Better memory.

Nobody talks about the real problem.

How do you make them stop talking?

Seriously.

If you give four AI agents a shared goal and tell them to figure it out, they'll happily keep discussing forever.

They'll agree.

Then disagree.

Then agree again.

Then revisit a point from three rounds ago.

LLMs don't naturally know when a conversation is finished.

They need rules.

That's exactly what LangGraph gave me.

Instead of one long unpredictable conversation, I could define the negotiation as a graph.

An agent speaks.

The next agent responds.

After everyone has spoken, another node checks whether they've reached consensus.

If they have, great.

Publish the plan.

Finish.

If not, start another round.

If they've gone around in circles four times, stop the negotiation and ask the actual humans to decide.

Without that hard stop, the app would have been one very expensive infinite conversation.

The Decision That Changed Everything

One design choice completely changed how the app felt.

Originally I wanted every agent to run in parallel.

It sounded perfect.

Everyone responds at the same time.

Collect the responses.

Done.

Fast.

Efficient.

Then I realised something.

If Agent Two starts thinking before Agent One finishes speaking, Agent Two never actually reacts to anything.

The same goes for everyone else.

What I built wasn't a negotiation.

It was four independent opinions dumped into a chat window.

It felt less like friends making plans and more like filling out a Google Form.

Real conversations don't work like that.

People react.

They change their minds.

They compromise.

Sometimes they completely disagree.

That only happens if everyone can hear what everyone else has already said.

So I changed the graph.

Every agent now runs one after another.

Agent Two reads Agent One's response.

Agent Three reads both.

By the time the fourth person speaks, the conversation has actually evolved.

Yes, it's slower.

But the slowness is exactly what makes it feel real.

Sometimes good software isn't about making something faster.

It's about making it feel natural.

How Everything Actually Works

This is probably my favourite part of the project.

Not because it's the most complicated.

Because it's surprisingly simple once you see the pieces working together.

The frontend never talks to the AI directly.

The AI never talks back to the frontend.

Everything happens through DynamoDB.

Here's what happens when someone sends a message.

The frontend writes the message into the Messages table.

That's it.

Its job is done.

Now DynamoDB Streams notices that something new has been written.

Think of Streams like a doorbell.

Every time a new record appears, it rings automatically.

That event wakes up an AWS Lambda function.

Inside that Lambda is the entire LangGraph workflow.

The function loads everyone's preferences, fetches memories, starts the negotiation, and lets each agent speak one after another.

Every time an agent finishes its turn, Lambda immediately writes that response back into DynamoDB.

It doesn't wait until the whole negotiation is finished.

Each message appears as soon as it's generated.

Back on the frontend there's a Server Sent Events connection quietly listening for anything new.

The moment another message lands in DynamoDB, it's streamed straight into the chat.

Watching the app feels surprisingly natural.

One agent starts typing.

A second later another replies.

Then someone disagrees.

Then another person suggests a compromise.

It feels much closer to watching four friends text each other than watching an AI generate a giant wall of text.

One thing I really liked about this architecture is that every component has exactly one responsibility.

The frontend writes data.

Lambda thinks.

DynamoDB stores everything.

That separation made debugging much easier because whenever something broke I already knew roughly where to start looking.

Giving Every Agent a Memory

Making agents remember your favourite movie sounds impressive.

Honestly, that's the easy part.

The interesting challenge is deciding what they should remember.

Pakt uses two different kinds of memory.

The first is short term memory.

This lives inside DynamoDB and only exists during an active negotiation.

Things like which round we're on, what restaurants have already been suggested, whether someone has voted, whether consensus has been reached.

Once the negotiation ends, that state disappears.

The second is long term memory.

That's stored in Amazon S3 Vectors.

Whenever a plan is accepted or rejected, every user's agent writes a small memory about what happened.

Maybe someone rejected a restaurant because parking was terrible.

Maybe the group loved a particular theatre.

Maybe everyone agreed never to suggest horror movies again.

Those memories are embedded into vector storage and kept completely separate for each user.

When a new conversation starts, the agent searches through those memories before it begins negotiating.

The first time I saw this working properly genuinely caught me off guard.

I started a completely new group.

Nobody had mentioned restaurants yet.

One of the agents immediately said something along the lines of,

"We didn't really enjoy that restaurant last time. Maybe we should try somewhere else."

That information came from a completely different conversation days earlier.

Nobody told the model to mention it.

It simply remembered.

That was one of those moments where the project stopped feeling like a demo and started feeling like an actual product.

The Weirdest Bug I Ran Into

Most bugs are predictable.

This one wasn't.

No matter what group I created, the agents somehow kept suggesting the exact same restaurant.

Someone would reject it because it was too far away.

Another negotiation round would begin.

The same restaurant came back.

Again.

And again.

Then things got even stranger.

My reviewer agent confidently explained that one of the restaurants was in Thrissur.

The address wasn't in Thrissur.

It was actually a mock address in Bangalore.

The model wasn't reading location data.

It was guessing based on the restaurant name.

That sent me down a very long debugging session.

Eventually I realised the problem wasn't the agent at all.

It was my architecture.

The venue search tool wasn't configured with a real Google Places API key yet.

Every search quietly returned the exact same mock dataset regardless of what city anyone searched for.

Every agent was independently calling the same tool.

Every agent received the same fake data.

And because there were no real addresses available, my reviewer agent had nothing concrete to compare.

It had a venue name and a lot of confidence.

That's a dangerous combination.

The fix ended up changing the architecture quite a bit.

Instead of letting every agent search for venues independently, I moved venue search into its own shared step inside the graph.

Now venue search runs once per negotiation round.

It performs a real search.

The results are cached for that round.

Any venue that was rejected gets filtered out before the next search.

Every agent now negotiates using exactly the same list of real places.

Nobody is guessing anymore.

Even better, the reviewer agent now receives the actual address of the selected venue along with every group member's address.

Checking whether somewhere is too far is no longer a guess.

It's just distance calculations.

That one bug completely changed how I thought about multi agent systems.

Shared information beats independent guesses every single time.

Guardrails Aren't Just About Safety

Another lesson I learned was that guardrails save money just as much as they improve reliability.

Originally every single message sent inside a group triggered a full negotiation.

It didn't matter what the message said.

Someone could paste a programming question.

Ask for today's weather.

Type complete nonsense.

The app would still launch an entire LangGraph workflow.

That meant multiple GPT 4o calls for absolutely no reason.

The fix was surprisingly small.

Before a message even gets written into DynamoDB, a tiny GPT 4o mini classifier checks whether it's actually related to planning.

The prompt is tiny.

The token limit is tiny.

If the message isn't about planning, it never reaches Lambda.

No negotiation.

No unnecessary API calls.

No wasted money.

I also added another guardrail after integrating real venue search.

Google Places isn't free.

If something went wrong and negotiations kept restarting forever, the app could quietly burn through API credits.

To avoid that, every search increments a shared counter stored in DynamoDB.

Once the daily limit is reached, the app simply falls back to mock data instead of breaking completely.

Hopefully nobody ever notices that fallback.

But it means I don't wake up to an unexpectedly large bill either.

Teaching Humans How to Talk to Agents

One thing became obvious during testing.

Humans are terrible at giving useful information.

Someone would create a group and type,

"Let's do something this weekend."

That's it.

No date.

No time.

No area.

No activity.

No budget.

The agents would spend the next few rounds asking questions instead of actually planning.

Technically it worked.

Practically it felt slow.

So I added another small step before negotiations begin.

The first message gets checked against a simple schema.

Depending on the activity type, the app looks for things like the date, preferred time, search area, movie genre or cuisine.

If enough information is missing, the chat doesn't even start negotiating.

Instead it renders a small form directly inside the conversation asking only for the missing details.

Once that's filled in, the agents finally have enough context to do something useful.

I made a similar change during onboarding.

Originally adding your home location was optional.

Almost nobody filled it in.

Which meant the distance calculations I had spent so much time building quietly stopped working for most users.

Now it's required.

Locality.

District.

State.

Pincode.

Everything gets geocoded into latitude and longitude during onboarding.

From that point onwards, every venue recommendation actually considers how far everyone has to travel.

That tiny onboarding change ended up making the recommendations feel dramatically smarter without changing the agents themselves.

Making Memory Visible

I realised something after building long term memory.

Users had no idea what their agent actually remembered.

They just had to trust me.

I didn't like that.

So I added a Memory page to the dashboard.

Every memory the agent stores is visible there.

Users can browse through them, see why they were saved, and delete anything they don't want anymore.

It doesn't make the AI smarter.

It makes the product feel more trustworthy.

I think that's just as important.

People are much more comfortable with AI remembering things when they can actually see what those things are.

What Pakt Looks Like Today

After weeks of building, rebuilding, debugging and questioning my own decisions, Pakt finally feels like a real product instead of a collection of AI experiments glued together.

The experience is intentionally simple.

You sign up once.

Tell the app a little about yourself.

Your favourite movies.

Food preferences.

Budget.

Your general schedule.

Where you live.

That's all the setup you need.

From there everything happens inside the group chat.

Create a group.

Invite your friends.

The moment everyone joins, their agents get to work.

Nobody has to tell the agents to start.

Nobody has to type "any suggestions?"

The conversation begins automatically.

The agents discuss different options, recommend movies from TMDB, find restaurants using Google Places, remember what the group enjoyed before, and slowly work towards something everyone is happy with.

Sometimes they agree almost immediately.

Sometimes they don't.

When there's a genuine split between two good options, Pakt creates a vote inside the chat.

Real people vote.

The agents take that result and continue negotiating from there.

Humans stay in control.

The agents just remove all the exhausting back and forth.

And if someone suddenly joins the conversation halfway through and says,

"I can't stay out too late tonight."

"I'm not really in the mood for pizza anymore."

The agents immediately adjust the negotiation around that new information.

Nothing has to restart.

The conversation simply continues.

Once everyone reaches an agreement, the chat ends with a plan card containing everything the group needs.

The venue.

The time.

The people joining.

And eventually, I want that card to include the actual booking as well.

A Few Small Things That Made a Big Difference

Not every improvement involved complicated architecture.

Some of my favourite fixes were tiny.

One of the first things I noticed during demos was that GPT naturally writes Markdown.

Lists.

Bold text.

Headers.

The chat wasn't rendering any of it.

Instead people saw a screen full of random asterisks.

It looked broken.

One Markdown renderer later, the entire conversation suddenly felt polished.

Another surprisingly important improvement involved the demo accounts.

Originally they all had empty profiles or random addresses.

The agents would recommend places that made absolutely no sense because nobody actually lived anywhere.

Before recording demos, I replaced those with real nearby locations.

Suddenly the recommendations became believable.

Sometimes the smallest details make the biggest difference when you're showing a product to someone for the first time.

Under the Hood

The final architecture ended up being much bigger than I originally expected.

There are six DynamoDB tables.

Users.

Groups.

Messages.

Negotiation state.

Polls.

And one extra table that exists for one reason only.

Making sure usernames stay unique using transactional writes.

The AI workflow runs inside AWS Lambda.

Each execution gets a 300 second timeout, which is far more than a normal negotiation ever needs.

To avoid cold starts during demos, EventBridge pings the function every few minutes.

Nobody watching a live demo wants to wait while Lambda wakes up.

Some engineering decisions exist purely because you've been embarrassed once.

That was one of them.

What I Want To Build Next

I think Pakt solves the hardest part of planning.

Getting people to agree.

But there's still one obvious gap.

Right now the agents decide where everyone should go.

The humans still have to book the movie tickets.

Reserve the restaurant.

Buy the event tickets.

I want the conversation to end with the booking already completed.

The agents shouldn't just recommend something.

They should finish the job.

The second thing I want to build is a proper mobile app.

This problem lives on phones.

Every group chat lives on phones.

People aren't sitting at a laptop wondering what they're doing on Saturday night.

They're checking WhatsApp while waiting for a bus or standing in a queue somewhere.

The experience belongs on mobile.

Longer term, movies and restaurants are just the beginning.

Weekend trips.

Concerts.

Sports.

Road trips.

Coffee catch ups.

Game nights.

The negotiation engine doesn't really care what it's planning.

It just needs different tools and different questions.

That part is surprisingly scalable.

What This Project Actually Taught Me

When I started building Pakt, I thought the hardest part would be getting the AI to make good decisions.

It wasn't.

The AI was probably the easiest part.

The difficult part was everything around it.

Designing the architecture.

Making sure every agent had the same information.

Knowing when a negotiation should stop.

Making sure memory actually helped instead of confusing the conversation.

Keeping costs under control.

Building guardrails.

Handling failures without breaking the experience.

Those ended up being the real engineering problems.

One lesson stood out more than anything else.

I originally thought running every agent in parallel would make the app feel smarter.

Instead it made the conversation feel fake.

The moment I switched to sequential negotiation, everything changed.

The agents actually started responding to each other.

Compromises appeared naturally.

Arguments felt believable.

The conversation slowed down.

Ironically, that slower experience felt much more human.

Sometimes making software feel intelligent isn't about making it faster.

It's about making it behave the way real people do.

Final Thoughts

Pakt started because my friends couldn't decide where to go on weekends.

Somewhere along the way it turned into one of the most enjoyable projects I've ever built.

Not because of the technologies.

Not because of the hackathon.

But because it kept forcing me to rethink how AI systems should actually work.

I went into this project thinking I was building a chatbot.

I came out of it thinking much more about orchestration, memory, shared context, architecture and trust than prompts or models.

That's probably the biggest lesson I took away.

If you're building multi agent applications, spend less time trying to make individual agents smarter.

Spend more time thinking about the system they live inside.

Shared context.

Clear responsibilities.

Good orchestration.

Reliable memory.

Those matter far more than another clever prompt.

And if your group chat still spends three days deciding where to eat every weekend, hopefully Pakt can save you from reading another message that says,

"So... are we doing anything or not?"

JoelJaison394 / Pakt

AI agents that negotiate your social plans, so you don't have to.

Pakt

AI agents that negotiate your social plans, so you don't have to.

Each user has a personal AI agent that knows their tastes, schedule, and budget. When a group wants to plan a movie night or dinner, their agents negotiate with each other in a shared chat — proposing, compromising, polling, and converging on a single confirmed plan — with the real humans able to jump in and override at any point.

Built for H0: Hack the Zero Stack (AWS DynamoDB + Vercel + Next.js) — deadline 30 June 2026.

The Problem

Planning leisure time with friends is broken — not because people don't want to hang out, but because of the coordination overhead:

"Can we do Saturday?" starts a 40-message thread that takes 3 days to resolve.
Everyone has different schedules, budgets, food preferences, and movie tastes.
Someone always says "IDK, up to you" — decision paralysis…

View on GitHub

Our Story · Pakt

How one chaotic group chat with zero plans turned into Pakt — AI agents that negotiate a real plan so your friends don't have to argue about it.

pakts.vercel.app

Built for the H0 Hack the Zero Stack Hackathon.

Stack

Next.js
Vercel
AWS Lambda
Amazon DynamoDB
DynamoDB Streams
LangGraph
OpenAI GPT 4o
Amazon S3 Vectors
TMDB API

I Finally Built Something Real for People Like Me Who Procrastinate – Break the Block

Joel Jaison — Sun, 01 Mar 2026 19:24:58 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community I Built For

I built this for a community I deeply belong to:

Developers. Students. Indie hackers. Creators.

We are ambitious — but stuck.

We:

Research productivity instead of being productive
Optimize workflows instead of finishing projects
Watch tutorials instead of shipping
Open YouTube when tasks feel overwhelming

We are not lazy.

We are digitally paralyzed.

That is the community I built for.

💡 The Problem

Modern apps are engineered for passive engagement:

Infinite scroll. Variable rewards. Dopamine loops.

But real-world goals feel:

Abstract
Heavy
Intimidating

The gap between intention and action keeps growing.

So I asked:

What if the same dopamine loops that keep us scrolling could be redirected toward real-world execution?

That question became Break the Block.

🚀 What I Built

Break the Block is a gamified, proof-based goal execution platform.

It turns productivity into a cooperative RPG.

Instead of tracking habits alone and feeling guilty, users collaborate to defeat a shared enemy:

🪨 The Global Stasis Stone

A visual “raid boss” representing procrastination.

Every real-world action:

Deals damage to the Stone
Earns XP
Advances your faction

There are three layers:

🛡️ Group Stone
🌍 Regional Stone
🌎 Global Stone

Hit 100% → confetti + badge → monthly reset.

Execution becomes collective.

🎥 Demo

Live - BreakTheBlock

💻 Code

View the source code on GitHub →

🛠️ How I Built It

I know we all hate getting bogged down in complex setups, so I wanted to keep things simple, fast, and reliable. Here is the stack I used to outsmart our own procrastination:

Next.js, Tailwind & Vercel — I actually thought about just using plain React, but I went with Next.js for that snappy performance. Hosted on Vercel because deployments should take seconds, not hours. Tailwind CSS to make the UI feel "crunchy"—every click gives that little dopamine hit you usually get from scrolling.
*Supabase * — Supabase for auth and real-time database (perfect for live Faction Leaderboards).
OpenAI API — Powers the "Friction Breaker." Custom prompt that takes a big scary goal (like "start my portfolio") and chops it into three stupidly easy 5-minute tasks.
Inngest — Handles background jobs (XP calculation, AI prompts) so the frontend always feels instant—no loading spinners.
Backblaze — "Proof of Action" means no photo = no XP. User image uploads go straight to Backblaze B2: fast, reliable, cheap.
Sentry — Catches bugs immediately so I don't get distracted hunting silent errors.

🧠 The (Quick) Science Behind the Features

I’m no neuroscientist, but during my late-night research (which was definitely just me procrastinating on actually coding), I dug into why our brains freeze up. I built the core features around a few specific behavioral science tricks:

Task Decomposition (The Friction Breaker AI)

When we look at a massive goal like "Build a Portfolio," our brains process that ambiguity as a literal threat → "freeze" response. By forcing the AI to chop it into three 5-minute micro-steps, we drastically lower the Activation Energy required to start. It tricks your brain into thinking, "Oh, I just have to open a new file? I can do that."

The Köhler Effect (The Stasis Stone & Factions)

In psychology, the Köhler Effect is when people work harder as part of a team so they don't let others down. By making the "Stasis Stone" a shared community boss, we weaponize our natural desire for social belonging. You aren't just doing the task for you; you're doing it so your Faction doesn't lose momentum.

High-Friction Accountability (Proof Verification)

We are numb to digital checkboxes. Clicking "Done" gives almost no dopamine anymore. Forcing users to take a physical photo of the completed task creates Intentional Friction. It pulls you out of the screen, into the real world, and makes the achievement feel earned.

Try it out!

→ Try Break the Block and Defeat the Stasis Stone!

KeyPilot – Semantic API Gateway with Real-Time AI Routing & Caching

Joel Jaison — Sun, 10 Aug 2025 18:03:40 +0000

This is a submission for the Redis AI Challenge: Beyond the Cache.

What I Built

One request, one intent and KeyPilot knows exactly which API to call.

Imagine you’re juggling five different AI services.
Each has its own API key, its own endpoint, and its own quirks.
Now, every time you want to build something, you have to stop and think:
"Which key should I use? Which service is cheaper for this request? Which one even supports what I need?"

That’s where KeyPilot steps in....

I’ve built a semantic API gateway that listens to what you actually want to do
"Summarize this document" or "Generate an image of a mountain village"
and instantly picks the right API key and endpoint for you.
No hunting through docs. No manual switching.

Here’s the magic:

Redis Vector Search understands the intent behind your request.
Redis Caching remembers if we’ve answered this before
and serves it back in milliseconds without hitting the API again.
You save time, you save money, and your integration just works faster.

With KeyPilot, I’m not just routing requests,
I’m making API integration faster to build, cheaper to run, and smarter every time you use it.

Demo - Before You Jump In…

I know what you’re thinking…
"Joel, just give me the live link, I’ll click it right now and start playing with it!" 😏

But here’s the thing—without the login credentials, you’ll just end up staring at the login screen wondering what went wrong.
And then… you’ll have to come back here looking for the details anyway.

So let’s save you that awkward extra step, shall we? 😉

👉 Live App - https://smartkeypilot.vercel.app/

Quick Heads-Up

This is a demo app, built fast to show you the core idea. It’s not a locked-down, production grade fortress. Think of it as a cool prototype enough to impress, but not something you’d run your banking on.

A few ground rules:

No personal API keys, please. 🙅‍♂️ I’ve already included demo-friendly keys for you.
If you absolutely must use your own, make sure they’re temporary and revocable.
Demo sessions last 8 minutes. When time’s up, poof all keys are wiped.
Be nice to the system ❤️ —no spam, no abuse, let’s keep the experience smooth for everyone.

🔐 Demo Login

Follow this simple pattern:

Username: demo + 1–3 digits → (Example: demo123)

Password: pass + the same digits → (Example: pass123)

Pick any number combo you like just stick to the format. Once you’re in, you’re free to explore with the built in demo API keys.
✅ No setup. ✅ No risk. ✅ Instant fun.

Using the Demo Keys

The app already has demo API keys built in, so you can try out everything semantic intent matching, routing, caching right away.
If you do add your own keys, remember—they’ll vanish as soon as your session expires.

Run It Locally (Optional)

If you landed here before smashing the demo link… I like you already. 🤝

For the best performance, hook it up to Redis Cloud for your connection string this gives you superfast vector search and caching ( fast and simple ).

Frontend repo: https://github.com/Joeljaison391/KeyPilot-Frontend

Backend repo: https://github.com/Joeljaison391/KeyPilot

⏱ Short on time?

No problem I’ve got you.
Here’s a quick intro video so you can watch the demo without lifting a finger:

ScreenShots

Welcome to KeyPilot

This is our Landing Page — clean, simple, and inviting.
The goal is to instantly tell you what KeyPilot does and give you a way to dive right in.

Getting Started

Here’s the Login Page no fuss, no confusion.
Just sign in, or hop in using the demo mode to explore without creating an account.

Onboarding in Minutes

New here?
Our Onboarding Tutorial walks you through the essentials, from finding your API keys to using the testing playground so you can get productive right away.

Your Mission Control – The Dashboard

Once inside, the Dashboard is your command center.
See your keys, usage stats, and quick actions all in one place.

Adding a Key

Need a new API key? The Add Key Modal makes it easy.
Choose a provider template, set limits, define allowed origins and you’re done.
Keys are encrypted and automatically expire when they should.

Behind the scenes, Redis Cloud powers everything from storing encrypted keys to caching API responses.
Here’s the Redis Cloud dashboard keeping it all running lightning-fast.

Testing APIs in Real-Time

Welcome to the API Testing Playground tweak payloads, change your intent, and watch KeyPilot choose the best template using semantic matching.

Intent Testing (Without Spending Tokens)

Curious which template your request would trigger but don’t want to hit a real API?
The Intent Testing Tool lets you check without making an actual API call.

Smart Caching for Cost & Speed

Why pay for the same API call twice?
KeyPilot uses semantic caching if a similar request was made before, it serves the stored response instantly, saving cost and time.

Monitoring & Insights
Finally, keep track of everything with API Usage Monitoring from tokens used and uptime/downtime, to success rate and cache hits.

Tech Stack

Here’s what powered this build:

Frontend
----------
I went with Vite + React because I wanted blazing fast dev speed and a smooth production build. Styling? Tailwind CSS because writing raw CSS at 3 AM is not a vibe. Everything’s hosted on Vercel, so deployment is just a push away.

Backend
----------
The server runs on Node.js + Express.js, written in TypeScript for that sweet type safety. I hosted it on Render, which meant I could focus on coding instead of babysitting servers.

Data Layer
----------
This is where things get interesting. Redis Cloud is my main database, handling both vector search and caching like a champ. For ultralow latency ops, I also keep a Redis in-memory instance because milliseconds matter.

Workflow
----------
Version control? Git, obviously.
Brainstorming and team planning? Notion, where ideas go from “what if…” to “ship it.”

How I Used Redis 8

Why Redis? Why Not “Normal” Databases?

Most people think of databases like PostgreSQL, MySQL and MongoDB when building apps.
They’re great for longterm, structured storage, but for this project, I needed something different

⚡ Speed over everything – I wanted sub-millisecond lookups.
🕒 Built-in expiration – Sessions and API keys should self-destruct after a few minutes, no cron jobs.
🔐 Simple, atomic ops – Set it, get it, delete it. No complex joins.
🧠 Works as cache and DB – Why juggle two systems when one can do both?

If I had used a normal database:

I’d have to write extra code to delete expired sessions.
Every API call would be slower due to disk-based queries.
Caching would require a separate Redis instance anyway.

So instead of this twosystem headache, I went all in on Redis 8 as a full-fledged primary database for this app.

How Redis Runs the Show in KeyPilot

When I say Redis is the backbone, I mean it literally runs everything from logging you in, to storing your API keys, to making sure your session politely disappears after 8 minutes without me lifting a finger.

Authentication Routes – “You’re In!”

We used Redis Strings & Hashes to store user sessions and encrypted API keys, with TTL auto expiration so they vanish when no longer needed.
This means no manual cleanup, no stale logins, and instant access.

await redis.setEx(`user:${userId}`, 480, JSON.stringify(sessionData));
await redis.expire(`keys:${userId}:${template}`, 480);

API Key Management – “Your Keys, Your Rules”

Every API key got stored in a Redis Hash with metadata like creation time and description.
No duplicate keys, no outdated entries — just clean, encrypted storage.

await redis.hSet(`keys:${userId}:${template}`, {
  encrypted_key: encrypted,
  description,
  created_at: Date.now()
});

Proxy & Semantic Cache – “Smartest Route Wins”

Redis RediSearch + Vector Index let us match the right API key to the right request based on meaning, not just keywords.
Once fetched, the response got cached for blazing replays.

const results = await redis.ft.search(
  'idx:intents',
  '*=>[KNN 1 @vector $query_vector]',
  { PARAMS: { query_vector } }
);
await redis.setEx(`cache:${userId}:${intentHash}`, 3600, JSON.stringify(apiResponse));

Analytics & RealTime Tracking – “See It As It Happens”

We combined Redis Pub/Sub, Streams, and Counters to track every request in real time.

Pub/Sub broadcasts “received” and “completed” events to the dashboard instantly.
Streams keep a time-ordered history of activity and cached requests.
Counters aggregate daily and weekly stats for quick summaries.

// Live event broadcasts
await redis.publish('channel:request:received', JSON.stringify({ userId, intent, ts: Date.now() }));
await redis.publish('channel:request:completed', JSON.stringify({ userId, latency, cacheHit, ts: Date.now() }));

// Activity stream (last 50 events)
await redis.xAdd(`analytics:activity:${userId}`, '*', { event: 'request:success', intent, latency: String(ms) });
await redis.xTrim(`analytics:activity:${userId}`, 'MAXLEN', 50);

// Daily counters
await redis.incr(`analytics:daily_requests:${userId}:${date}`);

Analytics Dashboard – “Know What’s Trending”

Every intent a user triggered got counted using Sorted Sets.
This gave us instant leaderboards of top requests perfect for spotting patterns.

await redis.zIncrBy(`intent_trends:${userId}:daily`, 1, intent);
const topIntents = await redis.zRange(`intent_trends:${userId}:daily`, -5, -1, { REV: true });

Cache Management – “One Sweep, All Clean”

Redis made it easy to find and wipe old cache keys in bulk.
No messy SQL queries, just a quick scan and delete.

const keys = await redis.scanIterator({ MATCH: `cache:${userId}:*` });
for await (const key of keys) await redis.del(key);

Intent Tracking & Trends – “What Users Want, Right Now”

We kept a running tally of weekly user intents using Sorted Sets.
This helped us predict what users would request next almost like reading minds.

await redis.zIncrBy(`intent_trends:${userId}:weekly`, 1, detectedIntent);

By combining multiple Redis 8 features, we replaced five different systems:

No extra SQL database for sessions
No Elasticsearch for search
No Kafka for event streaming
No cron jobs for cleanup
No separate analytics DB

What Tried to Slow Me Down (But Didn’t) 💪

Minimal UI, Maximum Clarity
----------------------------
My rule was simple: if someone needs a manual, I messed up.
So I kept cutting extra text, moving things around at random hours, and swapping long explanations for small icons. I just wanted people to open the app and instantly know what to do.

Time Pressure (Hackathon Mode)
----------------------------
The clock felt louder than my keyboard.
Every decision was the same question: should I make it perfect or just make it work? I went with “make it work.”

Semantic Matching & Provider Templates
----------------------------
The idea was simple: type what you want in plain English, and the app figures out which API to call. Sounds easy… but it wasn’t.
I had to create flexible templates for different services and still keep them accurate. By the time I was done, I’d listened to over 150 songs and sat through 60+ Spotify 🎧 ads while coding.

Speed Optimization in Practice
----------------------------
Saying “sub-millisecond” is easy. Making it happen? Not so much.
I spent hours tuning Redis queries, cutting down data sizes, and setting up caching all while making sure nothing else broke.

Team

Special thanks to abelboby for contributing to the frontend development and helping bring the user experience to life.

Thank You for Reading

If you made it this far, thank you! 🚀
I truly appreciate you taking the time to explore this project and follow along with the journey.

Download Manager v0.1.0

Joel Jaison — Mon, 23 Dec 2024 13:08:57 +0000

I’m excited to announce the release of Download Manager v0.1.0, an enhanced version of this lightweight Rust-based file organizer. This release marks a significant upgrade, adding new features, refining existing functionalities, and overcoming challenges to make Downloads folder management even more efficient.

What’s New in v0.1.0?

1. Initial Report Generation

When you first run the application, it generates an HTML report summarizing the state of your Downloads folder. This report provides insights into:

Total number of files.
Distribution of file types (e.g., Images, Videos, Documents).
Storage usage by category.

This feature ensures users start with an immediate overview of their Downloads folder.

2. Weekly Reports

Every week, the application generates a detailed HTML report, including:

File type breakdowns.
Total size and number of files.
Insights into unused files taking up space.
Visual charts (pie and bar graphs) for better data representation.

These reports are automatically generated at the beginning of each week, keeping you informed without manual effort.

3. Unused File Management

Files not accessed for 30 days are now moved to a dedicated Unused folder. Within this folder, files are categorized into subdirectories like Images, Videos, and Documents, making it easier to revisit or clean up these files.

The Process of Adding New Features

Every feature in this release was driven by the goal of making file organization smarter and more intuitive. Here’s how I approached each addition:

Initial Report Generation

I started with the requirement to analyze the entire Downloads directory on the program's first run. Using Rust's efficient file-handling capabilities, I created an HTML report that’s both visually appealing and easy to read. Handling large directories was challenging, but with optimized file iteration and selective metadata extraction, this process is now seamless.

Weekly Reports

Automating weekly reports involved tracking the last report’s generation using a report_status.txt file. This ensured reports are created at the right intervals. If the program wasn’t running during the scheduled time, the system checks the report generation status on the next startup.

Unused File Handling

Defining "unused" files as those inactive for 30 days was the first step. Scanning large directories efficiently was another challenge, but by leveraging Rust’s performance-optimized file system libraries, I ensured the process doesn’t interrupt real-time monitoring.

Challenges and How I Overcame Them

File Stability During Monitoring

Temporary and incomplete files caused errors during processing. To handle this, I added a file stability check that waits until the file size remains constant before organizing it.

Visualizing Data

Generating visually appealing reports involved integrating Chart.js into the HTML reports. Converting file metadata into chart-friendly formats was tricky but rewarding. The result is an aesthetically pleasing report that combines functionality with design.

Automated Testing with GitHub Actions

Testing these features required simulating a Downloads environment. Using GitHub Actions, I automated the process by downloading sample files, running the application, and verifying outcomes. Challenges like handling network issues during downloads were resolved with retries and caching.

What’s Next?

While v0.1.0 introduces exciting features, I’m already planning for the future:

Cross-Platform Support: Extend the tool to Linux and macOS.
Customizable Rules: Allow users to define their own file organization rules.
Cloud Integration: For users who want reports and organized files backed up.

Joeljaison391 / Downloads-Organizer

A Rust application designed to automate the organization of your downloads. It watches for new files and moves them to appropriate directories based on their extension, simplifying file management and improving workflow.

Download Manager

Overview

A lightweight Rust-based file monitoring and organizing tool designed to automatically segregate files downloaded into appropriate folders based on their type. The program monitors the Downloads folder for file events and organizes files into categories like Images, Videos, Documents, Archives, Audio, and Others

Features

File Monitoring: Monitors the Downloads folder for new files and organizes them based on file type.
Stability Check: Waits for file stability before processing (e.g., for partially downloaded files).
File Categorization: Automatically moves files into appropriate subfolders (e.g., Images, Videos, Documents).
Unused File Management: Identifies unused files and moves them to the Unused folder, organized by type.
Initial Report Generation: Generates a detailed report about the Downloads folder on the first run.
Weekly Reports: Automatically generates a detailed weekly report summarizing the files in the Downloads folder.
Subdirectory Analysis: Includes all subdirectories (e.g., Images, Videos…

View on GitHub

Download Manager v0.1.0 is a big step forward, and I’m thrilled to share it with you. If you haven’t tried it yet, head over to the release page and give it a go. Your feedback is invaluable, and I look forward to hearing your thoughts!

Building an Efficient File Organizer with Rust

Joel Jaison — Thu, 12 Dec 2024 18:55:08 +0000

Managing a cluttered Downloads folder is a problem that many of us face. Files pile up quickly, and before we know it, important documents, images, and videos get lost in a sea of irrelevant or outdated downloads. With this in mind, I set out to build a tool that organizes files automatically while being lightweight and efficient. Here’s the journey of how I developed the Download Manager, the challenges I encountered, and the lessons I learned along the way.

What is Download Manager?

The Download Manager is a Rust-based application that I built to automatically organize the Downloads folder. It monitors new file events, waits for files to stabilize, and categorizes them into folders like Images, Videos, Documents, Archives, Audio, and Others. The tool is built for Windows and is designed to be both fast and resource-efficient.

How to Use Download Manager

1. Download the Executable

Visit the GitHub releases page and download the prebuilt executable file (downloadManager.exe).

2. Configure in Task Scheduler

To ensure the tool runs automatically at system startup:

Open Task Scheduler (Press Win + R, type taskschd.msc, and press Enter).
Click Create Task on the right-hand side.
In the General tab:
- Name the task (e.g., "Download Organizer").
- Select Run whether user is logged on or not.
- Check Run with highest privileges.
Go to the Triggers tab:
- Click New and set the trigger to At system startup.
- Click OK.
Go to the Actions tab:
- Click New.
- Set Action to Start a program.
- Browse to the downloaded downloadManager.exe file and select it.
- Click OK.
Go to the Conditions tab:
- Uncheck Start the task only if the computer is on AC power.
- Check Wake the computer to run this task.
Click OK to save the task.

The tool will now run automatically at startup and monitor your Downloads folder.

3. Running Manually

If you prefer to run the program manually, simply double-click the downloadManager.exe file. The tool will start monitoring the Downloads folder immediately.

Problems I Faced and How I Solved Them

1. Handling Temporary Files

Problem: Many browsers like Chrome create .tmp or .crdownload files while downloading. If my tool processed these files prematurely, it interrupted downloads.

Solution: I implemented a file stability mechanism. The program ignores .tmp and .crdownload files until they are renamed. Additionally, I periodically check file size to ensure the file is stable before moving it.

2. Monitoring Resource Usage

Problem: File monitoring could easily become resource-intensive, consuming significant CPU and memory, especially during frequent file events.

Solution: To address this, I:

Used Rust's efficient libraries like notify for file event monitoring.
Implemented benchmarks to analyze and optimize CPU and memory usage. The program stabilizes at ~13 MB of memory usage and spikes to ~0.77% CPU during active monitoring, making it suitable for everyday use.

Fun Fact: Did you know that Rust is often called a "memory-safe language" because it avoids common memory errors like null pointer dereferences and buffer overflows?

3. Ensuring Cross-File Compatibility

Problem: Files come in a variety of formats. I needed to ensure proper categorization for dozens of extensions.

Solution: I implemented an extensive list of file extensions, mapping them to their respective categories like Images, Videos, and Documents. For unknown extensions, I used a default "Others" folder. This keeps the system future-proof for new file types.

4. Avoiding Interruptions During System Startup

Problem: Running the tool via Task Scheduler sometimes caused a terminal window to appear, disrupting the user experience.

Solution: I recompiled the program using the windows_subsystem = "windows" flag in Rust, ensuring the tool runs silently in the background without a visible terminal window.

5. Keeping It User-Friendly

Problem: Many users are not comfortable with command-line tools or complex setups.

Solution: I:

Provided a prebuilt executable for direct download from GitHub releases.
Included detailed instructions for configuring the tool in Task Scheduler for automatic startup.
Added desktop notifications to inform users of file movements, making the experience interactive and transparent.

Benchmarking and Testing

I tested the Download Manager on the following device:

Device Name: Lenovo Ideapad Gamming 3i
Processor: 12th Gen Intel(R) Core(TM) i5-12450H @ 2.00 GHz
Installed RAM: 32.0 GB
OS: Windows 11 Home, Version 23H2

Benchmark Results:

CPU Usage: Peaks at ~0.77% during active file monitoring.
Memory Usage: Stabilizes at ~13 MB during regular operations.

Insights:

The tool runs efficiently in the background and is ideal for users who want a "set it and forget it" solution. I made sure it remains user-friendly and lightweight.
Resource usage remains minimal even during heavy file operations, thanks to Rust's performance and low-level control.

Ideas for Similar Projects

If you're inspired by this project, here are some ideas you can explore yourself:

Photo Organizer:

Automatically sort photos by date, location (using EXIF data), or event name.

Music Library Manager:

Categorize audio files based on artist, album, or genre.

Document Digitizer:

Monitor scanned documents and automatically rename and move them based on OCR-detected content.

Video Compressor:

Monitor video folders and compress large files automatically to save disk space.

Cross-Platform File Organizer:

Extend the file organizer concept to support Linux and macOS.

Final Thoughts

The Download Manager project was both a challenging and rewarding experience. It taught me the importance of handling edge cases like temporary files and optimizing for low resource usage. Most importantly, it reinforced the power of automation to make life simpler and more productive.

I hope this tool helps you keep your Downloads folder tidy. I'd love to hear your feedback and ideas! If you’d like to contribute or suggest features, check out our GitHub repository!

Joeljaison391 / Downloads-Organizer

A Rust application designed to automate the organization of your downloads. It watches for new files and moves them to appropriate directories based on their extension, simplifying file management and improving workflow.

Download Manager

Overview

Features

File Monitoring: Monitors the Downloads folder for new files and organizes them based on file type.
Stability Check: Waits for file stability before processing (e.g., for partially downloaded files).
File Categorization: Automatically moves files into appropriate subfolders (e.g., Images, Videos, Documents).
Unused File Management: Identifies unused files and moves them to the Unused folder, organized by type.
Initial Report Generation: Generates a detailed report about the Downloads folder on the first run.
Weekly Reports: Automatically generates a detailed weekly report summarizing the files in the Downloads folder.
Subdirectory Analysis: Includes all subdirectories (e.g., Images, Videos…

View on GitHub

Feel free to leave your comments or suggestions below. Happy coding!

"Color Maze" - an accidental project

Joel Jaison — Sat, 30 Mar 2024 17:29:27 +0000

The Inspiration Behind ColorMaze

It all started with another project – an ambitious one aimed at creating an AI-powered color suggestion tool for Figma, the popular design platform. To make this AI truly insightful, we needed a massive dataset of color palettes, each carefully tagged with details about the emotions and feelings they evoke.

Unfortunately, there wasn't a single, perfect dataset readily available. So, we decided to get creative and build our own!

Data Collection

The data collection process involved scouring the web for freely available images through scrapping only from free sources🙂 .... (think stunning landscapes, eye-catching product designs, and everything in between). Using clever algorithms from the scikit-learn library, we extracted the dominant colors from each image.

But here's the twist: we didn't stop there. We leveraged the principles of color psychology to create three unique color palettes from those extracted colors. This way, our AI could learn the subtle associations between colors and human emotions.

To automate this data collection process, I chained together a series of Azure Cloud Functions. These functions acted like tiny robots, diligently scraping images, extracting colors, and generating palettes. And to avoid those pesky captchas that slow things down, we employed a clever cron job scheduling technique.

The result? A treasure trove of color data, meticulously collected and stored in the cloud

ColorMaze: A Sneak Peek

But wait, there's more! With this vast collection at our disposal, we decided to create something special for everyone – ColorMaze. This website allows you to explore the world of color palettes, including some hidden gems you might not find anywhere else (think premium palettes from all your favorite design sites!).

Right now, ColorMaze is still under development, undergoing its finishing touches and functionality tweaks. But feel free to check it out and let us know if you encounter any bugs – we view them as our little companions on the path to perfection!😅

The future of ColorMaze is brimming with possibilities. With the approval of my teammates, we plan to populate the site with the entirety of our color data collection. This will create a truly unique resource for designers and anyone who loves the language of color.

As for the source code, we're keeping that under wraps for now, but we're excited to share the final product with the world! So, stay tuned and keep an eye out for ColorMaze – it's destined to become your go-to destination for all things color inspiration.

checkout colormaze here - colormaze website

and also wishing everyone who reads on 3/31/2024 a Happy Easter🥚

StarBoard v1.0.0

Joel Jaison — Sun, 03 Mar 2024 13:58:56 +0000

A few weeks ago, I found myself searching for the perfect productivity tool, blending the user-friendliness of Notion, the intuitive layout of Trello, and the automation prowess of Zapier. Surprisingly, the options I discovered were mostly paid, and open-source alternatives were either less user-friendly or demanded extensive configurations. Faced with these challenges, I recalled my experience with an old task manager CMD tool built in Rust and decided to build something new, which led to the birth of StarBoard.

StarBoard's Origin Story

StarBoard, a name chosen hastily, might evolve in the future. The tool aims to streamline task and work management, eliminating unnecessary complexities. The vision includes automating repetitive steps, integrating with various platforms, and providing an efficient solution for task management.

Development Approach

To address concerns about privacy, data storage, and server setup, I decided to build StarBoard as a desktop software, focusing on Windows users. As a Windows user myself, this choice not only aligns with my preferences but also streamlines the development process.

Current Status

StarBoard has been pre-released with fundamental features allowing users to create collections and group tasks within them. Users can easily change the status of tasks from pending to completed or mark them as in progress. While this pre-release is not stable, the upcoming version 1.1.0, expected by the end of June, will offer a more polished and stable experience.

Contribution and Collaboration

Building a project from scratch is a challenging task, and I invite anyone interested to join and contribute to StarBoard's development. Every contribution is valuable, whether it's code, UI improvements, or feedback. Together, we can shape StarBoard into a robust and user-friendly productivity tool.

Get Involved

If you're interested, you can explore the pre-released version on GitHub. Feel free to test it out, provide feedback, or contribute to its development.

StarBoard GitHub Repository

A cliché rusty project built using rust

Joel Jaison ・ Feb 20 '24

#rust #tutorial #programming #beginners

Rust Daily Challenge Day-1

Joel Jaison — Thu, 29 Feb 2024 04:08:16 +0000

Today, we will focus on creating a Rust function called greet_user that takes a user's name as a parameter, reads input from the terminal, and prints a personalized greeting message.

In Rust, a function is defined using the fn keyword followed by the function name, parameters, return type (if any), and the function body enclosed in curly braces {}. Let's break down the structure of the greet_user function:

Here
fn: Keyword indicating the start of a function definition.

greet_user: Name of the function.

(name :&str): Parameter list enclosed in parentheses ()

name: Name of the parameter.
&str: Type of the parameter, indicating a string slice.

The main function is the entry point of a Rust program.It contains the code that will be executed when the program is run.

println!("Enter the name ");: Prints a message asking the user to enter a name.
let mut userName = String::new();: Declares a mutable variable userName of type String to store the user's input.
std::io::stdin().read_line(&mut userName).expect("Something error happened"); -

Reads a line from the standard input (keyboard) and stores it in the userName variable.
&mut userName passes a mutable reference to userName to allow the read_line function to modify its contents.
expect("Something error happened"); handles any potential errors that may occur during the input operation.

greet_user(&userName);: Calls the greet_user function with a reference to the userName variable as an argument.

Passing a reference (&) to userName allows greet_user to access the value without taking ownership of it.

Now when we run this code the output will be

To avoid the problem of newline character causing the ouput template string to be in newline after the template word , we need to trim out the user input

so for that the code should be modified like wise

Here the user input is trimmed before passing it to greet_user, any leading or trailing whitespace will be removed.

The to_string() method is used to convert a string slice (&str) to an owned String.This conversion is necessary because greet_user expects a &str parameter, and to_string() creates a new Stringinstance from the trimmed input

Now the final output will look like

so that's all for this challenge , Thank You

For a more detailed explanation, you can watch my YouTube video.

GitHub - Link

A cliché rusty project built using rust

Joel Jaison — Tue, 20 Feb 2024 15:50:09 +0000

So, it's been a week, and I have been relearning Rust. Hopefully, without falling into many pitfalls, I was able to cover the basics of Rust in a detailed and explanatory manner.

By incorporating fundamental concepts such as enums, structs, tuples, vectors, loops, strings, types, match, etc., I have successfully created a simple yet functional project—a task manager designed to operate in the command line interface (CMD).

The project building was fun, mainly because there weren't many confusing parts or head-scratching doubts or errors that I fell into. I believe it's mainly because of having a good foundation to stand upon. I have recorded the live coding of the project as a document.

The main aim of this blog is to keep track of my Rust progress, so that later when I look back, I can see the steps I have climbed in my learning journey. Rust is a tough language, but dedicating appropriate time and having good resources to learn will always be beneficial.

And a simple piece of advice to fellow readers: if you learn anything, always try to build something with that knowledge, even if it's small—no problem. It doesn't have to be perfect, bug-free, or very attractive. Just build; it will boost your confidence along with your motivation to code. Try to document the journey, take up challenges one by one. Likewise, you could build a strong foundation, and that foundation will support you forever, even if whatever AI comes to take over.

So, thank you, and have a great day! Don't forget to write at least a line of code today 😂. Below, I will provide the link to the live coding of the project, along with the GitHub repository link. If you have time and interest, do check it out.

Github repo - Link

KeyMomentum: My First TypeScript Project

Joel Jaison — Wed, 13 Dec 2023 11:32:22 +0000

Last week, I enrolled in a TypeScript course. While learning, I got excited and decided to build a project using it as well. I challenged myself to learn and build a medium-complexity project within just 7 days.

My Master Plan

For the first three days, I focused solely on understanding TypeScript. In my free time during those days, I explored project ideas and settled on building a type speed testing app. I created a basic outline in Figma, more like a rough sketch than a full design.

The remaining 4 days were dedicated to building the project.

DAY-4

The real challenge began on the first day of development. I chose Svelte as my framework but encountered difficulties with even basic tasks like managing simple states. My lack of experience in this framework likely contributed to these obstacles. Every line I wrote was instantly highlighted in red, highlighting my errors. This constant push of negativity led to discouragement, exhaustion, and ultimately, abandonment of the project.

DAY-5

The next day, fuelled by renewed determination, I took a bold step. Before even the thought of brushing my teeth crossed my mind, I deleted the Svelte project folder. In its place, I began a new project in React and Tailwind, embarking on a fresh path with renewed optimism.

Despite the initial comfort in setting up the UI with React and Tailwind, my progress soon encountered roadblocks again. The logic for matching the user's input against the provided sentence proved troublesome, deviating from my initial vision. Another hurdle arose with TypeScript, as the application's structure and complexities demanded a different understanding than the fundamentals I had learned. Specifically, the lack of experience with states, complex interfaces, and null checks presented a significant challenge.

Determined to overcome these obstacles, I searched for similar projects on GitHub. Though I found a JavaScript project, it provided valuable insights into the logic and function structure. This knowledge served as a springboard for recreating the logic in TypeScript, incorporating my modifications, and tailoring it to my specific needs. This process demanded long hours, often exceeding 10-11 hours, significantly impacting my sleep cycle.

DAY-6

On the third day, I was super tired, but I finally understood the logic from the day before. I was able to make a simple working prototype with a basic UI, even though it wasn't fancy and everything was in one file. By the end of the day, I was so happy! I can't wait to show you how simple it looked back then.

That same day, fueled by my accomplishment, I took the extra step of crafting a logo, christening the project with a name, and establishing a dedicated repository on GitHub. This marked a significant milestone, solidifying the project's existence and paving the way for further development.

Day-7

On the final day, while I knew I couldn't complete all the desired features, my goal was to build a working prototype with basic functionality. This included setting a timer range, adjusting difficulty levels, implementing proper state and context management, and creating a minimalist UI. I started from scratch in React, referencing my previous version and working tirelessly until midnight. I realized that focusing on specific dates was only adding stress, so I shifted my mindset to continuous learning and problem-solving through project development. Setting up a solid foundation was my main objective, and it took an additional two days to achieve the current state. While KeyMomentum may appear simple now, it represents a significant accomplishment and a stepping stone for future enhancements.

I'm so proud to share my experience with you. I encourage you to learn by doing and show the world what you've learned by building or solving something real. Don't just show off certificates or badges! When you face challenges, don't give up. Roadblocks are signs you're on the right path to progress. If you don't face any, it means you're not growing. I know I made a mistake when I gave up on Svelte. Now I know I need to improve there. When we meet next time, I'll be coming back with an amazing new project in Svelte using the latest features. See you soon!

the Keymometum project gallery and lnk to the porject will be provided below

githublink

Mastering Conditional Rendering and Lists in Svelte

Joel Jaison — Mon, 25 Sep 2023 15:23:03 +0000

In the previous assignment, you had the task of creating a counter and exploring the functionality of components in Svelte. Today, our focus will shift towards mastering the art of conditionally rendering components and efficiently rendering lists using loops.

if you haven't read part 1 and 2 check

Conditional Rendering in Svelte

Conditional rendering is a crucial concept in web development, allowing us to display different content based on certain conditions. In Svelte, this is quite straightforward thanks to its clean and intuitive syntax.

Basic Conditional Rendering

Let's start with the basics. To conditionally render content in Svelte, we use the {#if} and {/if} blocks. Here's an example:

<script>
  let showContent = true;
</script>

{#if showContent}
  <p>This content will only display if showContent is true.</p>
{/if}

In this code, the paragraph will be shown only if showContent is true.

Conditional Rendering with `else`

Sometimes, you want to display one thing when a condition is true and something else when it's false. Svelte allows you to do this with the {:else} block:

<script>
  let loggedIn = true;
</script>

{#if loggedIn}
  <p>Welcome, user!</p>
{:else}
  <p>Please log in.</p>
{/if}

Here, if loggedIn is true, it will display the welcome message, and if loggedIn is false, it will display the login prompt.

Conditional Rendering with Ternary Operator

If you have a simple conditional, you can use a ternary operator for a concise syntax:

<script>
  let isLoggedIn = false;
</script>

{isLoggedIn ? (
  <p>Welcome, user!</p>
) : (
  <p>Please log in.</p>
)}

This code achieves the same result as the previous example but with a more compact format.

Ticket Pricing for the Fun Ride

Now, let's apply our knowledge of conditional rendering to a real-world scenario: pricing tickets for a fun ride. Our pricing scheme is as follows:

Children below 10 years: $5
Children between 10 and 20 years: $10
Teenagers and young adults up to 60 years: $15

Children below 5 years and adults above 60 years: Not allowed to enter.

<script>
    let age = 0; 
    let ticketPrice;
    let showTicket = false;
    let name = "";

    function calculateTicketPrice() {
        if (age < 5 || age > 60) {
            ticketPrice = null; 
        } else if (age < 10) {
            ticketPrice = 5;
        } else if (age >= 10 && age <= 20) {
            ticketPrice = 10;
        } else if (age <= 60) {
            ticketPrice = 15;
        }

        return ticketPrice;
    }
</script>

<div class="container mx-auto p-4">
    <h1 class="text-3xl font-semibold mb-4 underline">Fun Ride Ticket Pricing</h1>

    <div class="mb-4">
        <label for="name" class="block text-gray-700 text-xl p-2">Enter your name:</label>
        <input type="text" id="name" name="name" placeholder="Name" class="border rounded-lg p-4 w-50" bind:value={name} />
        <label for="age" class="block text-gray-700 text-xl p-2">Enter your age:</label>
        <input type="number" id="age" name="age" class="border rounded-lg p-4 w-24 mr-4" bind:value={age} />
        <button on:click={() => showTicket = true} class="bg-blue-500 hover:bg-blue-600 text-white py-2 px-4 rounded-full transition duration-300 ease-in-out transform hover:scale-105 hover:shadow-md ">Get Ticket</button>
    </div>
    {#if showTicket}
        {#if age > 0}
            {#if ticketPrice !== null}
                <div class=" bg-yellow-300 w-52 hover:bg-yellow-400 border-2 border-yellow-500 rounded-lg p-4 shadow-lg transform scale-105 transition duration-300 ease-in-out ">
                    <p class="text-2xl font-bold mb-2">Ticket Details</p>
                    <p class="text-blue-500">Name: {name}</p>
                    <p class="text-blue-500">Date: {new Date().toLocaleDateString()}</p>
                    <p class="text-green-600">Ticket Price: ${calculateTicketPrice()}</p>
                    <p class="text-purple-500 mt-2 hover:text-purple-700 cursor-pointer transition duration-300 ease-in-out">Enjoy the ride!</p>
                </div>
            {:else}
                <p class="text-red-500 text-xl mt-4">Sorry, you are not allowed to enter the fun ride.</p>
            {/if}
        {/if}
    {/if}
</div>

In this example, we calculate the ticket price based on the age variable using conditional statements. If the age falls within one of the specified ranges, it displays the ticket price; otherwise, it informs the user that they are not allowed to enter the fun ride.

Conditional rendering in Svelte makes it easy to create dynamic and responsive interfaces, like our ticket pricing system for the fun ride.🎢🎉

Rendering Lists in Svelte

Now, let's see another aspect of Svelte: rendering lists using the {#each} block.

Using `{#each}` to Render Lists

Svelte provides a convenient way to iterate over arrays and render lists of elements using the {#each} block. Here's an example:

<script>
  let fruits = ['Apple', 'Banana', 'Cherry'];
</script>

<ul class="list-disc pl-4">
  {#each fruits as fruit }
    <li class="text-green-600">{fruit}</li>
  {/each}
</ul>

In this code:

We have an array of fruits.
We use {#each} to iterate over the fruits array and render a list item (<li>) for each fruit.
We also display the index of each fruit in the array.

Using Keys in Lists

When rendering lists in Svelte, it's crucial to understand the significance of using keys. Keys are unique identifiers assigned to each item in the list, helping Svelte efficiently update and manipulate the DOM when the list changes.

Why Use Keys?

Imagine you have a list of items displayed on a web page. This list can change dynamically due to various actions, such as adding or removing items. When a change occurs, Svelte needs to update the DOM to reflect the new state of the list.

Without keys, Svelte might struggle to differentiate between items in the old list and items in the new list. This can lead to unnecessary re-rendering of elements, affecting performance and potentially causing unintended side effects.

Let's illustrate the importance of keys with an example:
```
<script>
  let fruits = ['Apple', 'Banana', 'Cherry'];
</script>

<ul class="list-disc pl-4">
  {#each fruits as fruit (fruitIndex)}
    <li class="text-green-600">{fruit} (Index: {fruitIndex})</li>
  {/each}
</ul>
```
In this code, we have a list of fruits. Each item in the list is rendered as an <li> element within an unordered list. The index of each fruit is also displayed.

Now, let's say we want to add a new fruit to our list:
```
<script>
  let fruits = ['Apple', 'Banana', 'Cherry', 'Date']; 
</script>
```
Without keys, when Svelte updates the list, it might re-render all elements, even though the existing items haven't changed. This inefficiency can lead to performance issues, especially with larger lists.

By using keys, we provide Svelte with a unique identifier for each item. When we add the 'Date' fruit with a key, Svelte knows precisely which item has been added and can efficiently update the DOM without affecting other elements.

Now a note - [Svelte's reactivity system ensures that when you add or remove elements from an array, your UI stays in sync with the data, providing a seamless and responsive user experience.]

example :

Adding and Removing Elements of an Array

<script>
  let products = [
    { id: 1, name: 'Product A', price: 10 },
    { id: 2, name: 'Product B', price: 20 },
    { id: 3, name: 'Product C', price: 30 }
  ];

  let newProduct = {
    id: null,
    name: '',
    price: 0
  };

  function addProduct() {
    if (newProduct.name && newProduct.price > 0) {
      newProduct.id = products.length + 1;
      products = [...products, { ...newProduct }];
      newProduct = {
        id: null,
        name: '',
        price: 0
      }; 
    }
  }

  function removeProduct(id) {
    products = products.filter(product => product.id !== id);
  }
</script>

<div class="mx-auto p-4">
  <input type="text" bind:value={newProduct.name} placeholder="Product Name" class="border rounded-lg p-2" />
  <input type="number" bind:value={newProduct.price} placeholder="Price" class="border rounded-lg p-2" />
  <button on:click={addProduct} class="bg-blue-500 hover:bg-blue-600 text-white py-2 px-4 rounded-full transition duration-300 ease-in-out transform hover:scale-105 hover:shadow-md">Add Product</button>
</div>

<ul class="mt-4">
  {#each products as product (product.id)}
    <li key={product.id} class="bg-yellow-100 p-4 mb-2 rounded-lg shadow-md flex justify-between items-center">
      <div>
        <p class="text-xl font-semibold">{product.name}</p>
        <p class="text-gray-600">${product.price}</p>
      </div>
      <button on:click={() => removeProduct(product.id)} class="bg-red-500 hover:bg-red-600 text-white py-2 px-4 rounded-full transition duration-300 ease-in-out transform hover:scale-105 hover:shadow-md">Remove</button>
    </li>
  {/each}
 /ul>

We've laid the foundation of Svelte's basics, but this is just the beginning. The world of Svelte is full of possibilities waiting to be explored.

For the assignment, take the fun ride we built earlier and expand it. Add more exciting rides using lists and create separate tickets for each ride. This will not only solidify your understanding but also enhance your web development skills.

Remember, learning is a journey. If you face any challenges or need clarification, don't hesitate to reach out via email or comments. Your path to mastering Svelte has just begun, and the adventures ahead are limitless! 🎢🚀.

Thank you❤️

Unlocking the Power of Svelte: Mastering Bindings

Joel Jaison — Sun, 24 Sep 2023 03:21:19 +0000

So, previously, we stopped after just making that demo skeleton. Your folder structure looks something like this:

Okay, let's set up our working environment by creating some folders. Follow these steps:

Inside the lib directory, create a new folder named components.
Within the components folder, create a new file, and name it binding.svelte.

Now, your project structure should look like this:

 lib/
  - components/
    - binding.svelte

We've created a dedicated folder for our components, and we'll be working with the binding.svelte file shortly.

Import binding.svelte into +page.svelte:

Open your src/routes/+page.svelte file, and add the following import statement at the top:
```
<script>
  import Binding from '$lib/components/binding.svelte';
</script>
```
This imports the binding.svelte component into your +page.svelte file, allowing you to use it.

Add Content to binding.svelte:

Now, navigate to your binding.svelte file located in lib/components/. Add the following content as a sample:

<script>
  // You can add script logic here if needed
</script>

<style>
  /* You can apply styles specific to this component here */
</style>

<h2>This is a Sample Heading in binding.svelte</h2>

<p>
  Welcome to the world of Svelte bindings! You can add more content and functionality to this component as you explore Svelte's capabilities.
</p>

Remember, in Svelte, .svelte files can contain both script logic and styles within the same file. This component now has a sample heading and paragraph. and in here we will not be using much custom styles

With these changes, your binding.svelte component is ready with some content, and you've imported it into your +page.svelte file.

Now that you've made those changes, take a moment to appreciate the magic of Svelte. The content you added to binding.svelte is static.But what exactly is making it so?

Let's dive into the exciting world of binding in Svelte.

Understanding Binding in Svelte

Binding is a core concept in Svelte that allows you to create dynamic and interactive web applications effortlessly. At its heart, binding establishes a connection between your component's data and the user interface (UI). This connection ensures that any changes to your data are automatically reflected in the UI, and vice versa.

In other words, when you update a variable, input field, or any other UI element in a bound Svelte component, the corresponding data is updated, and the change is immediately reflected everywhere it's used in your app. No need to write complex event listeners or manually update the DOM – Svelte takes care of it for you.

Types of Bindings

Svelte offers various types of bindings, each designed for different use cases:

Two-way binding: This binds a variable to an input element, allowing changes in the input to update the variable and vice versa.
One-way binding: Also known as "binding," this connects a variable to an element's property, such as text content or attribute values, ensuring that changes in the variable are reflected in the UI.
Group binding: Useful for managing multiple related input elements, this binds a group of inputs to an array or object, simplifying data handling.
Event binding: This lets you respond to user interactions by binding an event handler function to an element, like a button click or mouseover event.

Two-way binding

let's look a example

update our binding.svelte with this code

<script>
    let inputValue = ''; // Initialize an empty variable to store the input value
  </script>

  <div class="mt-4">
    <input
      type="text"
      bind:value={inputValue}
      class="border rounded p-2 w-50"
      placeholder="Enter your name"
    />
  </div>

  <p class="mt-2">Hii,👋  {inputValue}</p>

In this example:

We declare a variable called inputValue in the Svelte script section.
We use the bind:value directive on the input element. This directive establishes a two-way binding between the input element and the inputValue variable. It means that any changes made to the input element will automatically update the inputValue, and vice versa.
Below the input element, we display the value of inputValue inside a paragraph (<p>) element. This demonstrates that the inputValue variable is reactive, and any changes in the input element are immediately reflected in the UI.

When you type in the input field, you'll see that the text below it updates in real-time to reflect the changes. This is the essence of two-way binding in Svelte, where data and the UI stay in sync without the need for manual event handling.

one-way binding


<script>
    let inputValue = ''; // Initialize an empty variable to store the input value
  </script>

  <div class="mt-4">
    <input
      type="text"
      value={inputValue}
      on:input={(event) => (inputValue = event.target.value)}
      class="border rounded p-2 w-50"
      placeholder="Enter your name"
    />
  </div>

  <p class="mt-2">Hii,👋  {inputValue}</p>

In this example:

We declare a variable called inputValue in the Svelte script section.
We use the value property on the input element to bind it to the inputValue variable. This establishes a one-way binding, where the input field displays the value of inputValue.
We add an on:input event handler to the input element. This event handler listens for changes in the input field. When the input field value changes, it updates the inputValue variable with the new value.
Below the input element, we display the value of inputValue inside a paragraph (<p>) element. This demonstrates that changes in the input field are reflected in the inputValue variable and, consequently, in the UI.

In this one-way binding example, changes in the input field update the variable (inputValue), but changes made directly to the variable (inputValue) do not update the input field. This is the essence of one-way binding, where data flows from the variable to the UI.

next is

group binding

group binding in Svelte that's interactive and dynamic. In this example, we'll create a list of items, and users can add, remove, and edit items. The items will be bound to an array using group binding, simplifying data handling:

Event binding

Event binding in Svelte allows you to respond to user interactions, such as button clicks, mouse events, and keyboard events. Let's explore event binding with some examples and code.

In this example, we'll demonstrate how to bind a button click event to a function in Svelte.

<script>
  function handleClick() {
    alert('Button clicked!');
  }
</script>

<button on:click={handleClick}>Click Me</button>

In this code:

We define a JavaScript function handleClick that displays an alert when called.
The on:click directive binds the handleClick function to the button's click event. When the button is clicked, the handleClick function is executed, triggering the alert.

Here's another example of binding an input field's change event to dynamically update a variable in Svelte.

<script>
  let inputValue = ''; // Initialize an empty variable to store the input value
  function handleChange(event) {
    inputValue = event.target.value;
  }
</script>

<input type="text" on:input={handleChange} placeholder="Type something..." />

<p>You typed: {inputValue}</p>

In this code:

We declare a variable inputValue to store the input field's value.
The on:input directive binds the handleChange function to the input field's change event. Whenever the user types something in the input field, the handleChange function is called, updating the inputValue variable.
We display the value of inputValue below the input field, showing real-time updates as the user types.

Now let's see how to handle a mouseover event on an element:

<script>
  function handleMouseover() {
    alert('Mouseover detected!');
  }
</script>

<div on:mouseover={handleMouseover} style="width: 100px; height: 100px; background-color: lightblue;">
  Hover over me
</div>

In this code:

We define a JavaScript function handleMouseover that displays an alert when the mouseover event occurs.
The on:mouseover directive binds the handleMouseover function to the mouseover event of the <div> element. When the mouse cursor is over the element, the handleMouseover function is called, triggering the alert.

These are just a few examples of event binding in Svelte. You can bind various events to different elements and perform actions based on user interactions, making your Svelte applications highly interactive and responsive.

we will learn much about it will going through coming topics

Binding HTML Content in Svelte

In Svelte, you can dynamically bind and render HTML content within your components. This feature is incredibly useful when you want to display rich, dynamic content that includes HTML markup. Let's dive right into it with a hands-on example.

The {@html ...} Syntax

To bind and render HTML content in Svelte, you'll use the {@html ...} syntax. This special syntax allows you to inject raw HTML content directly into your templates.

Example: Displaying Dynamic HTML Content

Let's say you have a use case where you want to display user-generated HTML content. Here's how you can do it:

htmlCopy code<script>
  let dynamicHTML = '<p><strong>This is bold text</strong> and <em>this is italicized text</em></p>';
</script>

<div>{@html dynamicHTML}</div>

In this example:

We have a variable dynamicHTML that contains an HTML string.
We use the {@html ...} syntax inside a <div> element to render the HTML content dynamically.
The content of dynamicHTML can change based on user interactions, data from an API, or any other source.

When you run this code, the HTML content stored in dynamicHTML will be rendered as part of your web page. This is a powerful way to incorporate dynamic and user-generated content into your Svelte applications.

Example: Updating HTML Content

You can also update the HTML content dynamically. Let's add a button to update the HTML content when clicked:

<script>
  let dynamicHTML = '<p>This is the initial HTML content</p>';

  function updateHTML() {
    dynamicHTML = '<p>Now the HTML content has been updated!</p>';
  }
</script>

<div>{@html dynamicHTML}</div>

<button on:click={updateHTML}>Update HTML</button>

In this example:

We have initial HTML content in the dynamicHTML variable.
There's a button with an on:click handler that triggers the updateHTML function when clicked.
Inside the updateHTML function, we change the value of dynamicHTML to update the HTML content.

Now, when you click the "Update HTML" button, the HTML content displayed on the page will change dynamically.

Assignment #2: Create an Interactive Counter

Objective: Build a simple web page that features a counter. You'll use event binding to increment and decrement the counter's value based on user interactions.

Instructions:

Set up a new Svelte project if you haven't already. You can use the Svelte project template or an existing project.
Create a component named Counter.svelte. This component will represent the counter and handle its functionality.
Inside Counter.svelte, declare a variable named count and initialize it to 0. This variable will store the current count value.
Create two buttons in your component: one for incrementing the count and one for decrementing it. Bind the appropriate event handlers to these buttons.
Implement event binding to increment and decrement the count variable when the corresponding buttons are clicked. Make sure the counter value is updated accordingly.
Display the current count value on your web page.
Style your counter component to make it visually appealing. You can use CSS or Tailwind CSS if you're familiar with it.
Create an instance of the Counter component in your main application file (+page.svelte) and render it on your web page.
Test your counter by interacting with the increment and decrement buttons. Ensure that the count updates correctly and that the UI reflects the changes.

Bonus (Optional):

Add validation to prevent the count from going below zero (i.e., the counter should not go negative).
Implement additional features, such as a reset button to set the count back to zero.
Explore other events and interactions you can add to your counter, such as mouseover effects or animations.

In the next part of our Svelte tutorial series, we'll continue our journey by exploring even more essential concepts. Get ready to dive into:

Conditional Rendering: Learn how to conditionally display or hide elements based on certain conditions, making your components adaptable and flexible.
Lists and Iteration: Discover how to work with lists of data and iterate over them to generate dynamic content, such as lists of items or dynamic tables.

These topics are fundamental for building complex and dynamic web applications with Svelte. So, stay tuned for the next episode, where we'll continue our exploration of Svelte's capabilities.

Happy coding!