DEV Community: Shweta Kale

Fluencr - Find Instagram Influencer For your brand

Shweta Kale — Mon, 26 May 2025 06:57:21 +0000

🧠 AI-Powered Influencer Discovery Engine

What I Built

I built an AI-powered platform that helps brands discover ideal influencers by tapping into real-time social media data. Unlike static influencer directories, this tool dynamically finds creators who align with a brand’s tone, values, target audience, and preferred content style.

The system uses an AI agent to:

Collect brand intent via a clean, guided interface
Generate a natural language brief for influencer matching
Transform that into search signals (hashtags, keywords, captions)
Crawl Instagram in real time using Bright Data's MCP

This lets brands find relevant, high-performing influencers based on their current content—not stale bios or outdated databases.

Demo

GitHub Repo: github.com/raibove/Fluencr

Live Demo: https://fluencr.pages.dev/

How I Used Bright Data's Infrastructure

To power the real-time influencer discovery system, I used Bright Data’s MCP (Mobile Cloud Proxy) and automation tools. Here's how it helped:

🔍 Discover – Crawler-Based Search

Used Search Engine Crawler API to scan TikTok, Instagram, and YouTube content based on AI-generated hashtags, keywords, and even video transcript data.
Dynamically prioritized posts with high engagement and recency.

🧭 Access – Platform Navigation with JS Rendering

Platforms like TikTok and Instagram require login, scrolling, and human behavior simulation.
Bright Data’s helped avoid detection and ensure reliability.

📥 Extract – Scraping Key Data

Collected structured content:
- Creator handles, bios, and follower count
- Common hashtags and captions
- Engagement stats and collaboration links
- Video transcripts (when available)
Stored this data with content embeddings for future AI-based matching.

Performance Improvements

Traditional influencer tools rely on pre-populated databases or partner networks, which are:

Often outdated
Miss dynamic trends
Lack true intent-based matching

By using real-time social content scraping, I was able to:

Surface creators based on live content behavior
Identify micro-influencers aligned with niche values like sustainability or tech innovation
Deliver 10x more relevant results for brands with very specific audience goals

Tech Stack

Layer	Tools Used
Frontend	React
Backend AI	Cloudflare Worker + GPT-4
Scraping Infra	Bright Data MCP

App Flow: From Brand Brief to Influencer Match

Enter Brand Details

→ Dropdowns for brand tone, audience, platform, values
AI Improves Prompt

→ GPT-4 generates a structured brand profile:

“Looking for creators who post funny, women-focused, Gen Z content around self-love on Instagram”
Generate Search Signals

→ AI outputs hashtags, content types, keywords
Search & Extract

→ Bright Data crawls platforms, simulates interaction, and extracts data
Deliver Matches

→ Ranked influencer shortlist with metrics and links

Final Thoughts

This tool blends AI prompt generation, real-time web scraping, and content analysis to solve one of the biggest challenges in influencer marketing: finding creators who truly align with a brand’s evolving voice and values.

By using Bright Data’s infrastructure, I was able to go beyond APIs and get dynamic, actionable insights directly from the platforms that matter.

🎨 Come Build and Deploy a Random Color Generator with Me Using Next.js, AWS, and Pulumi

Shweta Kale — Mon, 07 Apr 2025 06:56:40 +0000

This is a submission for the Pulumi Deploy and Document Challenge: Fast Static Website Deployment

What I Built

I created a Random Color Generator—a lightweight web app built with Next.js that displays a new random background color on each page load. It’s a small but fun tool for designers, developers, or anyone who loves color. It's also a great way to demonstrate deploying static websites to AWS using infrastructure as code with Pulumi.

Live Demo Link

🔗 View Live Demo

Project Repo

raibove / random-color-generator

Generate random color

🎨 Random Color Generator

A lightweight, fun static web app built with Next.js that displays a new random background color on every page load. This project also showcases how to deploy static websites to AWS using Pulumi and infrastructure as code principles.

🚀 Live Demo

👉 View Live Demo

📁 Project Structure

/app – The main Next.js app (exported as static HTML)
Pulumi/ – Infrastructure code to deploy to AWS S3 + CloudFront using Pulumi (in TypeScript)

📸 Preview

⚙️ How It Works

Each time you refresh the page, the background color changes randomly using a generateRandomColor() function in JavaScript. The app was statically exported using next export and deployed securely using AWS services via Pulumi.

🛠️ Deployment Using Pulumi

The infrastructure is defined in TypeScript and includes:

1. S3 Bucket (Private)

Hosts the exported static site.
Blocked public access.
Configured using BucketV2 and BucketWebsiteConfigurationV2.

2. CloudFront Distribution

Serves…

View on GitHub

You’ll find:

The full Pulumi deployment code
Instructions on setting up the Next.js app
A clean, minimal README to help you get started quickly

My Journey

🧪 Step 1: Let’s Build Something Simple

I started with a local Next.js project that randomly changes the background color every time the page is refreshed. I created a method called generateRandomColor to generate the random color dynamically, and the result was both playful and vibrant.

Once it looked good locally, I was ready to put it on the web.

🌐 Step 2: Hosting Static Files with AWS S3

The Next.js app was exported using next export, creating static files in the out/ directory.

To deploy these files, I used Pulumi to create an S3 bucket:

const bucket = new aws.s3.Bucket("color-bucket", {
  website: {
      indexDocument: "index.html",
  },
});

I uploaded all the files using Node’s fs module, and created s3 BucketObject for each path to deploy site assets

// for each dir we used this code
  new aws.s3.BucketObject(relativeFilePath, {
    bucket: bucket.id,
    source: new pulumi.asset.FileAsset(filePath),
    contentType: lookup(filePath) || undefined,
  });

🔐 Step 3: Oh No—Access Denied?!

After uploading, I tried to open the website via the bucket endpoint—and got blocked.
S3 had blocked public access by default. I briefly made the bucket public just to test, and while it worked, I immediately realized this wasn’t secure or scalable.

🛡️ Step 4: Enter CloudFront – Secure + Fast

Instead of making the bucket public, I used CloudFront with an Origin Access Identity (OAI) to serve files securely. This way, CloudFront could fetch content from S3, and S3 remained private.

Here’s how I linked CloudFront and S3 securely:

const oai = new aws.cloudfront.OriginAccessIdentity("oai", {
  comment: "OAI for secured S3 access",
});

Then, I wrote a bucket policy granting s3:GetObject only to this OAI.

