DEV Community: Dayanand garg

GoWithProof: I Built My Friend an AI That Argues Against Its Own Recommendations

Dayanand garg — Sun, 04 Oct 2026 23:37:31 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

Choosing a place to go should be easy.

I built GoWithProof for a close friend I regularly make plans with. Whenever we decide where to eat, drink, or spend an evening around Delhi/Gurgaon, one of us inevitably ends up doing the same research loop: Google Maps, Reddit, restaurant apps, recent reviews, and then an AI search on top of all of it. We rarely trust a single source enough to make the decision.
That recurring problem was the reason for this project. I wanted to build something specifically for the way we actually make plans together—not another generic “best restaurants near me” app.

Search Google Maps
Check ratings
Open Reddit
Search for recent discussions
Look at restaurant platforms
Read the newest reviews
Read the worst reviews
Ask an AI
Discover that every source says something different
Still not know where to go

The problem is not that recommendations are unavailable.

The problem is that there are too many recommendations, from sources with different incentives, different levels of freshness, and different blind spots.

So I built GoWithProof.

Recommendations with receipts.

GoWithProof is an AI-assisted decision engine for choosing places.

Instead of asking an LLM:

"What's the best pub in Gurgaon?"

and trusting whatever appears next, GoWithProof does something closer to how I would research the decision myself.

It:

understands what you actually care about,
discovers plausible places,
researches recent reviews and live web evidence,
deliberately searches for complaints and counter-evidence,
extracts grounded claims,
measures evidence quality and disagreement,
ranks candidates deterministically,
and shows both why you should consider a place and why you might not want to go there.

The feature I care about most is called Devil's Advocate.

Most recommendation systems spend their effort finding reasons why their recommendation is good.

GoWithProof also asks:

What could make this recommendation wrong?

If a place looks great for craft beer but recent visitors repeatedly complain about service, noise, pricing, crowds, or reservations, I want to know that before we leave home.

It doesn't require a perfect prompt

A user can start with something vague:

"Find me a pub in Gurgaon."

GoWithProof progressively asks for the information that will materially change the decision.

For example:

"Friday around 8 PM."

"Around ₹1500 per person."

"Craft beer."

It builds a structured decision context across the conversation instead of forcing users to express every constraint in one giant prompt.

During development, I also learned that specific preferences need to stay specific.

For example:

craft beer != drinks
live music != music

If someone asks for craft beer, a generic cocktail bar should not automatically count as a strong match.

Preserving that meaning throughout clarification, discovery, research, and ranking became one of the most important parts of the system.

Demo

👉 Live Demo: https://go-with-proof.onrender.com

You can try something like:

Dinner in CP tomorrow at 7 PM, 4 people, around ₹1000–1200 each, great food, vegetarian options, and quiet enough to talk.

Or something simpler:

Find me a pub in Gurgaon with good craft beer.

The application will clarify missing details when necessary, research candidates, and return evidence-backed recommendations.

Code

The complete project is open source:

👉 Repository: https://gitlab.com/gargdaya/go-with-proof

The project is a small monorepo:

go-with-proof/
├── frontend/
│   └── Next.js + React + TypeScript
│
├── backend/
│   └── Bun + Elysia + TypeScript
│
├── .gitlab-ci.yml
└── render.yaml

GitLab CI runs the automated checks and production build, while the frontend and backend are deployed separately on Render.

How I Built It

One of the main design decisions was to avoid building a system where an LLM receives a prompt and simply returns three restaurant names.

I wanted to use the model where language models are strong, while keeping the actual decision process understandable and testable.

The architecture looks roughly like this:

User
  │
  ▼
Conversational clarification
  │
  ▼
Gemma
intent + constraints
  │
  ▼
DecisionContext
  │
  ▼
Candidate discovery
  │
  ▼
SerpApi
  │
  ├── Google Maps
  ├── Reviews
  └── Web/community search
          │
          ▼
Counter-evidence searches
          │
          ▼
Gemma evidence extraction
          │
          ▼
Grounding + Zod validation
          │
          ▼
