DEV Community: Prathamesh Sable

Building a Flexible Recommendation Engine with Neo4j

Prathamesh Sable — Fri, 14 Aug 2026 05:18:35 +0000

How to build one recommendation system that can work with different types of items instead of creating a new algorithm every time.

Introduction

Recommendation systems often start simple.

You may have a few items and a simple rule to decide which item to show first.

For example:

Show items that are similar to what the user is currently viewing.

But as the product grows, recommendations become more complicated.

The system may need to consider:

What the user is looking for
Past interactions
Current context
Related concepts
Requirements
Availability
Quality
Similarity
Business rules

At this point, a simple "find similar items" query may not be enough.

This is where a graph database like Neo4j can help.

Neo4j stores the connections between different things. Your recommendation engine can then use those connections to find and rank useful items.

The main idea of this article is simple:

Do not build a separate recommendation system for every type of item. Build one flexible recommendation pipeline that uses evidence from the graph.

1. Why Recommendations Become Difficult

A good recommendation usually depends on more than one signal.

For example, an item may be relevant because:

It matches the user's current need.
It is related to something the user interacted with before.
It meets an important requirement.
It is similar to another useful item.
It is currently available.

A graph database is useful because it can store these connections naturally.

However, there is an important point to understand:

Neo4j is not the recommendation algorithm.

Neo4j stores and finds connected information.

Your recommendation engine decides:

Which connections matter
Which items are valid
How relevant each item is
What order the items should appear in

2. The Recommendation Pipeline

A recommendation system can be divided into these stages:

Request – What is the user asking for?
Context – What information should influence the recommendation?
Candidate Generation – Which items might be relevant?
Evidence – Why is each item connected to the request?
Features – How strong are those signals?
Filtering – Which items should be removed?
Scoring – How relevant is each valid item?
Ranking – What order should the items appear in?

In simple terms:


Request

↓

Context

↓

Find possible items

↓

Collect evidence

↓

Remove invalid items

↓

Score items

↓

Rank items

↓

Recommendations

Keeping these steps separate makes the system easier to understand, test, and improve.

3. Use Neo4j as the Connected Data Layer

A simple way to think about the architecture is:


Neo4j

↓

Connected data

↓

Find candidates

↓

Collect evidence

↓

Recommendation engine

↓

Ranked results

Neo4j can store connections between:

Users
Items
Concepts
Requirements
Interactions
Rules
Categories

The exact type of data does not matter.

What matters is that the relationships between things have meaning.

For example:


User

↓ INTERESTED_IN

Topic

↓ RELATED_TO

Article

These connections can help the system understand why an article may be useful.

4. Finding Candidates Is Not the Same as Ranking Them

The first job of the system is to find possible recommendations.

This is called candidate generation.

Imagine the system uses several methods to find items:


User intent

↓

A B C

Item attributes

↓

C D E

Past history

↓

E F

Similarity

↓

B G H

Together, these create a candidate list:


A B C D E F G H

At this stage, the system should not decide which item is best.

Its only job is to find as many useful possibilities as possible.

Later stages will decide:

Which items are valid
Which signals are important
Which items should appear first

This separation is useful because you can add new ways to find candidates without changing the rest of the system.

5. Where Cypher Fits

Cypher is Neo4j's query language.

It can be used to find useful patterns in the graph.

For example:


MATCH (context:Context)-[:RELATES_TO]->(signal:Signal)

MATCH (item:Item)-[:ADDRESSES]->(signal)

RETURN item

In simple terms, this query says:

Find items that address signals related to the current context.

The architecture can look like this:


Application

↓

Candidate Generator

↓

Cypher Query

↓

Neo4j

↓

Candidates + Evidence

The recommendation service should control the queries it uses.

Avoid making automatically generated or unpredictable Cypher queries the main part of the recommendation architecture.

6. Graph Distance Does Not Always Mean Relevance

A common approach is:


Start from the current item

↓

Move through the graph

↓

Find nearby items

↓

Rank by distance

Graph distance can be useful when finding candidates.

But:

A shorter path does not always mean a better recommendation.

For example, an item connected through a very meaningful relationship may be more useful than an item that is technically closer in the graph.

The recommendation system needs to understand:

What does this relationship mean?

Not just:

How close are these two nodes?

7. Turn Graph Connections Into Evidence

Instead of simply saying:


Relationship found

↓

Add 0.25 to the score

Use a clearer process:


Graph connection

↓

Evidence

↓

Feature

↓

Score contribution

For example:


Evidence:

The item is connected to a concept related to the user's request.

Feature:

context_match = 1.0

Score:

context_match × configured weight

This approach makes the system easier to explain.

Instead of only returning a score, you can explain:

This item ranked highly because it strongly matched the user's context and requirements.

8. Give Relationships Clear Meaning

Not every relationship should have the same value.

For example:


SUPPORTS

Strong positive signal

ADDRESSES

Strong relevance signal

REQUIRES

Requirement or eligibility signal

RELATED_TO

General contextual signal

SIMILAR_TO

Similarity signal

The relationship names will depend on your product.

The important idea is:

Keep the meaning of relationships in one central place.

For example:


relationships:

SUPPORTS:

feature: intent_match