const bucketPolicy = new aws.s3.BucketPolicy("bucket-policy", {
  bucket: bucket.id,
  policy: pulumi.all([bucket.bucket, oai.iamArn]).apply(([bucketName, iamArn]) => {
    return JSON.stringify({
      Version: "2012-10-17",
      Statement: [
        {
          Effect: "Allow",
          Principal: { AWS: iamArn },
          Action: "s3:GetObject",
          Resource: `arn:aws:s3:::${bucketName}/*`,
        },
      ],
    });
  }),
});

🌍 Step 5: Create a CloudFront Distribution to Serve Your Website Globally

To deliver your static website with low latency and improved performance across the globe, we configure an AWS CloudFront distribution. CloudFront acts as a Content Delivery Network (CDN), caching your website content at edge locations.

This block sets up CloudFront to serve content securely from the S3 bucket, enforce HTTPS, cache static assets, and handle errors gracefully. The Origin Access Identity (OAI) ensures that only CloudFront (not the public internet) can access your S3 bucket content.

const cloudfrontDistribution = new aws.cloudfront.Distribution("web-distribution", {
  enabled: true,

  // Define the S3 bucket as the origin
  origins: [{
    originId: bucket.id,
    domainName: bucket.bucketRegionalDomainName,
    s3OriginConfig: {
      originAccessIdentity: oai.cloudfrontAccessIdentityPath,
    },
  }],

  // Default behavior for all requests
  defaultCacheBehavior: {
    targetOriginId: bucket.id,
    viewerProtocolPolicy: "redirect-to-https", // Enforce HTTPS
    allowedMethods: ["GET", "HEAD", "OPTIONS"],
    cachedMethods: ["GET", "HEAD", "OPTIONS"],
    forwardedValues: {
      queryString: false,
      cookies: { forward: "none" }, // Improve cacheability
    },
    minTtl: 0,
    defaultTtl: 3600,
    maxTtl: 86400,
  },

  defaultRootObject: "index.html",

  // Error responses are redirected to index.html to support clean URLs or fallback content
  customErrorResponses: [
    {
      errorCode: 403,
      responseCode: 200,
      responsePagePath: "/index.html",
    },
    {
      errorCode: 404,
      responseCode: 200,
      responsePagePath: "/index.html",
    },
  ],

  priceClass: "PriceClass_100", // Use cost-efficient edge locations
  viewerCertificate: {
    cloudfrontDefaultCertificate: true, // Use default CloudFront SSL certificate
  },

  restrictions: {
    geoRestriction: {
      restrictionType: "none", // No country-based restrictions
    },
  },
}, {
  dependsOn: [bucketPolicy], // Ensure the S3 bucket policy is in place before distribution
});

✨ Step 6: Refactoring Pulumi Static Site Deployment: From Complex to Clean with BucketV2

While exploring Pulumi for deploying a static site to AWS, I initially started by stitching together different snippets—mostly influenced by Pulumi Copilot suggestions and online examples. The deployment worked, but the code felt a bit heavy and overly complex for what was essentially a simple use case: serve a static site securely via S3 and CloudFront.

🧠 Discovery: What’s BucketV2?
While chatting with Pulumi copilot and reading deeper through Pulumi docs, I came across BucketV2 and BucketWebsiteConfigurationV2. These are part of the updated AWS S3 API and give a more modular and future-proof way to define bucket behavior, especially website settings and public access restrictions. That was the cue to start refactoring.

✅Improvements After Refactoring

Switched to BucketV2 + BucketWebsiteConfigurationV2 Before:

const bucket = new aws.s3.Bucket(...);
bucket.website = { indexDocument: "index.html" };

After:

const bucket = new aws.s3.BucketV2("bucket", {});
const websiteConfig = new aws.s3.BucketWebsiteConfigurationV2("config", {
  bucket: bucket.id,
  indexDocument: { suffix: "index.html" },
});

🟢 Why it’s better: Clear separation of concerns. BucketV2 handles just the bucket, and the website settings are defined explicitly in BucketWebsiteConfigurationV2.

🔐 2. Tighter CloudFront + OAI Integration
The original setup required manually managing bucket policy, blocking public access, and wiring the OAI correctly—while juggling dependencies across resources.

🟢** What improved:** The refactored version keeps the OAI logic clear, makes policy assignment more predictable, and ensures the S3 bucket is accessible only through CloudFront.

📦 3. Cleaner File Upload with BucketObject
Used a recursive upload function to mirror the folder structure into the S3 bucket, without overcomplicating ACLs or dealing with public access issues.

🟢 Improvement: Now everything is private by default and securely served via CloudFront.

🧩 What I Learned

Not all snippets are created equal. What works in isolation might not scale or feel right when put together.
BucketV2 and friends are the way forward if you're starting a new project. They’re cleaner, more modular, and aligned with AWS’s evolving APIs.
Understanding resource relationships (like between OAI, bucket policies, and public access blocks) is key to avoiding common pitfalls in AWS infrastructure.

This refactor was more than just cleanup—it was a learning exercise in how Pulumi encourages modular and declarative infrastructure. With a better understanding of the tools and a simpler setup, I now have a static site deployment stack that’s secure, scalable, and easy to maintain.

Using Pulumi 🛠️

As a frontend developer, I’ve mostly relied on platforms like Vercel or Netlify to deploy my sites. They’re super convenient, especially when you just want to push to Git and get a live preview. I always felt that diving into AWS directly was a bit too involved for static sites—until I discovered Pulumi.

Pulumi changed my perspective completely.

With Pulumi, I was able to define my entire infrastructure using TypeScript, the same language I use for building my frontend apps. That familiarity made it surprisingly approachable. Instead of clicking around the AWS Console or writing CloudFormation, I could write real code—loop over files, conditionally configure resources, and reuse logic just like in any other app.

Now that I understand how Pulumi works, I feel like I have the best of both worlds:

The power and flexibility of AWS,

Combined with the ease and speed of modern frontend tooling.

💬 Pulumi Copilot: The AI Teammate I Didn't Know I Needed
I also tried out Pulumi Copilot while working on this. Some of the prompts I used were:

“Deploy a static site to AWS using S3 and CloudFront with Pulumi in TypeScript.”

“How do I make sure S3 is only accessible through CloudFront?”

“How to configure custom error responses for a single page app?”

It gave me a solid foundation to start with—but I still had to refactor a lot (see above 😅). That said, it was a great assistant to explore AWS resource options and common configurations quickly.