Deduplication + normalization
          │
          ▼
Deterministic TypeScript ranking
          │
          ▼
Recommendations
  │
  ├── Why it fits
  ├── Confidence
  ├── Concerns
  └── Devil's Advocate

There are really three different jobs in that pipeline:

Understand

What does the user actually want?

Research

What evidence exists about the candidates?

Decide

How well does each candidate fit the current situation, and how much evidence do we actually have?

Keeping those responsibilities separate made the system much easier to reason about.

Gemma: Language Understanding, Not an Oracle

Gemma is at the core of GoWithProof, but it does not get to arbitrarily choose the final answer.

I use two Gemma models for different workloads.

Gemma 3 4B

The smaller model handles conversational clarification.

This operation happens frequently and is latency-sensitive.

Its job is to understand statements such as:

"tomorrow around seven"
"somewhere we can talk"
"around ₹1200 each"
"craft beer"
"vegetarian options"

and turn them into structured context.

Gemma 3 27B

The larger model is used where understanding messy natural language becomes more important: extracting structured evidence from reviews and search results.

Its job is to turn unstructured text into evidence such as:

{
  "category": "drinks",
  "sentiment": "positive",
  "claim": "The beer quality was praised.",
  "supportingQuote": "Superb quality beer....",
  "firsthand": true,
  "confidence": 0.8
}

But Gemma does not calculate the final recommendation score.

That is deliberate.

The model interprets language.

The application makes the decision.

Things such as:

freshness weighting,
preference matching,
negative ratios,
source diversity,
practical constraints,
evidence quantity,
disagreement,
and confidence

are handled deterministically in TypeScript.

That gives me something I can test and reason about.

SerpApi: Connecting the System to Live Evidence

A recommendation engine isn't very useful if its knowledge stops at model training time.

GoWithProof uses SerpApi as its live research layer.

It provides information used for:

place discovery,
Google Maps results,
business metadata,
ratings and review counts,
operating information,
recent reviews,
low-rated reviews,
Google Search results,
community discovery,
and deliberate counter-evidence searches.

The key idea is that SerpApi provides evidence, not the final answer.

GoWithProof does not assume:

"Google Maps ranked this first, therefore it must be the best."

Instead, those results become inputs into a larger decision process.

That distinction matters.

I Search for Reasons NOT to Recommend a Place

This is probably the most important part of the project.

For a candidate, GoWithProof doesn't only run normal searches.

It deliberately generates searches such as:

"<place>" bad experience
"<place>" overrated
"<place>" crowded
"<place>" expensive
"<place>" noisy

Those searches can also depend on what the user actually cares about.

If the user says:

"I want somewhere quiet enough to have a conversation."

then evidence about noise becomes especially important.

If they want craft beer, evidence about the beer matters more than generic evidence about cocktails.

This became the Devil's Advocate part of GoWithProof.

Instead of only asking:

"How can I justify recommending this?"

the system also asks:

"What evidence would make me change my mind?"

Every AI Claim Needs a Receipt

One of my favorite bugs from the weekend changed the architecture.

During a live test, a review said something positive about vegetarian food.

Gemma produced a claim saying both:

the vegetarian food was good and the music was good

The source excerpt did not actually support the music claim.

It was a small hallucination.

But for GoWithProof, that is a serious problem.

The entire product is based on the idea that recommendations should be inspectable.

So I changed the evidence model.

Every extracted claim now contains a supportingQuote.

Conceptually:

type Evidence = {
  sourceType:
    | "google_maps_review"
    | "reddit"
    | "official"
    | "web";

  sourceUrl: string;
  sourceDate?: string;

  category:
    | "food"
    | "service"
    | "noise"
    | "price"
    | "crowd"
    | "ambience"
    | "drinks"
    | "wait_time"
    | "cleanliness"
    | "other";

  sentiment:
    | "positive"
    | "negative"
    | "mixed"
    | "neutral";

  claim: string;
  supportingQuote: string;
  firsthand: boolean;
  confidence: number;
};