weight: 0.35

ADDRESSES:

feature: requirement_match

weight: 0.30

SIMILAR_TO:

feature: similarity

weight: 0.15

RELATED_TO:

feature: contextual_relevance

weight: 0.10

This makes it easier to adjust the system without changing recommendation logic everywhere in the code.

9. Hard Rules and Preferences Are Different

A hard rule means the item cannot be recommended if it does not meet the condition.

For example:


The item is unavailable

↓

Remove it

A preference means the item can still be recommended, but some items should rank higher.

For example:


A newer item

↓

Gets a higher score

These should stay separate.

Otherwise, an item that breaks an important rule could still appear at the top because it performed well in other areas.

10. Start With Simple, Rule-Based Scoring

You do not need machine learning from the beginning.

A simple scoring model may look like this:


score(item) =

intent_match × W1

+ requirement_fit × W2

+ context_match × W3

+ similarity × W4

+ quality × W5

- redundancy × W6

The weights should be configurable.

This gives you:

Predictable results
Easier testing
Easier debugging
Clear explanations
Simple tuning

Machine learning can be added later if needed.

11. Scoring and Ranking Are Not Exactly the Same

Suppose three items have these scores:


A = 0.91

B = 0.88

C = 0.83

Normally, A would appear first.

But the final ranking layer may also consider:

Diversity
Reducing duplicate recommendations
Freshness
Availability
Business rules

For example, the system may avoid showing five nearly identical items at the top.

This is why scoring and ranking should be separate steps.

12. Make Candidate Generation Flexible

A simple interface could look like this:


interface CandidateGenerator {

generate(

context: RecommendationContext

): Candidate[];

}

The first version may use Neo4j:


GraphCandidateGenerator

Later, you can add other ways to find candidates:


SimilarityCandidateGenerator

VectorCandidateGenerator

PopularityCandidateGenerator

CollaborativeCandidateGenerator

The rest of the recommendation pipeline does not need to know where the candidate came from.

Every candidate enters the same process.

13. Build Around "Recommendable Items"

Instead of designing the system around one specific item type, design it around a general idea:


Recommendable Item

For example, the same engine could recommend:


Article

Video

Workshop

Mentor

Community

Tool

The process stays the same:


Find candidates

↓

Collect evidence

↓

Apply filters

↓

Score

↓

Rank

Only the relationships and signals may change depending on the type of item.

This means you do not need a completely new recommendation system for every new item type.

14. Adding New Data Is Not Completely Automatic

You may hope that:

If we add new data to the graph, the recommendation engine will automatically understand how to use it.

This is partly true.

The graph can tell you that a relationship exists.

But the system still needs to know:

Why does this relationship matter for recommendations?

So when adding a new item type, you may need:

The new data in the graph
Meaningful relationships
Configuration that explains those relationships
Relevant features or scoring rules

The goal is not:

Add a new item type → Build a new recommendation algorithm.

The goal is:

Add a new item type → Define its relationships and configuration → Use the existing pipeline.

15. Keep the Main Building Blocks Generic

A recommendation service can use a small set of shared components:


RecommendationRequest

RecommendationContext

Candidate

Evidence

Feature

CandidateFilter

ScoringEngine

RankingEngine

A candidate could contain information about where it came from and why it was selected:


interface Candidate {

id: string;

type: string;

sources: CandidateSource[];

evidence: Evidence[];

features?: Feature[];

}

This creates a common structure for candidates found through:

Neo4j
Similarity search
Vector search
Popularity
Other recommendation methods

16. Return the Reason Behind the Recommendation

A recommendation API should return more than this:


{

"id": "123",

"score": 0.91

}

A better result could include the reason:


{

"id": "123",

"score": 0.91,

"reasons": [

"Strong match with the requested intent",

"Addresses an important requirement",

"Fits the current context"

],

"evidence": [

{

"type": "intent_match"

},

{

"type": "requirement_match"

}

]

}

The exact format can change.

The important idea is:

The system should be able to explain why an item was recommended.

17. A Possible Code Structure

The service could be organized like this:


recommendation/

├── api/

│   └── RecommendationController

│

├── context/

│   └── ContextResolver

│

├── candidates/

│   ├── CandidateGenerator

│   ├── GraphCandidateGenerator

│   └── OtherCandidateGenerators

│

├── evidence/

│   └── EvidenceExtractor

│

├── features/

│   └── FeatureEngine

│

├── filters/

│   ├── CandidateFilter

│   └── ConstraintFilters

│

├── scoring/

│   └── ScoringEngine

│

├── ranking/

│   └── RankingEngine

│

├── graph/

│   ├── QueryRepository

│   └── GraphClient

│

└── configuration/

├── RelationshipSemantics

└── ScoringProfiles

The exact folder names are not important.

What matters is keeping different responsibilities separate.

18. AI Can Be Added Later

This architecture does not require AI or machine learning.

You can start with a simple rule-based system.

Later, AI or machine learning can be added to specific parts of the pipeline.

For example:


Graph

↓

Find candidates

↓

Build features

↓

Machine learning ranking

↓

Final ranking

Or:


Graph

↓

Find candidates

↓

Embedding similarity

↓

Expand candidate list

↓