Pulumi didn’t just help me deploy a site—it helped me understand what’s really happening under the hood. I now feel more confident using AWS, setting up secure and production-ready infrastructure, and doing it all in a repeatable, code-first way.

⏭️ What’s Next: Automating Deployment with GitHub Actions

Now that I’ve got the hang of using Pulumi manually, my next weekend goal is to fully automate the deployment process. I want to set up GitHub Actions so that every time I push to the main branch, Pulumi runs and updates the infrastructure automatically.

This would:

Keep my stack always in sync with my latest code
Help avoid manual errors or missed steps
Make the project feel like a real production-grade setup

Excited to explore Pulumi's GitHub Action and see how to manage secrets, handle preview/diff steps, and maybe even set up different stacks for staging and production down the line.

DOM Question #8 - closest interactive element

Shweta Kale — Tue, 04 Mar 2025 05:25:26 +0000

Find the closest interactive element (button, input, link) to a given DOM node.

To find closest element we can use element.closest so it will be something like

const closestInteractiveEl = (node) => {
 return node.closest('button, a, input');
}

But this will only return el if current node or parent nodes are interactive. Because closest traverse till root from current element and returns if selector matches.

According to question we need to find closest interactive element. This can be sibling, children or ancestor.

We can solve this by getting all interactive nodes and their distance from current node. We will return element who has minimum distance from current node. If we have to get distance by traversing DOM this will be a complex problem as calculating distance between two nodes is time consuming task. Instead we will find visual proximity, which means that we will find distance between current and interactive node when they are rendered on the screen.

const findClosestIinteractiveElement = ()=> {
  const interactiveSelectors = ['button', 'a', 'input', '[role="button"]', '[role="link"]','[role="checkbox"]',
    '[role="radio"]'];

  const interactiveElements = Array.from(document.querySelectorAll(interactiveSelectors.join(',')))
}

if(interactiveElements.length===0){
 return {element: null, distance: Infinity};
}

 // Get the position of the reference node
  const nodeRect = node.getBoundingClientRect();
  const nodeCenter = {
    x: nodeRect.left + nodeRect.width / 2,
    y: nodeRect.top + nodeRect.height / 2
  };

let closestElement = null;
let shortestDistance = Infinity;

// finding distance between given and interactive node.
for(const interactiveElement of interactiveElements){
  if(node===interactiveElement || node.contains(interactiveElement)){
    return {node: element, distance: 0}
  }

  const elementRect = interactiveElement.getBoundingClientRect();
  const elementCenter = {
    x: elementRect.left + elementRect.width/2,
    y: elementRect.top + elementRect.height/2
  };

// calculate Euclidian distance
  const distance = Math.sqrt(Math.pow(elementCenter.x-nodeCenter.x, 2) + Math.pow(elementCenter.y - nodeCenter.y, 2))

  if(distance < shortestDistance){
   shortestDistance = distance;
   closestElement = interactiveElement;
  }
}

return {element: closestElement, distance: shortestDistance};

DOM Question #7 - Circular Reference

Shweta Kale — Sun, 02 Mar 2025 13:59:29 +0000

Detect cycles in a DOM tree (circular references)

DOM is a tree which means it should have hierarchical structures, which means it should not have circular reference.

But circular reference can still occur due to

Improper DOM manipulation: eg. If a node's child references the parent node, you would introduce a cycle in what was supposed to be a tree structure.

const parent = document.createElement('div');
const child = document.createElement('div');

// Setting up a circular reference
parent.appendChild(child);
child.appendChild(parent); // This creates a cycle

How can we detect circular reference?

We traverse the DOM and track visited nodes. If we encounter node which is already visited then DOM has circular reference.

function detectCycle(root){
 const visitedNodes = new Set();

 function traverse(node){
  if(visitedNode.has(node)){
    return true;
  }

  visitedNodes.add(node);

  for(let child of node.children){
    if(traverse){
      return true;
    }
  }
 return false;
 }
  return traverse(root)
}

What is time complexity of this code?
To traverse tree we used DFS, so we visit each node once.
Considering N is number of nodes time complexity of this will become O(N)

DOM Question #6 - Serialization

Shweta Kale — Fri, 28 Feb 2025 04:36:04 +0000

Write code to serialize given HTML

Serialization means converting given HTML to JSON format. In the JSON we need to store node name, node type, children, props.

<div id="foo">
  <h1>Hello</h1>
  <p class="bar">
    <span>World!</span>
  </p>
</div>

We will create a function and call it recursively on all HTML children to get JSON data in required format.

function getNodeProps(node){
  let props = {};
  for(let i=0; i< node.attributes.length; i++){
    const attribute = node.attributes[i];
    props[attribute.nodeName] = attribute.nodeValue;
  }
  return props;
}

function serialize(node){
  const serializedJSON = {};
  serializedJSON.nodeName = node.nodeName;
  serializedJSON.nodeType = node.nodeType;

  const props = getNodeProps(node);
  serializedJSON.props = props;

  let children = [];
  if(node.children.length>0){
   for(let i=0; i< node.children.length; i++){
    children.push(serialize(node.children[i]));
   }}
  serializedJSON.children = children;

  return serializedJSON;
}

This will give us serialized JSON but what about time complexity?

Total time complexity: Since the function recursively visits every node in the tree, the total time complexity is proportional to the number of nodes and the number of attributes and children. In the worst case, the time complexity is:

O(N×(A+C))

Where:

N: is the total number of nodes.
A: is the average number of attributes per node.
C: is the average number of children per node.

DOM Challenge #5 Deepest node

Shweta Kale — Tue, 25 Feb 2025 14:38:54 +0000

Find the deepest node in a DOM tree.

To get deepest node in DOM tree we can use Depth first search (DFS).
Considerations ->
We can have multiple nodes at deepest levels or single node as well. So I will consider we need to return first deepest node.

const getDeepestNode = (root) => {
  const stack = [{node: root, depth: 0}];
  let deepestNode = root;
  let maxDepth = 0;
  while(stack.length > 0){
    const {node, depth} = stack.pop();
    if (depth > maxDepth) {
       maxDepth = depth;
       deepestNode = node;
    }
    for (let i=node.children.length - 1; i >= 0; i++){
       stack.push({node: node.children[i], depth: depth + 1})
    }
  }
  return deepestNode;
}

This problem can also be modified to return all nodes at deepest level.