The backend verifies that the supporting quote actually exists in the source material before accepting the evidence.

If an extracted claim cannot be grounded in the retrieved text, it should not survive the pipeline.

That was an important lesson:

LLMs can be excellent evidence interpreters, but evidence still needs verification.

Negative Evidence Is First-Class Data

I also wanted to avoid the classic recommendation pattern:

4.5 stars — highly recommended!

A place can have thousands of excellent reviews while still having a recurring problem that matters specifically to you.

So GoWithProof tracks negative evidence explicitly.

For every candidate it can calculate things such as:

total evidence
positive evidence
negative evidence
negative ratio
recent negative evidence
source diversity

The ratio matters more than simply counting complaints.

For example:

5 negative signals out of 8

is very different from:

5 negative signals out of 80

even though the raw negative count is identical.

Freshness matters too.

A complaint from last month should generally matter more than a complaint from four years ago.

Match and Confidence Are Not the Same Thing

This became another important lesson.

Imagine a place appears to perfectly satisfy what the user asked for.

It is:

the right kind of venue,
in the right area,
open at the requested time,
and associated with the requested preference.

That can make it look like an excellent fit.

But what if the system only managed to collect one useful piece of evidence?

Then these two statements are very different:

This place looks like a good fit.

and:

We have strong evidence that this place is a good fit.

GoWithProof therefore separates recommendation fit from evidence confidence.

A candidate can effectively be:

Strong potential fit · Low confidence

instead of turning sparse evidence into false certainty.

When the evidence is too weak, the application explicitly labels it:

Weak evidence

I think recommendation systems should be allowed to admit uncertainty.

Disagreement Is Useful Information

Sources do not always agree.

Instead of averaging disagreement away, GoWithProof can track it by category.

Imagine the research produced:

Food
8 positive
1 negative

Service
6 positive
5 negative

Noise
1 positive
7 negative

Those categories tell very different stories.

Food looks consistently strong.

Service is disputed.

Noise looks like a legitimate concern.

A single average score hides all of that.

GoWithProof preserves disagreements so the user can decide whether they matter.

Failure Is Part of Live Web Research

Real-time research is messy.

During development I encountered:

empty search results,
malformed model output,
network failures,
provider timeouts,
missing dates,
duplicate URLs,
evidence that could not safely be attributed,
and community searches with no useful result.

I didn't want one unavailable source to make the whole recommendation fail.

Each research channel therefore has its own coverage state.

Conceptually:

{
  "recentReviews": "ok",
  "lowRatedReviews": "ok",
  "community": "empty",
  "counter": "ok"
}

The system can still return useful partial research.

And importantly, it can tell the user when evidence is incomplete instead of silently pretending everything succeeded.

The First Research Pipeline Took 85 Seconds

One of my first successful live research runs took around 85 seconds.

It technically worked.

But nobody wants to stare at a loading spinner for a minute and a half while deciding where to eat.

The first implementation was performing too much research across too many candidates.

So I changed the orchestration.

Instead of deeply researching everything immediately, the pipeline became closer to:

Broad discovery
      │
      ▼
Candidate filtering
      │
      ▼
Smaller research set
      │
      ▼
Parallel source collection
      │
      ▼
Evidence extraction

Independent searches run concurrently with bounded concurrency.

Candidate research is capped.

Partial results can survive the research time budget.

One later live run dropped from roughly 85 seconds to around 15 seconds.

That was a useful engineering lesson:

Better prompting cannot compensate for inefficient orchestration.

Progressive Clarification Was Harder Than Expected

The clarification system also went through several iterations.

Initially, every answer was sent back through Gemma.

That caused a funny but important failure.

The UI asked:

"What matters most?"

The user clicked:

"Drinks"

The backend failed to preserve that answer correctly.

So it asked:

"What matters most?"

again.

And again.

The fix was simple once it was obvious:

Do not use AI to interpret information your own UI already knows.

Quick-choice answers are now merged deterministically.

Gemma is reserved for genuinely free-form language such as:

"good beers and somewhere we can actually talk"