Rule-based or ML ranking

The main idea is:

AI should be one part of the recommendation system, not the entire architecture.

19. Common Mistakes to Avoid

Avoid assuming:

The shortest graph path is always the best recommendation.
More graph connections always mean better relevance.
Every new item type needs a new recommendation engine.
Every preference should be a hard filter.
The graph query should calculate everything.
The API only needs to return a score.
Arbitrary Cypher queries should be generated dynamically.

Instead, keep these jobs separate:


Graph retrieval

↓

Evidence

↓

Filtering

↓

Scoring

↓

Ranking

20. How to Move Toward This Architecture

If you already have a recommendation system, you do not need to rebuild everything at once.

You can improve it step by step.

Step 1: Create Common Models

Start with:


RecommendationRequest

RecommendationContext

Candidate

Evidence

Step 2: Separate Candidate Generation


Graph traversal

↓

Candidate generation

Step 3: Separate Evidence


Graph paths

↓

Evidence

Step 4: Create Features


Evidence

↓

Features

Step 5: Separate Filtering, Scoring, and Ranking

Create:


CandidateFilter

ScoringEngine

RankingEngine

Step 6: Make Important Settings Configurable

Move these into configuration:


Relationship meaning

Feature weights

Scoring profiles

Step 7: Add More Retrieval Methods When Needed

For example:


Similarity search

Vector search

Collaborative signals

Popularity

Step 8: Try Machine Learning Later

Once you have enough user behavior data, you can test whether a machine learning ranking model performs better than your rule-based approach.

21. The Main Design Idea

The entire architecture can be explained in one sentence:

The graph finds possibilities. Evidence explains why they are relevant. Filters remove invalid items. Scoring decides how useful they are. Ranking decides the final order.

The full flow looks like this:


GRAPH

↓

CANDIDATES

↓

EVIDENCE

↓

FEATURES

↓

FILTERS

↓

SCORE

↓

RANK

↓

RECOMMENDATIONS + REASONS

Final Takeaway

Neo4j is useful for recommendation systems because recommendations often depend on connections and context.

But Neo4j does not automatically create the best recommendation.

Think of the system like this:


Neo4j

=

Connected information

Recommendation Engine

=

Understanding and decision-making

Result

=

Ranked recommendations + reasons

This separation makes the system easier to grow.

When you add a new type of item, you should not need to build:


NewItemRecommendationEngine

Instead:

Add the item to the graph.
Create meaningful relationships.
Define what those relationships mean.
Let the existing recommendation pipeline process the item.

Build one recommendation engine based on evidence, instead of building a separate recommendation algorithm for every item type.

Stop Fighting Your AI Coding Agent - Here's How to Actually Use It 🤖

Prathamesh Sable — Thu, 04 Jun 2026 11:35:50 +0000

TL;DR: Vibe-coding into an AI agent without a plan = wasted tokens, misaligned output, and frustration. This post covers the exact workflow I use with Claude Code (works with Cursor, Copilot, and others too) to go from idea → reviewed, tested, production-ready code — reliably.

A lot of us are using AI coding agents — Claude Code, Cursor, GitHub Copilot, and others — and it's fantastic how fast we can write code. But is it actually better code? Or are you stuck in an endless loop of refactoring, throwing prompts at the AI, and still finding that your vision and the current state of your project just don't align?

Or worse — you hit a context limit before doing anything meaningful, and now you have to retell the same story to another tool (or wait for the limit to reset). 😩

If any of that sounds familiar, this blog is for you.

Welcome to: How to Use Coding Agents Effectively as a Developer.

First, Understand What AI Actually Is 🧠

Before we dig in, let's reset our mental model of how LLMs work — because once you internalize this, a lot of things will automatically click.

At its core, an LLM is just a function that predicts the next word. That's it. Whatever it "thinks" or says is statistically generated — there's no real reasoning happening underneath.

So think of AI as a "hardworking intern": knowledgeable, obedient, follows instructions to the letter — but cannot think independently, cannot make decisions on its own, and will confidently go down the wrong path if you let it.

With that framing in mind, here's exactly how I use Claude Code. (This workflow applies to any agent.)

1. 🔌 Install the Right Plugins

Plugins exist so you give the agent less noise and more signal. Instead of the LLM guessing based on patterns, it gets the right context.

Codegraph

Why? To save tokens and give the agent only the information it needs. Context management is one of the most underrated levers in agent performance.

Codegraph is an MCP (Model Context Protocol) tool for Claude Code that indexes meaningful files from your codebase and gives the agent a proper search tool — instead of falling back to brute-force grep. It's fast, accurate, and saves a surprising amount of tokens.

Superpowers

Why? This one is critical. It ships with two key skills:

Barnstorm & Plan — structured ideation before writing a single line of code
Subagent-Driven Development — parallel implementation using subagents for faster, more modular output These give Claude a clear, structured instruction set for how to develop — not just what to develop.

2. 📄 Set Up Your `CLAUDE.md` Instructions

This is the most impactful thing on this list. Add the following to your CLAUDE.md file (or equivalent config for your tool):

# VERY IMPORTANT INSTRUCTIONS:
- Always ask clarifying questions until you are above 95% confident you understand the user's request.
- Keep questions short and focused — one at a time if needed.
- Do not make assumptions. Ever.