DOM Question #4 All siblings

Shweta Kale — Fri, 21 Feb 2025 17:44:24 +0000

Find all siblings of a given DOM element.

In this question we need to return all siblings so they can have same parent or different, but need to be on same level.

To solve this question BFS will be the most suitable algorithm. We will do level order traversal and return nodes at current level if targetNode exist.


const getRoot = (targetNode )=> {
  let parent = targetNode;
  while(parent.parentElement){
    parent = parent.parentElement;
  }
  return parent;
}

const getSiblings = (targetNode )=> {
  if(!targetNode ) return null;
  const root = getRoot(targetNode);
  const queue= [root, null];
  let nodesAtSameLevel = [];
  let currentLevelIncludeTarget = false;

  while(queue.length > 0){
    const currentN = queue.shift();



    if(currentN === null){
      if(currentLevelIncludeTarget){
        return nodesAtSameLevel;
      }
      nodesAtSameLevel = [];
      if(queue.length) queue.push(null);
    } else {
      if(currentN === targetNode){
         currentLevelIncludeTarget = true;
      } else {
        nodesAtSameLevel.push(currentN);
      }
      queue.push(...currentN.children);
    }
  }
  return [];
}

If we want to return only immediate siblings of given node we can get parentNode and then return all its child nodes after removing targetNode.

Something like


 const getSiblings = (node) => {
  if (!node || !node.parentElement) return [];

  return Array.from(node.parentElement.childNodes).filter((sibling) => sibling !== node);
};

DOM question #3 Distance between two DOM

Shweta Kale — Thu, 20 Feb 2025 17:13:30 +0000

Find the distance (number of edges) between two DOM elements.

We can get distance between given 2 nodes by calculating LCA and then adding the distance between LCA to these two nodes.

So we can write code as

const getParentList = (node)=>{
   const parentList = [node];
let tempNode = node;
  while(tempNode.parentElement){
    parentList.push(tempNode.parentElement);
      tempNode = tempNode.parentElement;
  }

return parentList;
}

const LCA = (node1, node2)=>{
  const parentList1 = getParentList(node1);
  const parentList2 = getParentList(node2);

   for(let i=0; i<parentList1.length; i++){
       const index2 = parentList2.findIndex(item=> item === parentList1[i]);
       if(index2!==-1){
          return index2 + i;
       }
   }
return -1;
}

DOM Challenge #2 nth parent

Shweta Kale — Tue, 18 Feb 2025 14:01:01 +0000

Today's question:

Find the nth parent of a given DOM element.

If input is Div.6 & n is 2 we should output Div.2

Considerations:
1) What if n > number of parents?
In that case we return null.
2) n > 0

Approach:

Get all parentNodes of DOM and return (n-1)th element from array.

Code:

const parentList = (node)=>{
   let tempNode = node;
   const parentNodes = [];
   while(tempNode.parentElement){
     parentNodes.push(tempNode.parentElement);
    tempNode = tempNode.parentElement;
   }
   return parentNodes;
}

const getNthParent = (node, n) => {
   const parentNodes = parentList(node);
   if(n > parentNodes.length){
      return parentNodes[n-1];
   }
  return null;
}

DOM Challenge - #1 common ancestor

Shweta Kale — Mon, 17 Feb 2025 17:16:45 +0000

I'm planning to write around 30 posts covering various questions related to DOM traversal, manipulation, and optimization.

Today's question is related to DOM traversal

Question:
Find the common ancestor of two given DOM elements.

In this question we have DOM tree and we need to find common ancestor of given nodes. The first approach I can think of is collect all parent nodes of both elements and find the first common node.

We can get parentNodes using this method

const parentList = (element)=>{
    let el = element;
   const list = [];
    while(true){
        list.push(el);

        if(!el.parentNode) break;
        el = el.parentNode;
    }

    return list;
}

Now we can use this list to find LCA -


const findLCA = (el1, el2)=>{
    const parentList1 = parentList(el1);
    const parentList2 = parentList(el2);

    for(let i=0; i<parentList1.length; i++){
     if(parentList2.includes(parentList1[i])){
         return parentList1[i];
     } 
    }
    return null;
}

This solution works, but it has a time complexity of O(n²) due to the includes() check inside the loop.

We can improve this by using Set to store parent list, so that we can use parentList2.has(parentList1[i]), this is of O(1) complexity so time complexity for our code will be O(n).

💡 Note: These posts are primarily for my learning and practice. They are not meant as official guides but might be helpful for someone preparing for interviews.

Learning Smart Contract Development using Okashi

Shweta Kale — Mon, 19 Aug 2024 06:41:31 +0000

This is a submission for the Build Better on Stellar: Smart Contract Challenge : Create a Tutorial

Your Tutorial

I worked on creating a tutorial that uses Okashi to explain How Stellar Smart Contract work and create different Smart contracts. This tutorial can be accessed here - link

What I Created

I'm excited to share with you what I've been working on. I've created a beginner-friendly tutorial on Stellar smart contract development using Soroban.

I have included A step-by-step guide covering five different smart contracts, each introducing new concepts:

Basic "Hello World" contract
Multi-method contract with data storage
Increment counter with TTL management
User authentication in smart contracts
Persistent storage implementation

An introduction to the Okashi platform for in-browser smart contract development and testing.
Explanations of key Stellar-specific concepts like contract instances, Time-To-Live (TTL), and different types of storage (temporary, instance, persistent).
A walkthrough of the smart contract deployment process on the Stellar testnet.
Visual aids including screenshots and diagrams to enhance understanding.

I hope that this tutorial will help other developers like me to:
-Get started with Soroban without feeling overwhelmed

Understand when to use different types of storage (trust me, it matters!)
Learn best practices through real-world examples
Feel confident deploying your first smart contract

Journey

Creating this tutorial has been quite the adventure!

When I first started learning about Stellar smart contracts, I found the existing resources a bit scattered. I thought to myself, "Wouldn't it be great if there was a guide that took you from absolute beginner to deploying your first contract?" So, I decided to create the guide I wish I had when I was starting out. It helps in understanding basic concepts without doing any local setup.

I spent a lot of time experimenting with the Okashi. It's such a great tool for learning – being able to test your contract instantly is a game-changer. I wanted to make sure I showcased its capabilities in the tutorial.

Creating each example contract was a learning experience in itself. I'd write a contract, test it, realize I misunderstood something, and then revise. It was a cycle of continuous learning, which I've tried to distill into the tutorial.