That reduced unnecessary inference and removed an entire class of clarification loops.

Specific Intent Should Stay Specific

Another problem appeared when:

craft beer → drinks
live music → music

Those transformations are technically reasonable abstractions, but they destroy information that matters to the decision.

A person asking for craft beer does not simply want "drinks".

A person asking for live music does not necessarily want a DJ.

So GoWithProof preserves specific traits alongside broad categories.

For example:

{
  "priorities": ["drinks"],
  "traits": ["craft_beer"]
}

That information can then influence discovery and ranking.

It also prevents unrelated evidence from being treated as more relevant than it really is.

For example, a complaint about cocktails should not automatically mean the craft beer is bad.

Testing

The backend has tests around the areas I considered most dangerous:

context accumulation,
explicit corrections,
timezone-aware dates,
quick-choice merging,
clarification loops,
model validation,
evidence grounding,
deduplication,
unknown source dates,
partial provider failure,
freshness weighting,
negative ratios,
source diversity,
disagreement detection,
ranking,
confidence,
and weak-evidence handling.

By the time I froze the backend for submission:

86 automated tests were passing

along with successful type checks and production builds.

For a weekend project, writing those tests saved much more time than they cost.

Tech Stack

Frontend

Next.js
React
TypeScript
Tailwind CSS
shadcn/ui
Lucide

Backend

Bun
TypeScript
Elysia
Zod

AI

Gemma 3 4B
Gemma 3 27B
Hugging Face Inference

Live Research

SerpApi
Google Maps results
Google Maps reviews
Google Search and community discovery

Deployment

Render Web Service for the frontend
Render Web Service for the backend
GitLab CI/CD

Both production services are described in render.yaml.

GitLab CI performs verification before deployment:

git push
   │
   ▼
GitLab CI
   │
   ├── install
   ├── tests
   ├── typecheck
   └── production build
          │
          ▼
        Render
       /      \
 frontend    backend

There is no PM2, Docker, Redis, queue, vector database, or giant agent framework involved.

For this project I deliberately preferred a small system whose decisions I could still understand.

Why Does Open Innovation Matter?

GoWithProof is fundamentally about questioning opaque authority.

The application doesn't say:

"Trust this recommendation because AI said so."

It says:

"Here is the evidence I found. Here is what supports the recommendation. Here is what contradicts it. You decide."

I wanted the AI layer to follow the same philosophy.

Using an open-weight model like Gemma means the language-understanding layer isn't inseparably tied to a single proprietary recommendation system.

The architecture keeps clear boundaries:

Gemma
"What does the user mean?"
"What does this evidence say?"

SerpApi
"What is happening on the live web?"

Application code
"How fresh is this?"
"How relevant is it?"
"How much independent evidence exists?"
"Where do sources disagree?"
"How strongly should we recommend it?"

That separation gives me control over the actual decision logic.

I can change model sizes.

I can change inference providers.

I can inspect and iterate on prompts.

I can test deterministic scoring independently.

And because Gemma is open-weight, the model itself can eventually run in environments where sending every user interaction to a closed hosted model is not desirable.

A completely closed recommendation API would give me an answer.

Open components let me build a decision process.

That difference is the entire point of GoWithProof.

Don't ask for authority. Ask for evidence.

What I Learned

I started the weekend thinking I was building a recommendation engine.

By the end, I realized I was really building a small decision engine.

The interesting questions were not:

"How do I ask an LLM for the top three restaurants?"

They were:

"How do I know whether this evidence is actually about this restaurant?"

"What happens when recent reviews disagree with the overall rating?"

"Should five negative reviews matter if there are eighty positive ones?"

"How do I distinguish a place that looks right from a place I have strong evidence for?"

"What happens when one research source fails?"

"How do I stop the model from turning 'craft beer' into generic 'drinks'?"

"How do I prevent an extracted claim from saying more than its source actually said?"

Those questions made the project much more interesting than the original idea.

The biggest lessons were:

Discovery and verification are different problems.
Specific user intent should remain specific.
Negative evidence deserves equal treatment.
Freshness matters.
Source disagreement should be exposed, not averaged away.
A model-generated claim needs provenance.
Match quality and evidence confidence are different concepts.
Partial failure is normal in live web research.
Deterministic code is often better than another LLM call.
Sometimes "I don't have enough evidence" is the best recommendation.

What I'd Build Next

There is a lot more I would like to explore with GoWithProof.

Future versions could include:

post-visit feedback,
gradual preference learning,
remembering what kinds of places a user actually enjoys,
comparing places friends have already suggested,
stronger cross-platform candidate discovery,
deeper Reddit/community research,
on-demand verification of a specific place,
recommendation history,
streaming research progress,
trip and itinerary decisions,
and eventually decisions beyond restaurants entirely.

But those are extensions.

The core idea is already:

Discover
   ↓
Verify
   ↓
Challenge
   ↓
Decide

Prize Categories

Best Use of Gemma

Gemma is a core part of GoWithProof rather than an optional chatbot layer.

Gemma handles natural-language clarification and turns messy live research into structured evidence.

I use a smaller Gemma model for latency-sensitive clarification and a larger model for deeper evidence interpretation.

The final ranking remains deterministic, making the boundary between model interpretation and application decision-making explicit.

Best Use of SerpApi

SerpApi is GoWithProof's connection to the live world.

It powers place discovery, Maps information, review retrieval, organic search, community discovery, and the deliberate counter-evidence searches that make Devil's Advocate possible.

Without live search, the product would simply be another model recommending places from stale training knowledge.

SerpApi turns it into a research system.

Best Use of Render

The complete production application runs on Render.

Both the Next.js frontend and Bun/Elysia backend are deployed as independent Render Web Services.

The backend running on Render orchestrates live SerpApi research, Gemma inference, validation, evidence processing, and ranking.

Deployment configuration is committed as infrastructure-as-code through render.yaml, while GitLab CI runs tests, type checks, and production builds before deployment.

I built GoWithProof because I wanted a recommendation system I could disagree with.

Not one that hides uncertainty behind a confident answer.

Not one that assumes the highest-rated result must be right.

And not one that asks me to trust an AI without showing me where its answer came from.

Sometimes the most useful thing an AI can say isn't:

"Go here."

It's:

"This looks promising. Here's the evidence. Here's what worries me. Now you decide."

That's GoWithProof.

Recommendations with receipts.

Mastering Database Schema Design: The First Step of Requirement Gathering

Dayanand garg — Thu, 30 Mar 2023 18:19:23 +0000

When it comes to designing a database schema, the first and most important step is requirement gathering. This step involves understanding the needs and objectives of the system being developed and the data that will be stored and processed within the database. A well-designed database schema can greatly improve the efficiency and accuracy of data management, and ultimately, the success of the system as a whole.

Here are some key steps to follow when gathering requirements for database schema design:

Identify the stakeholders: The first step in requirement gathering is to identify the stakeholders who will be using the system and the data that will be stored in the database. This includes end-users, developers, and other stakeholders such as managers, administrators, and data analysts.
Determine the scope: Once the stakeholders have been identified, it is important to determine the scope of the system and the database. This includes understanding the business processes, rules, and workflows that will be supported by the database, as well as the types of data that will be stored and processed.
Define the data entities: Once the scope has been determined, the next step is to define the data entities that will be stored in the database. This involves identifying the key data elements and their relationships, as well as any constraints or rules that must be applied to the data.
Determine the data attributes: For each data entity, it is important to determine the attributes that will be stored in the database. This includes defining the data type, size, format, and any other relevant properties.
Identify the relationships: Once the data entities and attributes have been defined, the next step is to identify the relationships between the entities. This involves understanding the primary keys, foreign keys, and any other relationships that must be established to ensure data integrity and consistency.
Consider performance and scalability: Finally, when gathering requirements for database schema design, it is important to consider performance and scalability. This includes understanding the expected volume of data and transactions, as well as the types of queries and reports that will be generated. This information can be used to design a database schema that is optimized for performance and can scale to meet future needs.