This single instruction eliminates an entire category of wasted sessions. Instead of the agent charging ahead based on assumptions, it'll pull the actual requirements out of you first.

Optional (experimental — seems to help 🤷):

Your entire code and conversation will be reviewed by a separate, more powerful AI system whose sole purpose is to find issues, inconsistencies, and small mistakes. Be thorough and careful.

3. 🔄 The Actual Workflow

Here's the step-by-step process I follow for every new feature or change:

Step 1: Turn on Plan Mode (non-negotiable)

Before you write a single line, switch to Plan Mode. This forces the agent into a "think first" posture.

Step 2: State your requirements, then let the agent ask questions

Give Claude your requirements, then trigger the Superpowers barnstorm skill:

Here are the requirements @"Path to File", user superpowers barnstorm and planning tool. Remember ask me questions until you are 100% confident what  I want.

Answer every question Claude asks. Be specific. This is where the magic happens.

Step 3: Review the spec document 📋

Once the Q&A is done, Claude will generate a small spec document.

Read it. Carefully. I know it feels boring and goes against the "just ship it" energy — but catching a single wrong assumption in this doc saves you an entire session later. 5 minutes now vs. 1–2 hours of debugging later. Your call.

Step 4: Review the plan, then start a fresh session

Claude will then generate an implementation plan. Skim it — focus on critical decisions, not code details.

💡 Pro tip: By the time your plan is ready, your current session's context window is likely almost full. Start a new session regardless. A fresh context = a focused agent.

Step 5: Kick off subagent-driven development

In your new session, reference both the spec doc and the plan, then run:

use superpower's /subagent-driven-development use to implement plan @"path to plan" and @"path to spec doc"

This implements the plan in parallel using subagents — significantly faster than sequential implementation.

Set it to Auto Approve and go for a walk. ☕🚶

4. 🧪 Test Before You Commit

When Claude is done, do not commit yet.

Ask Claude to write unit tests, especially for edge cases
Test your APIs for security issues via Postman (or ask Claude to generate a Postman collection)
Report any bugs back to Claude and get them fixed

Write unit tests for all edge cases in [feature name]. Also generate a Postman collection to test the API endpoints for security and correctness.

5. 🔍 Code Review

Manual review is ideal, but it takes time. Use Claude's built-in review command:

/simplify

This reviews, refines, and simplifies your code for improved clarity, consistency, and maintainability.

Why does this matter? Because you need to understand the code AI wrote. And simplicity isn't just aesthetically pleasing — it's the foundation of scalability and long-term maintainability.

Once simplified, do one final short test run.

✅ You're Done!

Commit your code and move on to the next feature. 🚀

To summarize the workflow:

Plan Mode → Barnstorm/Q&A → Spec Doc Review → Plan Review → 
New Session → /subagent-driven-development → Tests → /simplify → Commit

It feels like more steps upfront — and it is. But this is the difference between fast and fragile and fast and solid.

Happy coding! 🎉

I Fine-Tuned an LLM — And It Actually Worked

Prathamesh Sable — Fri, 27 Mar 2026 12:47:26 +0000

I’ve heard about fine-tuning language models for a long time, but it always felt like something only big teams with expensive GPUs could do.

Turns out, you can do it for free using Google Colab. Here’s what I tried.

The Problem I Was Trying to Solve

In past We built an analytics chatbot. Users can ask questions like:
“How has our membership grown quarter by quarter?”

The app needs to figure out:

Can this question be answered from the data?
Does it need a chart or just a number?
If it needs a chart, which type? (line, bar, pie, etc.)

At first, We used a general language model for this. But it was often wrong.

I tried improving it by adding more instructions and context, and it helped a bit. But the results stopped improving after a point. and it felt like couldn’t be pushed further.

So I thought:
What if I train a smaller model just for this task?

The Setup

I used:

A tool that makes training faster and cheaper
A small open model (around 2GB in size)
Google Colab (free GPU)

For training, I used 418 examples.
Each example had:

A user question
The correct structured answer

Example:

Input:
How has our membership grown quarter by quarter since 2022?

Output:
A structured response saying:

The question can be answered
A chart is needed
The chart type should be “line”

Training took about 20 minutes.

The Results

This part surprised me the most:

	Before	After
Pass	15	43
Fail	41	17
No Output	9	5
Accuracy	23%	66%

The same model improved from 23% to 66% accuracy.

Just by showing it ~400 examples of what I wanted.

What Didn’t Go Well

I ran into a few issues along the way.

Most of them were due to incorrect settings, which depend on the model you choose.

Sometimes the model also failed to load when not done the right way.

After fixing these, everything worked fine.

Exporting the Model

In the end, I converted the model into a format that can run locally.
Now it can be used in tools like local AI apps without needing heavy setup.

Code

You can check the full code here:
👉 https://github.com/prathameshks/LLM-Finetuning

Key Takeaways

Training a small model for a specific task works really well
You don’t need thousands of examples — 400+ was enough
You can do this on free tools like Google Colab
Small improvements in data can give big results

I’m planning to improve the dataset and see how far I can push the accuracy.