Through this process, I've gained a much deeper understanding of Soroban and the Stellar ecosystem. Looking ahead, I'm excited to dive even deeper. I'm thinking about creating more advanced tutorials – maybe something on cross-contract calls or integrating with frontend apps.

This journey helped me to be a bit more confident on web3 development and Stellar. When I started writing this tutorial, I had lot's of confusion like how is backend handled? where is data stored? how can we interact with it? and more silly questions 😂

I'm proud that I can now write a contract and understand different contracts that I come across on github or community.

I would like to give credit to Stella, she was life saver for me. This tutorial is written because she helped me in clarifying all doubts I had as a beginner.

I hope my tutorial helps smooth the path for other new developers entering this exciting space. Happy coding, everyone!

Thank you and hope you give the tutorial a read too, here's the link - https://dev.to/shweta/crafting-stellar-smart-contracts-learn-by-creating-smart-contracts-in-browser-5gg5

Crafting Stellar Smart Contracts: Learn by creating Smart Contracts in browser

Shweta Kale — Mon, 19 Aug 2024 06:19:38 +0000

Hey there!👋 Thank you for opening this blog, its my attempt to help everyone understand stellar blockchain as I learn the concepts.
By end of this blog, we'll have built five smart contract, right in your browser. No complicated setup, no downloads, - just you, this blog, and some code. Let's get started!

What's a Smart Contract Anyway?

Imagine a vending machine. You put in a coin, press a button, and out comes your snack. Now, picture that vending machine running on a blockchain, handling not just snacks, but any kind of digital transaction you can think of. That's essentially what Smart Contract does!

In technical terms, a smart contract is a self executing program that lives on blockchain. It automatically makes things happen when certain conditions are met. Here's why this is cool:

They're Transparent: Everyone can see the rules (i.e the code and associated transactions), so there are no surprises.
They're Trustworthy: Once a smart contract is deployed on blockchain, it can't be changed. What you see is what you get😄
They're Efficient: They cut out middlemen, making transactions faster and cheaper.
They're Permissionless: Anyone can write a smart contract and deploy it.

Now, Stellar has its own flavor of smart contract, and that's what we are going to learn today. Stellar's smart contract platform is called Sorban, and its designed to be simple, fast, and developer-friendly.

The best part? We are going to write this smart contract in Rust on Browser, to do that we are going to use Okashi platform. Don't worry if you are new to Rust - we'll cover everything you need to know.

Rust basics for Stellar Smart Contract

For writing Stellar Smart Contracts we make use of Rust. Rust is a systems programming language that emphasizes safety, concurrency, and performance. Here are some key Rust concepts you'll frequently use in Soroban development:

Structs: Define custom data types, similar to classes in other languages.

struct MyStruct {
    field1: Type1,
    field2: Type2,
}

Impl Blocks: Used to implement methods for Structs.

impl MyStruct {
    fn my_method(&self) {
        // method body
    }
}

Functions: Defined using the fn keyword.

fn greet(env: Env, arg1: Symbol) -> String {
    // Method body
}

Attributes: Metadata applied to code elements, starting with #

#[contract]
struct MyStruct {}

These are just four basic ... related to Rust that we need to know to get started.

Sorban Structure, Data Type and Imports

Soroban is Stellar's smart contract platform. It uses Rust with some specific structures and types that includes:
1. No Standard Library:
Sorban Contracts typically start with #![no_std] to indicate they don't use Rust standard library. We do this to make smart contract smaller and more efficient.

#![no_std]
// Now we're writing a lean, Stellar-ready contract!

2. Importing Sorban SDK:
We need to bring in special Stellar tools. We do this by importing from the Stellar SDK.

use sorban_sdk::{contract, impl, Env};
// Now we've access to Stellar specific features.

3. Contract Structure:

Contract are defined as Struct with the #[contract] attribute.
Functions are implemented in an impl block with the #[contractimpl].

#[contract]
pub struct ContractName {}

#[contractimpl]
impl ContractName {
}

4. Important Data Types:
a) Env
Env is like smart contract's connection to Stellar World. It let's us access storage, call other imports and more.

use sorban_sdk::{Env};

pub fn my_function(env: Env) {
let current_ledger = env.ledger().sequence();
}

b) Symbol
Symbol is a special, efficient type for short strings. It is often used as keys in storage.

use sorban_sdk::{symbol, Symbol};

let my_symbol: Symbol = symbol!("hello");

c) String
This is similar to Rust's standard String, but optimized for Sorban

d) SymbolShort
This is a way to create Symbols at compile-time, which is even more efficient.

use soroban_sdk::{symbol_short};

const MY_KEY: Symbol = symbol_short!("key");

This was just an overview, to get you familiar with the terms and syntax. Don't worry if you didn't understood the keywords and its usage. By end of this tutorial you definitely will.

Our First Smart Contract

Now that we have basic understanding, let's write our "Hello World" contract step by step.

Step 1: The Contract Structure -

#![no_std]
use soroban_sdk::{contract, contractimpl, String, vec, Env, Vec};

#[contract]
pub struct HelloContract;

#[contractimpl]
impl HelloContract {
    // We'll add our functions here
}

Explanation:

We start with #![no_std] to indicate we're not using the standard library.
We import necessary items from soroban_sdk.
We define our contract struct HelloContract and mark it with #[contract].
We start an implementation block for HelloContract and mark it with #[contractimpl].

Its all same thing that we learned above, we have just put the blocks together.

Step 2: Implementing the method

The code we saw above was just structure, without including any public function in it the code does not have any meaning even if we deploy it.

 pub fn greeting_from(env: Env, from: String) -> Vec<String> {
    vec![&env, String::from_str(&env, "Hello, I'm "), from]
 }

Explanation:

We created a public function called greeting_from which has two arguments - Env and from.
-> Vec<String> signifies that we are returning a vector of type String, with text "Hello, I'm " and input user entered.

Putting it together we will have:

#![no_std]
use soroban_sdk::{contract, contractimpl, String, vec, Env, Vec};

#[contract]
pub struct HelloContract;

#[contractimpl]
impl HelloContract {
    pub fn greeting_from(env: Env, from: String) -> Vec<String> {
      vec![&env, String::from_str(&env, "Hello, I'm "), from]
    }
}

Step 3: Running Smart Contract on Okashi

Okashi is a place where we can experiment with our stellar smart contract in browser, so no need to setup any code locally.
It's like a digital workspace with three main sections:

Code Window: Where we will write our smart contract.
Contract Window: Calling the functions from our smart contract.
Console Window: Show us result of our experiment, i.e output.

To try the code we wrote
a) Go to Okashi.dev playground.
b) Paste the code in code section.
c) Click on Compile.
d) In the contract window you should see a method greeting_from, click on it and enter input in modal.
e) You will see the output in the Console window.

You can also see the output in this link.
Congratulations!🎉 You've just written your first Soroban smart contract in Rust.

Second Smart Contract - Creating multiple methods in one contract.

For our second smart contract we will work on creating more that one method in contract and learn how to access it.

Let's try creating a new smart contract TitleContract which has two methods

set_title: Get's input from user and save the title.
get_title: Returns input user entered.

Step 1: Basic structure

#![no_std]
use soroban_sdk::{contract, contractimpl, symbol_short, Env, Symbol, String};


#[contract]
pub struct TitleContract;

#[contractimpl]
impl TitleContract {
    pub fn set_title(env: Env, title: String) {
    }

    pub fn get_title(env: Env) -> String {
    }
}

As mentioned in task we have two methods get_title and set_title, the structure is similar to first contract.

Step 2: Implementing the methods

Before we implement the method we need to understand basics of data storage in stellar smart contract.

Smart Contract Storage in Stellar:
Smart contract storage in Stellar is designed to accommodate a wide range of uses affordably. It's primarily used for storing data related to the state and functionality of smart contracts deployed on the Soroban platform.

To store the data we need to have a key using which we can identify the data stored to use it.
Data in storage can be set using set method and retrieved using get method.

In Stellar we have three type of storage
a) Temporary Storage - Temporary storage is ideal for data that is only needed for a short period and can be discarded afterwards without consequences. It's the cheapest option but has a limited lifespan.

Example: A contract that stores the recent price of BTC against USD.

Can be accessed using -

// save the VALUE in temporary storage using set with key as KEY
env.storage().temporary().set(KEY, VALUE)

// get the VALUE from temporary storage using key, KEY
env.storage().temporary().get(KEY)

b) Persistent Storage - Persistent storage is used for long-term data storage. When the TTL (Time to Live) reaches zero, the data is archived rather than deleted and can be restored when needed.

Example: A loyalty points system where users accumulate points.

Can be accessed using -

// save the VALUE in persistent storage using set with key as KEY
env.storage().persistent().set(KEY, VALUE)

// get the VALUE from persistent storage using key, KEY
env.storage().persistent().get(KEY)

c) Instance Storage - Instance storage is a type of storage that is tied directly to the contract instance itself.

Example: A voting system where each contract instance represents a unique vote.

Can be accessed using -

// save the VALUE in instance storage using set with key as KEY
env.storage().instance().set(KEY, VALUE)

// get the VALUE from instance storage using key, KEY
env.storage().instance().get(KEY)

We will understand this more in next examples, For this example we will use instance storage.

Creating Key for Storage in our contract

We will create key, TITLE to access instance storage

const TITLE: Symbol = symbol_short!("title");

Saving and Retrieving Title data

// set_title
env.storage().instance().set(&TITLE, value);

// get_title
env.storage().instance().get(&TITLE).unwrap_or(String::from_str(&env, "No Title Set"));

In above code we are setting instance storage with key TITLE
We are retrieving it using get() and if no value is present we return a default title "No Title Set" using unwrap_or.

Step 3: Putting it together

#![no_std]
use soroban_sdk::{contract, contractimpl, symbol_short, Env, Symbol, String};

const TITLE: Symbol = symbol_short!("title");

#[contract]
pub struct TitleContract;

#[contractimpl]
impl TitleContract {
    pub fn set_title(env: Env, title: String) {
        env.storage().instance().set(&TITLE, &title);
    }

    pub fn get_title(env: Env) -> String {
        env.storage().instance().get(&TITLE).unwrap_or(String::from_str(&env, "No title set"))
    }
}

In above code set_title accepts argument called title and sets it with instance storage.
In get_title we retrieve the key and return the value present, if value is not present we return default value.

Step 4: Testing code in Okashi.dev

Paste the code in Okashi playground and click on Compile.
The contract window should have two methods.

If you click on get_title you should see default value in console.
Now set title by clicking on set_title and click on get_title. You should see the title you entered.

Yep, that's it. We have our second smart contract working fine. I know you might have some doubt about storage, different types available and why did we select instance storage. I've been there too, it would be much clearer before we end this blog, so for now let us keep basic in mind - Smart contract have three type of storage - In our TitleContract, we used instance as we only want to use it till the contract instance is active.

You can try the code here: https://okashi.dev/playground/btpyseknmnjmhfedbrxilgirhnvo

Congratulations!🎉 We have worked on creating smart contract with two methods and learned about different types of smart contract storage and used instance storage.

Our Third Smart Contract

Let us create a new smart contract that use instance storage to increment counter.

You need to create a new Smart Contract - IncrementCounterContract. This contract should have one public method called as increment and a key which you will use for saving and retrieving data from instance storage

Step 1: Coding the contract

This part is similar to second contract we wrote, so let's create contract, it should be a good revision for us.

#![no_std]
use soroban_sdk::{contract, contractimpl, Env, symbol_short, Symbol};
const COUNTER: Symbol = symbol_short!("COUNTER");

#[contract]
pub struct IncrementContract;

#[contractimpl]
impl IncrementContract {

    pub fn increment(env: Env, value: u32) -> u32 {

        let mut count: u32 = env.storage().instance().get(&COUNTER).unwrap_or(0);

        // Increment the count.
        count += value;

        // Save the count.
        env.storage().instance().set(&COUNTER, &count);

        // Return the count to the caller.
        count
    }
}

In above code we have method increment, which return integer value, i.e count.

Step 2 Understanding contract instance and TTL

Well, the contract we wrote above is fine but with instance storage, the contract storage and its instance have default lifetime determined by network's minimum time to live(TTL) for contract's instance.

To handle that we need to extend the time to live (TTL) for the instance storage. Before doing that let's first understand technical terms I mentioned above

Contract Instance:

A contract instance refers to a deployed smart contract on the Stellar network. When you deploy a contract, you're creating an instance of that contract on the blockchain. This instance has its own unique identifier and can maintain its own state.

Example:
Let's say you deploy a token contract. This deployed contract becomes an instance, and it can have its own storage, including things like:

The token's name
Total supply
Administrator address

Time To Live (TTL)

Contract instances on Stellar have an archival TTL (Time-To-Live) that determines how long they remain active. This TTL is tied to the contract instance itself.

A contract instance becomes inactive when its TTL expires. However, it's important to note that the TTL can be extended to keep the contract instance active for a longer period.

We are using Instance Storage. As we discussed above anything stored in instance storage has an archival TTL that is tied to the contract instance itself. So, if a contract is live and available, the instance storage is guaranteed to be so, too.

Now, we will learn how to prevent instance storage from expiring and extend its TTL

Extending Instance Storage TTL

env.storage().instance().extend_ttl(50, 100);

This line of code is used to extend the Time-To-Live (TTL) of the contract's instance storage. Here's how it works:

It extends the TTL by 50 ledgers.
It sets a minimum TTL of 100 ledgers.

What this means:

If the current TTL is less than 100 ledgers, it will be set to 100.
If the current TTL is already 100 or more, it will be extended by 50 ledgers.

This operation ensures that the contract instance and its associated instance storage remain active and accessible for at least the specified number of ledgers.

To summarize:

Contract instances become inactive when their TTL expires.
The TTL is tied to the contract instance and its associated data.
Developers can extend the TTL to keep contract instances active for longer periods.

By managing the TTL, developers can control how long their contract instances remain active on the Stellar blockchain.

Let's add relevant code in our contract

#![no_std]
use soroban_sdk::{contract, contractimpl, log, symbol_short, Env, Symbol};


const COUNTER: Symbol = symbol_short!("COUNTER");

#[contract]
pub struct IncrementContract;

#[contractimpl]
impl IncrementContract {
    /// Increment increments an internal counter, and returns the value.
    pub fn increment(env: Env, value: u32) -> u32 {
        // Get the current count.
        let mut count: u32 = env.storage().instance().get(&COUNTER).unwrap_or(0); // If no value set, assume 0.
        log!(&env, "count: {}", count);

        // Increment the count.
        count += value;

        // Save the count.
        env.storage().instance().set(&COUNTER, &count);

        // The contract instance will be bumped to have a lifetime of at least 100 ledgers if the current expiration lifetime at most 50.
        // If the lifetime is already more than 100 ledgers, this is a no-op. Otherwise,
        // the lifetime is extended to 100 ledgers. This lifetime bump includes the contract
        // instance itself and all entries in storage().instance(), i.e, COUNTER.
        env.storage().instance().extend_ttl(50, 100);

        // Return the count to the caller.
        count
    }
}

You can access the code in this playground -
https://okashi.dev/playground/bcjohutecdojquhnafveonzkttxk

Step 3: Compiling the contract

Simply copy paste the code in Okashi playground, and click on Compile.
Vola!! You can test your increment counter and it should work just fine.

Try reloading the playground, and run the method again. Counter starts from zero. Why? because we did not deploy the contract and its running in a mock environment.

Well we did compile this and all our previous smart contract. Does that mean its available on blockchain?
Not really, To make it available on blockchain we will deploy it on testnet. Let's do that in next step.

Step 4: Deploying Smart Contract on Okashi

Did we not deploy our contract earlier?
No, Okashi allows you to run and test your contract locally without deploying it to the actual network. This is incredibly useful for development and testing purposes.

What does it mean that we deploy our contract?
Deploying a contract means uploading your smart contract code to the blockchain and making it available for interaction. It's essentially the process of putting your contract "live" on the network. Here's what happens when you deploy a contract:

The contract's compiled WebAssembly (Wasm) code is uploaded to the network.
A unique contract ID is generated for your deployed contract.
The contract becomes accessible and can be interacted with by users or other contracts.

Deployment in Sorban
In Sorban deployment is typically a two-step process:

Install: This install the contract's WASM bytecode to the network.
Deploy: This creates instance of contract with unique contract ID.

To deploy smart contract on testnet simply click on settings icon in left panel and select testnet as shown in above image.

Hurray!!! Now we have completed 3 contracts, and learned to deploy it on the network so that even other users can interact with it.
All this in browser. Isn't that great??

Our Fourth Smart Contract - User Authentication

Picture this, instead of increment counter you have a balance book where balance increase and decrease. We only have one balance so anyone who run this method the balance will be affected. Huhh, so everyone has a common balance? That's not correct right?

To handle this we will use user authentication to our increment counter code.

In stellar we can use user.require_auth() to make sure user has authenticated the transaction.

Step 1: Adding `require_auth` in code

a) Update imports from sdk to import Address.
b) Accept one more argument from increment method called user of type Address.
c) Add user.require_auth() before we perform any computation or updates.

 pub fn increment(env: Env, user: Address, value: u32) -> u32 {
user.require_auth();
// other code remain same
        }

You can access code here - https://okashi.dev/playground/buscouoocaofizhsoeddwufiiwke

What does this mean? It means that whenever increment is called, user is authenticating to make the change.

d) Compile contract and run the increment method. You will notice that you have a new field as input -> some user options.
Select one user, Alex and click on call.

So, our code complied successfully and we have output. Are we done?
No not at all, we just implemented user authentication. All the data is stored in same key. If you try calling increment again, this time select Bart. The value is updated with count Alex had. We don't want this to happen!!

To handle this we need unique key for each user. Let's do that in second step.

Step 2: Adding unique key for each user

Instead of having a same key, i.e COUNTER. Let's use User's address as a key to store the increments. We can do that by replacing current key with &user.clone()

.clone() is called on user to create a new copy of the address. This is necessary if user is not owned by this part of the code or if it needs to be used elsewhere after this operation.

        env.storage().instance().set(&user.clone(), &count);

This is complete code for your reference

#![no_std]
use soroban_sdk::{contract, contractimpl, log, Env, Address};

#[contract]
pub struct IncrementContract;

#[contractimpl]
impl IncrementContract {
    /// Increment increments an internal counter, and returns the value.
    pub fn increment(env: Env, user: Address, value: u32) -> u32 {
user.require_auth();

        // Get the current count.
        let mut count: u32 = env.storage().instance().get(&user.clone()).unwrap_or(0); // If no value set, assume 0.
        log!(&env, "count: {}", count);

        // Increment the count.
        count += value;

        // Save the count.
        env.storage().instance().set(&user.clone(), &count);


        // Return the count to the caller.
        count
    }
}

Step 3: Compile and deploy the code