Overall, requirement gathering is a crucial step in the database schema design process. By taking the time to understand the needs and objectives of the system and the data that will be stored and processed, it is possible to design a database schema that is efficient, accurate, and supports the needs of all stakeholders.

Database Design 101: An Introduction

Dayanand garg — Wed, 22 Feb 2023 17:30:50 +0000

If you're new to the field of database design, you might be wondering what it is and why it's important. In this post, we'll provide a basic overview of database design, explain why it matters, and walk you through the basic steps involved in the database design process.

What is database design?

At its core, database design is the process of creating a logical and physical model of a database system. This involves defining the structure of the data, the relationships between different data elements, and the rules for storing and retrieving the data. A well-designed database can improve data accuracy, reduce data redundancy, and provide faster access to the data.

Why is database design important?
Database design is critical because it can impact the performance and usability of a database system. Poorly designed databases can lead to data inconsistencies, slower performance, and difficulties in retrieving and analyzing data. On the other hand, well-designed databases can provide numerous benefits, including improved data accuracy, increased data security, and faster access to the data.

Steps in the database design process

The database design process typically involves several distinct steps, including requirements gathering, conceptual design, logical design, normalization, physical design, implementation, and maintenance.

Requirements gathering: This involves understanding user requirements, defining data elements, and creating use cases and scenarios.
Conceptual design: This step involves creating an Entity-Relationship (ER) model, identifying entities and attributes, and defining relationships between entities.
Logical design: Here, you create a relational schema, define tables and columns, and create primary and foreign keys.
Normalization: This step involves organizing the data into tables and eliminating redundancy in the data.
Physical design: In this step, you choose a database management system (DBMS), define storage structures, and create indexes and views.
Implementation: This involves creating the database schema, populating the database with data, and ensuring data integrity and security.
Maintenance: Finally, you'll monitor the database performance, back up and restore the database, and modify the database schema as needed.

Conclusion
Database design is a complex and important field that can have a significant impact on the performance and usability of a database system. By understanding the basic steps involved in the database design process, you can begin to create databases that are well-designed, secure, and efficient. In the coming chapters of this book, we'll dive deeper into each step of the database design process, providing practical advice and best practices along the way.

We hope you found this introduction to database design helpful. If you have any questions or comments, please feel free to leave them below!

Why Next.js is the Best Choice for Server-Side Rendering with React

Dayanand garg — Wed, 22 Feb 2023 04:59:37 +0000

In recent years, server-side rendering (SSR) has become an essential part of building modern web applications. Server-side rendering allows web developers to provide better user experience and improve search engine optimization (SEO) by pre-rendering HTML on the server before sending it to the client. React, one of the most popular JavaScript libraries for building web applications, also supports server-side rendering. In this blog, we'll discuss why Next.js is the best choice for server-side rendering with React.

What is Next.js?

Next.js is a popular open-source framework for building server-rendered React applications. It was created by Vercel, the company that created the popular JavaScript-based JAMstack platform. Next.js provides a set of tools and features that help developers build high-performance web applications. Some of its features include:

Server-side rendering: Next.js provides built-in support for server-side rendering, which means that your application's pages are pre-rendered on the server and sent to the client as HTML. This significantly improves the time-to-first-byte (TTFB) and makes the website load faster.
Automatic code splitting: Next.js automatically splits your code into smaller chunks, which reduces the size of the JavaScript files and improves the page load time.
Static site generation: Next.js supports static site generation, which means that your website's pages can be pre-generated as static HTML files and served from a content delivery network (CDN). This further improves the page load time and reduces the server's load.

Why Next.js is the Best Choice for Server-Side Rendering with React