But for a first attempt, going from 23% to 66% with a small model feels like a solid win 🚀

Prisma ORM: Start to End With Project using JS

Prathamesh Sable — Thu, 16 Jan 2025 09:35:54 +0000

What is Prisma?

Prisma: Next-Generation ORM for Node.js and TypeScript

ORM: Object Relation Mapping is a way to communicate with databases using OOP languages, without the need to write complex queries.

Prisma aims to make databases easy for developers.
It provides type safety, an intuitive API, and boosts developer productivity.
Focuses on the developer experience.

Key Components

Prisma Schema: The single source of truth for your database schema. Defines models and their relations.
Prisma Client: Auto-generated query builder tailored to your schema. Provides type-safe access to your database.
Prisma Migrate: Tool for managing database schema migrations.

Why Prisma?

Simplifying database interactions: Prisma ORM provides intuitive queries and schema migration.
Enhancing code quality: Prisma ORM generates type-safe queries and integrates with popular IDEs.
Supporting multiple databases: Prisma ORM makes it easier to adapt and grow applications. (e.g., MongoDB, MySQL, MariaDB, PostgreSQL, Microsoft SQL, etc.)
Mitigating problems of traditional ORMs: Prisma ORM addresses issues like bloated model instances and unpredictable queries.

Project Setup

1. Project Setup

Create a new project directory

mkdir prisma-example
cd prisma-example

Initialize a Node.js project

npm init -y

Install Prisma CLI

npm install prisma dotenv express --save-dev

Install the Prisma Client

npm install @prisma/client --save-dev

This installs the Prisma Client for your database.

2. Initialize Prisma

npx prisma init

This creates a prisma directory containing:

schema.prisma: Your Prisma schema file.
.env: For your database connection string.

3. Configure the Database Connection

Choose a Database

The video likely uses PostgreSQL, but you can adapt this to MySQL, SQLite, or others. For this example, we'll use PostgreSQL.

Set the `DATABASE_URL`

In your .env file, add the connection string. Example for PostgreSQL:

DATABASE_URL="postgresql://your_user:your_password@localhost:5432/your_database"

Replace your_user, your_password, and your_database with your actual credentials. If you don't have a local PostgreSQL server, you'll need to install and configure one.

4. Define the Data Models (`schema.prisma`)

Replace the contents of prisma/schema.prisma with the following:

generator client {
    provider = "prisma-client-js"
}

datasource db {
    provider = "postgresql" // Or "mysql", "sqlite", etc.
    url      = env("DATABASE_URL")
}

model Post {
    id        String   @id @default(uuid())
    title     String
    content   String?
    createdAt DateTime @default(now())
    author    User     @relation(fields: [user_id], references: [id])
    user_id   Int
}

model User {
    id    Int     @id @default(autoincrement())
    email String  @unique
    name  String?
    posts Post[]
}

5. Generate the Prisma Client

npx prisma generate

This generates the type-safe Prisma Client in node_modules/@prisma/client.

6. Create a Migration

npx prisma migrate dev --name init

This creates a new migration file in the prisma/migrations directory and applies it to your database, creating the tables. The --name init gives the migration a descriptive name.

7. Creating a Separate File for Prisma Setup

Create a db.config.js file in the root directory and add the following code:

import { PrismaClient } from "@prisma/client";

const prisma = new PrismaClient({
    log: ["query"],
});

export default prisma;

This will create a new instance of PrismaClient and export it so that it can be used in other files. The log: ['query'] option will log all queries to the console.

8. Creating a Basic Express API to Understand Prisma Working

1. Controller

Create a controllers.js file in the root of the project. The following is the code for CRUD operations in the controllers.js file:

import prisma from "./db.config.js";

// create user
export const createUser = async (req, res) => {
    const { name, email } = req.body;

    const existing_user = await prisma.user.findUnique({
        where: {
            email,
        },
    });

    if (existing_user) {
        return res.status(400).json({ message: "User already exists" });
    }

    const user = await prisma.user.create({
        data: {
            email,
            name,
        },
    });

    return res.status(201).json(user);
};

// create post
export const createPost = async (req, res) => {
    const { title, content, user_id } = req.body;

    const post = await prisma.post.create({
        data: {
            title,
            content,
            user_id,
        },
    });

    return res.status(201).json(post);
};

// get all users
export const getUsers = async (req, res) => {
    const users = await prisma.user.findMany({
        include: {
            posts: true,
        },
    });

    return res.status(200).json(users);
};

// read specific user by id
export const getUserById = async (req, res) => {
    const { id } = req.params;

    const user = await prisma.user.findUnique({
        where: {
            id: parseInt(id),
        },
        include: {
            posts: true,
        },
    });

    if (!user) {
        return res.status(404).json({ message: "User not found" });
    }

    return res.status(200).json(user);
};

// update user
export const updateUser = async (req, res) => {
    const { id } = req.params;
    const { name, email } = req.body;

    const user = await prisma.user.update({
        where: {
            id: parseInt(id),
        },
        data: {
            name,
            email,
        },
    });

    return res.status(200).json(user);
};

// delete user
export const deleteUser = async (req, res) => {
    const { id } = req.params;

    const user = await prisma.user.delete({
        where: {
            id: parseInt(id),
        },
    });

    return res.status(200).json(user);
};