You can use Okashi to test the code and check if it works fine.
If you call increment from one user, Alex, it should not affect value stored in other user.
You can access the code here- https://okashi.dev/playground/asuxzxwasubvfypwzyqhaqyfgywz

Our Fifth Smart Contract

This is last contract we are going to discuss for this blog.
Till now we

understood smart contract structure
Learned three type of smart contract storage
used instance storage to implement increment counter and title contract
Learned about Contract instance and TTL.
Learned how to use authentication in contract
Deployed our contract on Testnet

That's a lot we covered in this blog, but I'm sure you are still confused between instance storage and persistent storage.
This is our chance to understand proper difference between these two.

In our fourth smart contract we used user authentication, so many users can use same contract and each will have their separate counter as we have unique key. Everything seems to be correct right?
Not exactly, this works but in this case we can use persistent storage as
instance storage wouldn't work well for this use case:

a) Limited Storage: Instance storage has a limited amount of space. With a growing number of users, you could quickly run out of storage.

b) Performance Impact: Every piece of data stored in instance() storage is retrieved from the ledger every time the contract is invoked. Even if the invoked function does not interact with any ledger data at all.
This means that as your user base grows, contract invocations would become increasingly expensive and slower, as all counts would be loaded each time.

Persistent storage is ideal for this scenario because it allows for efficient storage and retrieval of individual user data, scales well with a growing user base, and ensures data availability regardless of the contract instance's active status.

Converting our code to use persistent storage is easy, you just need to replace instance storage with persistent storage and its done.
Here is complete code for your reference -

#![no_std]
use soroban_sdk::{contract, contractimpl, log, symbol_short, Env, Symbol, Address};


const COUNTER: Symbol = symbol_short!("COUNTER");

#[contract]
pub struct IncrementContract;

#[contractimpl]
impl IncrementContract {
    /// Increment increments an internal counter, and returns the value.
    pub fn increment(env: Env, user: Address, value: u32) -> u32 {
user.require_auth();

        // Get the current count.
        let mut count: u32 = env.storage().persistent().get(&COUNTER).unwrap_or(0); // If no value set, assume 0.
        log!(&env, "count: {}", count);

        // Increment the count.
        count += value;

        // Save the count.
        env.storage().persistent().set(&COUNTER, &count);


        // Return the count to the caller.
        count
    }
}

You can try the code here- https://okashi.dev/playground/caavrhvfctirmkryboblgxkwxshl

Conclusion

That was a longest blog I have ever written, and I really learned a lot of stuff while writing this blog.

In this blog we learned:

The basics of smart contracts and their importance in blockchain technology
Fundamental Rust concepts used in Soroban development
How to structure Soroban smart contracts
Different types of storage in Stellar smart contracts (temporary, persistent, instance)
How to implement multiple methods within a single contract
The concept of contract instances and Time To Live (TTL)
How to use user authentication in smart contracts
The process of deploying smart contracts on the Stellar testnet
When to use persistent vs instance storage for scalability

With this knowledge, we can start working on more complex Stellar smart contracts, such as:

Token systems
Decentralized exchanges
Voting systems
Multi-signature wallets
Cross-chain atomic swaps

The examples we explored were adapted from https://github.com/stellar/soroban-examples, which is an excellent resource for further learning and experimentation.

This tutorial aimed to provide a solid foundation for beginners to start their journey into Stellar smart contract development. Would love to hear your feedback and thoughts!

Remember, the best way to learn is by doing. So don't hesitate to experiment with the concepts we've covered, modify the example contracts, and create your own unique smart contracts on the Stellar network. Happy coding!

DEV Community: Shweta Kale

Fluencr - Find Instagram Influencer For your brand

🧠 AI-Powered Influencer Discovery Engine

What I Built

Demo

How I Used Bright Data's Infrastructure

🔍 Discover – Crawler-Based Search

🧭 Access – Platform Navigation with JS Rendering

📥 Extract – Scraping Key Data

Performance Improvements

Tech Stack

App Flow: From Brand Brief to Influencer Match

Final Thoughts

🎨 Come Build and Deploy a Random Color Generator with Me Using Next.js, AWS, and Pulumi

What I Built

Live Demo Link

Project Repo

raibove / random-color-generator

Generate random color

🎨 Random Color Generator

🚀 Live Demo

📁 Project Structure

📸 Preview

⚙️ How It Works

🛠️ Deployment Using Pulumi

1. S3 Bucket (Private)

2. CloudFront Distribution

My Journey

🧪 Step 1: Let’s Build Something Simple

🌐 Step 2: Hosting Static Files with AWS S3

🔐 Step 3: Oh No—Access Denied?!

🛡️ Step 4: Enter CloudFront – Secure + Fast

🌍 Step 5: Create a CloudFront Distribution to Serve Your Website Globally

✨ Step 6: Refactoring Pulumi Static Site Deployment: From Complex to Clean with BucketV2

Using Pulumi 🛠️

⏭️ What’s Next: Automating Deployment with GitHub Actions

DOM Question #8 - closest interactive element

DOM Question #7 - Circular Reference

DOM Question #6 - Serialization

DOM Challenge #5 Deepest node

DOM Question #4 All siblings

DOM question #3 Distance between two DOM

DOM Challenge #2 nth parent

DOM Challenge - #1 common ancestor

Learning Smart Contract Development using Okashi

Your Tutorial

What I Created

Journey

Crafting Stellar Smart Contracts: Learn by creating Smart Contracts in browser

What's a Smart Contract Anyway?

Rust basics for Stellar Smart Contract

Sorban Structure, Data Type and Imports

Our First Smart Contract

Step 1: The Contract Structure -

Step 2: Implementing the method

Step 3: Running Smart Contract on Okashi

Second Smart Contract - Creating multiple methods in one contract.

Step 1: Basic structure

Step 2: Implementing the methods

Step 3: Putting it together

Step 4: Testing code in Okashi.dev

Our Third Smart Contract

Step 1: Coding the contract

Step 2 Understanding contract instance and TTL

Contract Instance:

Time To Live (TTL)

Extending Instance Storage TTL

Step 3: Compiling the contract

Step 4: Deploying Smart Contract on Okashi

Our Fourth Smart Contract - User Authentication

Step 1: Adding require_auth in code

Step 2: Adding unique key for each user

Step 3: Compile and deploy the code

Our Fifth Smart Contract

Conclusion

Step 1: Adding `require_auth` in code