Easy to get started: Next.js provides an easy-to-use CLI tool that helps you create a new project quickly. You don't need to set up a separate server or configure complex build tools. Next.js takes care of all the setup, so you can focus on building your application.
Provides a great developer experience: Next.js provides a great developer experience by supporting hot module replacement (HMR), which means that your changes are reflected in the browser instantly. This makes the development process faster and more efficient.
Improves search engine optimization: By using server-side rendering, Next.js provides search engine crawlers with fully rendered HTML pages, which makes it easier for them to index your website's content. This improves the website's visibility on search engine results pages (SERPs) and can lead to more organic traffic.
Better performance: Next.js provides faster page load times by using server-side rendering and automatic code splitting. This significantly reduces the time-to-first-byte (TTFB) and makes the website load faster. In addition, Next.js supports static site generation, which makes the website even faster by serving pre-generated HTML files from a content delivery network (CDN).

Conclusion

Next.js is a powerful open-source framework for building server-rendered React applications. It provides a set of tools and features that make it easy to get started and improve the website's performance, developer experience, and search engine optimization. If you're looking to build a server-rendered React application, Next.js is the best choice

How to track user location in background

Dayanand garg — Sat, 18 Feb 2023 03:51:12 +0000

In many mobile apps, it's important to track the user's location to provide location-based services or gather data for analytics purposes. However, tracking the location in the background and sending it to the server can be challenging, especially when the screen is locked or the app is in the background. In this tutorial, we'll learn how to update the user's location in every 15 minutes and send it to the server even when the screen is locked in a React Native app.

Prerequisites

Before we get started, make sure you have the following installed on your development machine:

Node.js (v10 or later)
React Native CLI
Android Studio (for Android development)
Xcode (for iOS development)

Step 1: Install necessary packages

First, let's install the necessary packages to track the user's location in the background and schedule a background task. Run the following commands in your terminal:



npm install @react-native-community/geolocation
npm install react-native-background-task

Step 2: Grant permissions

Next, we need to grant the necessary permissions to access the device's location. Depending on your target platform, you need to add the following lines to your AndroidManifest.xml and Info.plist files:

AndroidManifest.xml:



<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />

Info.plist:



<key>NSLocationAlwaysAndWhenInUseUsageDescription</key>
<string>Location is used to track your movements.</string>
<key>NSLocationAlwaysUsageDescription</key>
<string>Location is used to track your movements.</string>
<key>NSLocationWhenInUseUsageDescription</key>
<string>Location is used to track your movements.</string>
<key>UIBackgroundModes</key>
<array>
  <string>fetch</string>
  <string>remote-notification</string>
  <string>location</string>
</array>

These permissions allow the app to access the device's location even when the app is in the background or the screen is locked.

Step 3: Set up background location tracking

Now, let's set up the background location tracking using the Geolocation module from @react-native-community/geolocation. This module provides a way to watch the device's position in the background and receive updates at a given interval.

Here's an example of how you can set up the background location tracking:



import Geolocation from '@react-native-community/geolocation';

// Configure Geolocation
Geolocation.setRNConfiguration({
  authorizationLevel: 'always', // Request "always" location permission
  skipPermissionRequests: false, // Prompt for permission if not granted
});

// Watch for position updates
const watchId = Geolocation.watchPosition(
  position => {
    console.log(position);
    // Send the position data to the server
  },
  error => {
    console.log(error);
  },
  {
    distanceFilter: 10, // Minimum distance (in meters) to update the location
    interval: 900000, // Update interval (in milliseconds), which is 15 minutes
    fastestInterval: 300000, // Fastest update interval (in milliseconds)
    accuracy: {
      android: 'highAccuracy',
      ios: 'best',
    },
    showsBackgroundLocationIndicator: true,
    pausesLocationUpdatesAutomatically: false,
    activityType: 'fitness', // Specify the activity type (e.g., 'fitness' or 'other')
    useSignificantChanges: false,
    deferredUpdatesInterval: 0,
    deferredUpdatesDistance: 0,
    foregroundService: {
      notificationTitle: 'Tracking your location',
      notificationBody: 'Enable location tracking to continue', // Add a notification body
    },
  }
);

// To stop tracking (for example, when the component unmounts):
// Geolocation.clearWatch(watchId);

By following the steps outlined in this tutorial, you can ensure that your app continues to track the user's location and provide relevant services even when the app is in the background or the screen is locked.