// create similar for post

2. Routes

Create a routes.js file in the root of the project. The following is the code for CRUD operations in the routes.js file:

import express from "express";
import {
    createUser,
    createPost,
    getUsers,
    getUserById,
    updateUser,
    deleteUser,
} from "./controllers.js";

const router = express.Router();

router.post("/users", createUser);
router.get("/users", getUsers);
router.get("/users/:id", getUserById);
router.put("/users/:id", updateUser);
router.delete("/users/:id", deleteUser);
// create similar for post
router.post("/posts", createPost);
// router.get('/posts', getPosts);
// router.get('/posts/:id', getPostById);
// router.put('/posts/:id', updatePost);
// router.delete('/posts/:id', deletePost);

export default router;

3. Server

Create a server.js file in the root of the project. The following is the code for CRUD operations in the server.js file:

import express from "express";
import dotenv from "dotenv";
import router from "./routes.js";

dotenv.config();

const app = express();

app.use(express.json());
app.use("/api", router);

const PORT = process.env.PORT || 5000;

app.listen(PORT, () => {
    console.log(`Server running on port ${PORT}`);
});

9. Run the Script

node index.js

This will execute the script, creating a user and a post in your database, then updating the user and deleting the post.

You can use Postman to test the API with the following routes:

POST: http://localhost:5000/api/users
GET: http://localhost:5000/api/users
GET: http://localhost:5000/api/users/1
PUT: http://localhost:5000/api/users/1
DELETE: http://localhost:5000/api/users/1

Set the body in Postman for the POST request as JSON with the following data:

{
    "name": "John Doe",
    "email": "sample@example.com"
}

Key Points to Consider for Prisma Syntax

findUnique/findFirst - to get a single record, does not return an array.
findMany - to get multiple records, returns an array.
include - to include the related data.
select - to select specific fields.
You can only use one of the attributes, either select or include.

Examples of Prisma Syntax

// get all posts of a user with id
const user = await prisma.user.findUnique({
    where: {
        id: parseInt(id),
    },
    include: {
        posts: true,
    },
});

// select specific fields of user with post details
const user = await prisma.user.findUnique({
    where: {
        id: parseInt(id),
    },
    select: {
        name: true,
        posts: {
            select: {
                title: true,
                content: true,
            },
        },
    },
});

// get all users name with their posts count (Aggregation)
const req_data = await prisma.user.findMany({
    select: {
        id: true,
        name: true,
        _count: {
            select: {
                post: true,
            },
        },
    },
});

More on Prisma Aggregations, Filtering, Ordering, and Relations

1. Aggregation Functions in Prisma

Prisma provides several aggregation functions that allow you to perform calculations on sets of data directly within your database queries. These functions are useful for summarizing data and gaining insights without having to fetch large amounts of data to your application.

Common Aggregation Functions

_count: Counts the number of records that match the given criteria.
_avg: Calculates the average of a numeric field.
_sum: Calculates the sum of a numeric field.
_min: Finds the minimum value of a field.
_max: Finds the maximum value of a field.

Examples of Aggregation

Let's assume we have the following Product model:

model Product {
    id        Int      @id @default(autoincrement())
    name      String
    price     Float
    category  String
    createdAt DateTime @default(now())
}

Counting the Number of Products in Each Category

const categoryCounts = await prisma.product.groupBy({
    by: ["category"],
    _count: {
        id: true, // Count based on the 'id' field
    },
});

console.log(categoryCounts);
// Example output:
// [
//   { category: 'Electronics', _count: { id: 10 } },
//   { category: 'Clothing', _count: { id: 5 } },
// ]

Calculating the Average Price of All Products

const averagePrice = await prisma.product.aggregate({
    _avg: {
        price: true,
    },
});

console.log(averagePrice);
// Example output: { _avg: { price: 25.50 } }

Finding the Minimum and Maximum Price of Products in a Specific Category

const minMaxPrices = await prisma.product.aggregate({
    where: {
        category: "Electronics",
    },
    _min: {
        price: true,
    },
    _max: {
        price: true,
    },
});

console.log(minMaxPrices);
// Example output: { _min: { price: 10.00 }, _max: { price: 50.00 } }

Sum of Prices for Products Created in the Last Week

const lastWeek = new Date();
lastWeek.setDate(lastWeek.getDate() - 7);

const sumOfPricesLastWeek = await prisma.product.aggregate({
    where: {
        createdAt: {
            gte: lastWeek,
        },
    },
    _sum: {
        price: true,
    },
});
console.log(sumOfPricesLastWeek);

2. Filtering in Prisma

Prisma offers a rich set of filtering options that allow you to precisely query your database. Here's a comprehensive overview with examples:

Basic Filtering

equals (Default): Checks for exact equality.

const users = await prisma.user.findMany({
    where: {
        email: "test@example.com", // Equivalent to: email: { equals: 'test@example.com' }
    },
});

not: Negates a condition.

const users = await prisma.user.findMany({
    where: {
        email: { not: "test@example.com" },
    },
});

Comparison Operators

gt (Greater Than), gte (Greater Than or Equal To), lt (Less Than), lte (Less Than or Equal To): Used for numeric and date/time comparisons.

const posts = await prisma.post.findMany({
    where: {
        id: { gt: 10 }, // Posts with ID greater than 10
    },
});

const usersCreatedAfter = await prisma.user.findMany({
    where: {
        createdAt: { gte: new Date("2024-01-01") },
    },
});

String Filters

contains: Checks if a string contains a substring.

const users = await prisma.user.findMany({
    where: {
        name: { contains: "Test" }, // Users with names containing "Test"
    },
});

startsWith: Checks if a string starts with a prefix.

const users = await prisma.user.findMany({
    where: {
        name: { startsWith: "A" }, // Users with names starting with "A"
    },
});

endsWith: Checks if a string ends with a suffix.

const users = await prisma.user.findMany({
    where: {
        email: { endsWith: "@example.com" },
    },
});

mode: insensitive: Performs case-insensitive searches.

const users = await prisma.user.findMany({
    where: {
        name: { contains: "test", mode: "insensitive" }, // Case-insensitive search
    },
});

List Filters

in: Checks if a value is present in a list.

const users = await prisma.user.findMany({
    where: {
        id: { in: [1, 2, 3] }, // Users with IDs 1, 2, or 3
    },
});

notIn: Checks if a value is not present in a list.

const users = await prisma.user.findMany({
    where: {
        id: { notIn: [4, 5, 6] }, // Users with IDs not equal to 4, 5, or 6
    },
});

Logical Operators

AND: Combines multiple conditions with a logical AND.

const users = await prisma.user.findMany({
    where: {
        AND: [
            { name: { contains: "Test" } },
            { email: { endsWith: "@example.com" } },
        ],
    },
});

OR: Combines multiple conditions with a logical OR.

const users = await prisma.user.findMany({
    where: {
        OR: [{ name: { startsWith: "A" } }, { email: { contains: "gmail" } }],
    },
});

NOT: Negates a group of conditions.

const users = await prisma.user.findMany({
    where: {
        NOT: {
            email: { contains: "example" },
        },
    },
});

Nested Filters (Filtering on Relations)

You can filter based on related models.

const posts = await prisma.post.findMany({
    where: {
        author: {
            email: { contains: "test" }, // Posts where the author's email contains "test"
        },
    },
});

const postsWithCategory = await prisma.post.findMany({
    where: {
        categories: {
            some: {
                // Use some for OR logic
                name: "Simple Category",
            },
        },
    },
    include: {
        categories: true,
        author: true,
        author: { include: { profile: true } },
    },
});

Filtering on Optional Relations

const usersWithOrWithoutProfile = await prisma.user.findMany({
    where: {
        profile: {
            is: null, // Find users without a profile
            // isNot: null // Find users WITH a profile
        },
    },

Combining Filters

You can combine these operators for complex filtering logic.

const users = await prisma.user.findMany({
    where: {
        AND: [
            { name: { startsWith: "J" } },
            {
                OR: [
                    { email: { contains: "gmail" } },
                    { email: { contains: "yahoo" } },
                ],
            },
        ],
    },
});

These examples cover the most common filtering scenarios in Prisma. By combining these operators and nested filters, you can create very precise queries to retrieve the exact data you need. Remember to consult the official Prisma documentation for the most up-to-date and detailed information.

Order Records in Prisma

Prisma's orderBy option allows you to sort the results of your queries. Here are some examples demonstrating its usage:

Basic Ordering

Ascending Order (Default):

```javascript
const usersAsc = await prisma.user.findMany({
    orderBy: {
        name: 'asc', // Sort users by name in ascending order (A-Z)
    },
});
```

Descending Order:

```javascript
const usersDesc = await prisma.user.findMany({
    orderBy: {
        name: 'desc', // Sort users by name in descending order (Z-A)
    },
});
```

Ordering by Multiple Fields

You can specify multiple fields to order by, with different directions for each. Prisma will first sort by the first field, then by the second field within groups of identical values in the first field, and so on.

const posts = await prisma.post.findMany({
    orderBy: [
        {
            author: {
                name: 'asc', // Sort by author's name first
            },
        },
        {
            title: 'desc', // Then sort by post title in descending order
        },
    ],
});

In this example, posts will be primarily sorted by the author's name in ascending order. If multiple posts have the same author, they will then be sorted by their titles in descending order.

Ordering by Nested Fields (Relations)

As shown in the previous example, you can order by fields on related models.

const postsByAuthorEmail = await prisma.post.findMany({
        orderBy: {
            author: {
                email: 'asc',
            },
        },
    });

This will order posts based on the email address of their authors.

Ordering by Date/Time Fields

You can order by date and time fields as well.

const postsByCreatedAt = await prisma.post.findMany({
    orderBy: {
        createdAt: 'desc', // Sort posts by creation date in descending order (newest first)
    },
});

Ordering by a Different Field than the Filtering Field

You can filter by one field and order by another. For example, you might want to find all users with a name containing "test" but order them by their email address:

const users = await prisma.user.findMany({
        where:{
                name:{
                        contains:"test"
                }
        },
        orderBy:{
                email:"asc"
        }
})

Using `nulls` Option

You can control how null values are handled in the sorting. The nulls option can be set to either first or last.

const usersWithNullsFirst = await prisma.user.findMany({
        orderBy: {
            name: {
                sort: 'asc',
                nulls: 'first', // Null values will appear first
            },
        },
    });

const usersWithNullsLast = await prisma.user.findMany({
        orderBy: {
            name: {
                sort: 'asc',
                nulls: 'last', // Null values will appear last (default behavior)
            },
        },
    });

By default, null values are placed last when sorting in ascending order and first when sorting in descending order. The nulls option allows you to override this default behavior.

Relation Functions in Prisma

Prisma excels at handling database relationships elegantly. Here are the key aspects:

Defining Relationships in the Schema: You define relationships between models directly in your schema.prisma file using the @relation attribute.
Types of Relationships: Prisma supports:
- One-to-One: One record in model A is related to exactly one record in model B.
- One-to-Many: One record in model A is related to multiple records in model B.
- Many-to-Many: Multiple records in model A are related to multiple records in model B (requires a join table).

Examples of Relations

Let's use the User and Post models from the previous examples:

model User {
    id      Int      @id @default(autoincrement())
    email   String   @unique
    name    String?
    profile Profile? @relation(fields: [profileId], references: [id]) // One-to-one (optional)
    profileId Int? @unique
    posts   Post[]   // One-to-many
}

model Profile {
    id      Int     @id @default(autoincrement())
    bio     String?
    user    User    @relation("UserToProfile", fields: [userId], references: [id]) // One-to-one
    userId  Int     @unique
}

model Post {
    id        Int      @id @default(autoincrement())
    title     String
    author    User     @relation(fields: [authorId], references: [id]) // One-to-many (Post to User)
    authorId  Int
    categories Category[] @relation("PostToCategory") // Many-to-many
}

model Category {
    id    Int     @id @default(autoincrement())
    name  String  @unique
    posts Post[] @relation("PostToCategory") // Many-to-many
}

Hope this helps you to understand the Prisma ORM in a better way.
Feel free to give your feedback and suggestions.

Thanks for reading! 🚀

DEV Community: Prathamesh Sable

Building a Flexible Recommendation Engine with Neo4j

Introduction

1. Why Recommendations Become Difficult

2. The Recommendation Pipeline

3. Use Neo4j as the Connected Data Layer

4. Finding Candidates Is Not the Same as Ranking Them

5. Where Cypher Fits

6. Graph Distance Does Not Always Mean Relevance

7. Turn Graph Connections Into Evidence

8. Give Relationships Clear Meaning

9. Hard Rules and Preferences Are Different

10. Start With Simple, Rule-Based Scoring

11. Scoring and Ranking Are Not Exactly the Same

12. Make Candidate Generation Flexible

13. Build Around "Recommendable Items"

14. Adding New Data Is Not Completely Automatic

15. Keep the Main Building Blocks Generic

16. Return the Reason Behind the Recommendation

17. A Possible Code Structure

18. AI Can Be Added Later

19. Common Mistakes to Avoid

20. How to Move Toward This Architecture

Step 1: Create Common Models

Step 2: Separate Candidate Generation

Step 3: Separate Evidence

Step 4: Create Features

Step 5: Separate Filtering, Scoring, and Ranking

Step 6: Make Important Settings Configurable

Step 7: Add More Retrieval Methods When Needed

Step 8: Try Machine Learning Later

21. The Main Design Idea

Final Takeaway

Stop Fighting Your AI Coding Agent - Here's How to Actually Use It 🤖

First, Understand What AI Actually Is 🧠

1. 🔌 Install the Right Plugins

Codegraph

Superpowers

2. 📄 Set Up Your CLAUDE.md Instructions

3. 🔄 The Actual Workflow

Step 1: Turn on Plan Mode (non-negotiable)

Step 2: State your requirements, then let the agent ask questions

Step 3: Review the spec document 📋

Step 4: Review the plan, then start a fresh session

Step 5: Kick off subagent-driven development

4. 🧪 Test Before You Commit

5. 🔍 Code Review

✅ You're Done!

I Fine-Tuned an LLM — And It Actually Worked

Prisma ORM: Start to End With Project using JS

What is Prisma?

Key Components

Why Prisma?

Project Setup

1. Project Setup

Create a new project directory

Initialize a Node.js project

Install Prisma CLI

Install the Prisma Client

2. Initialize Prisma

3. Configure the Database Connection

Choose a Database

Set the DATABASE_URL

4. Define the Data Models (schema.prisma)

5. Generate the Prisma Client

6. Create a Migration

7. Creating a Separate File for Prisma Setup

8. Creating a Basic Express API to Understand Prisma Working

1. Controller

2. Routes

3. Server

9. Run the Script

Key Points to Consider for Prisma Syntax

Examples of Prisma Syntax

More on Prisma Aggregations, Filtering, Ordering, and Relations

1. Aggregation Functions in Prisma

Common Aggregation Functions

Examples of Aggregation

Counting the Number of Products in Each Category

Calculating the Average Price of All Products

2. 📄 Set Up Your `CLAUDE.md` Instructions

Set the `DATABASE_URL`

4. Define the Data Models (`schema.prisma`)

Using `nulls` Option