DEV Community: vimuth

How to Implement Stripe Payments with Payment Intents and Webhooks for Complete Payment Flow Management

vimuth — Thu, 03 Apr 2025 13:11:45 +0000

In today’s digital economy, integrating a reliable payment gateway is crucial for any online business. Stripe, one of the most popular payment processing platforms, offers a powerful solution for handling payments securely and efficiently. In this tutorial, we'll walk you through how to implement Stripe Payments using Payment Intents and Webhooks.

1. Starting the Project:

To kick things off, we’ll begin by setting up a basic Node.js project. I’ve already created the project and initialized it in Git, so we won’t need to go through the setup steps from scratch. Let’s jump straight into the implementation of Stripe payment integration.

"https://github.com/vimuths123/stripeapp.git" this repos has a branch called initial_project. This has a simple node project with this structure

stripe-payment/
│── public/
│ └── index.html (Frontend)
│── .env (Environment variables)
│── package.json (Project metadata)
│── server.js (Backend server)

And it has installed all packages needed like "body-parser", "cors", "dotenv", "express", "stripe", "nodemon"

2. Implementing Stripe Payment Intents

In this section, we will create a Payment Intent on the server-side to handle the payment process securely. The Payment Intent represents your intent to collect a payment and manages the complexities of authentication and authorization, like 3D Secure.

1. Set up the Environment

Before we create the Payment Intent, make sure you have added your Stripe API keys in the .env file. You can find your keys in the Stripe Dashboard.

In the .env file, add the following:

STRIPE_SECRET_KEY=your_stripe_secret_key
STRIPE_PUBLISHABLE_KEY=your_stripe_publishable_key

2. Create the Payment Intent Route

In your server.js file, we’ll create an endpoint that will handle creating the Payment Intent. When a client sends a payment request, this endpoint will interact with Stripe to create a Payment Intent and return the client secret to the frontend.

Open the server.js file and add the following code to create the Payment Intent:

const express = require("express");
const bodyParser = require("body-parser");
const cors = require("cors");
const stripe = require("stripe")(process.env.STRIPE_SECRET_KEY);

const app = express();

// Middleware
app.use(cors());
app.use(bodyParser.json());

// Create Payment Intent endpoint
app.post("/create-payment-intent", async (req, res) => {
  try {
    const { amount, currency } = req.body;

    // Create Payment Intent
    const paymentIntent = await stripe.paymentIntents.create({
      amount: amount * 100, // Convert to cents
      currency: currency,
    });

    // Send the client secret to the client
    res.send({
      clientSecret: paymentIntent.client_secret,
    });
  } catch (error) {
    res.status(500).send({
      error: error.message,
    });
  }
});

// Start the server
const port = process.env.PORT || 5000;
app.listen(port, () => {
  console.log(`Server running on port ${port}`);
});

Here you can see we take stripe secret from .env and create stripe object to get the payment intent

const stripe = require("stripe")(process.env.STRIPE_SECRET_KEY);

And

const paymentIntent = await stripe.paymentIntents.create({
      amount: amount * 100, // Convert to cents
      currency: currency,
    });

Now, you can test the server by running:

npm run dev

You can se the code until this with "backend_payment_intent" branch or previous repo.

3. Frontend Implementation: Handling Stripe Payment

In this section, we will build the frontend to collect payment information from the user and complete the payment using Stripe's Payment Intent.

I have added a page called public/index.html in root. But to populate this we need to do a small change in server.js

const path = require('path');

// Serve static files from the 'public' folder
app.use(express.static(path.join(__dirname, 'public')));

This line of code is used to serve static files (such as HTML, CSS, JavaScript, images, etc.) from a specific folder, in this case, the public folder.

Now if we run 'http://localhost:5000/' this index.html file will be shown in browser.

1. Add Stripe.js to Your HTML

First, we need to include Stripe.js in the

section of your index.html file. This script will provide the necessary functions to interact with Stripe on the client side. You can see this index.html in git repo.

<script src="https://js.stripe.com/v3/"></script>

2. Get the payment intent and confirm payment

Upon clicking the button, we make a request to the previously created endpoint, passing the payment amount and currency. The server responds with the payment intent ID, which includes the Stripe secret.

let response = await fetch("http://localhost:5000/create-payment-intent", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ amount: amount, currency: "usd" }),
});

These lines retrieve the payment intent's client secret from the server response and then use it to confirm the payment with Stripe.

let { clientSecret } = await response.json();

let { paymentIntent, error } = await stripe.confirmCardPayment(clientSecret, {
    payment_method: { card: cardElement },
});

Flow:
1. Backend creates a PaymentIntent: The server creates a PaymentIntent and returns a clientSecret.

2. Frontend confirms the payment: The frontend uses the clientSecret to confirm the payment by calling stripe.confirmCardPayment() with the user's card details.

3. Success or error: If the payment is successful, the paymentIntent is returned, which contains the payment details. If the payment fails, the error is returned, and you can handle it accordingly (e.g., showing an error message).

You can find changes upto this point with frontend_implementation git branch.

3. Save the data with stripe webhook.

Now we may need to save data to the db or add a record that payment happened. Now we can do it by sending ajax call from front end. But that have issues.

Users can change the payment amount and send or user may close the window before the axios call and also another axios call may slow the user experience. So best way is letting stripe call the webhook url.

let's add one more endpoint to server.js

app.use("/webhook", express.raw({ type: "application/json" })); // Webhook requires raw body


app.post("/webhook", express.raw({ type: "application/json" }), (req, res) => {
    const sig = req.headers["stripe-signature"];

    let event;
    try {
        // Use req.body directly (raw Buffer) for signature verification
        event = stripe.webhooks.constructEvent(req.body, sig, process.env.STRIPE_WEBHOOK_SECRET);
    } catch (err) {
        console.error("Webhook signature verification failed:", err.message);
        return res.status(400).send(`Webhook Error: ${err.message}`);
    }

    console.log("Webhook received:", event.type);

    res.json({ received: true });
});

Now we have two ways of adding stripe webhook. If we have a server then we can get this endpoint and add it here.

https://dashboard.stripe.com/test/webhooks

After that we can get 'STRIPE_WEBHOOK_SECRET' and add it to .env. But if you are using localhost you need to add Stripe CLI and run webhook from here.

4. Run with Stripe CLI

First you need to install the stripe CLI. Since I use windows I get it from here

https://docs.stripe.com/stripe-cli?install-method=windows

You just have to copy the extracted data to a folder and give environment variable

Then run this

stripe listen --forward-to http://localhost:5000/webhook

That is it. Happy coding.

Automate Laravel Deployment on Hostinger with GitHub Actions: A Step-by-Step Guide

vimuth — Sun, 26 Jan 2025 10:36:09 +0000

Previously I added a blog on deploying a laravel application on Hostinger. This is an extension on this.

This is the previous article. - Effortless Laravel Deployment on Hostinger Using Git: A Step-by-Step Guide

GitHub Actions is a powerful automation tool that allows you to streamline your development workflow. When you push a change to a GitHub repository branch, GitHub can automatically trigger a workflow to deploy that branch to your server. This seamless process ensures continuous integration and deployment without manual intervention.

Creating a Deployment Script for GitHub Actions

Let's create a deploy.sh file and add all the necessary laravel related commands here.

First login via SSH and go to your site location

cd /home/youruser/domains/yourdomain.hostingersite.com

Then create deploy.sh file.

nano deploy.sh

Add this to file

#!/bin/bash

# Define a function to check the status of the last executed command
check_status() {
    if [ $? -eq 0 ]; then
        echo "✅ $1 succeeded."
    else
        echo "❌ $1 failed."
        exit 1
    fi
}

composer2 install --no-interaction
check_status "Composer Install"

npm install
check_status "NPM Install"

npm run build
check_status "NPM Run Build"

# Run migrations
php artisan migrate --force
check_status "PHP Artisan Migrate"

# Run database seeders
php artisan db:seed --force
check_status "PHP Artisan DB Seed"

# Clear caches
php artisan config:clear
check_status "PHP Artisan Config Clear"

php artisan cache:clear
check_status "PHP Artisan Cache Clear"

php artisan view:clear
check_status "PHP Artisan View Clear"

php artisan route:clear
check_status "PHP Artisan Route Clear"

# Rebuild caches
php artisan config:cache
check_status "PHP Artisan Config Cache"

php artisan route:cache
check_status "PHP Artisan Route Cache"

php artisan view:cache
check_status "PHP Artisan View Cache"

echo "✅ Deployment complete."

You will see all the Laravel commands here.

Create the GitHub Actions workflow file

Let's create a GitHub Actions workflow file that automates the deployment of your project to a Hostinger server whenever changes are pushed to a particular branch

Add this file to you github repo .github\workflows\maindeploy.yml. And add this content

name: Deploy to Hostinger Server

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout repository
      uses: actions/checkout@v3

    - name: Install sshpass (if using password authentication)
      run: sudo apt-get install -y sshpass

    - name: Deploy to Hostinger via SSH with custom port
      env:
        HOSTINGER_IP: ${{ secrets.HOSTINGER_IP }}
        HOSTINGER_PORT: ${{ secrets.HOSTINGER_PORT }}
        HOSTINGER_USERNAME: ${{ secrets.HOSTINGER_USERNAME }}
        HOSTINGER_PASSWORD: ${{ secrets.HOSTINGER_PASSWORD }}
      run: |
        # Specify custom port with -P for scp
        sshpass -p "$HOSTINGER_PASSWORD" scp -P $HOSTINGER_PORT -o StrictHostKeyChecking=no -r * $HOSTINGER_USERNAME@$HOSTINGER_IP:/home/youruser/domains/yourdomain.hostingersite.com

        # Specify custom port with -p for ssh
        sshpass -p "$HOSTINGER_PASSWORD" ssh -p $HOSTINGER_PORT -o StrictHostKeyChecking=no $HOSTINGER_USERNAME@$HOSTINGER_IP "cd /home/youruser/domains/yourdomain.hostingersite.com && bash deploy.sh"

You can see "/home/youruser/domains/yourdomain.hostingersite.com" in two places. You must change this to your actual location. More about this you can find in first video.

And remember that here you are using default main branch. if you need change the branch here

on:
  push:
    branches:
      - main

Add repository secret values

You can see this section

env:
        HOSTINGER_IP: ${{ secrets.HOSTINGER_IP }}
        HOSTINGER_PORT: ${{ secrets.HOSTINGER_PORT }}
        HOSTINGER_USERNAME: ${{ secrets.HOSTINGER_USERNAME }}
        HOSTINGER_PASSWORD: ${{ secrets.HOSTINGER_PASSWORD }}

You must add these values as github repository secrets. Let me show how. First go to repository and got to Settings -> Secrets and variables -> Actions and you can add these values.

That's it and when you see the actions tab you can see the action status.

Thanks and that's all you have to do.

Building a Simple Laravel App with Reverb: A Step-by-Step Guide

vimuth — Sat, 25 Jan 2025 08:51:20 +0000

Laravel is a powerful PHP framework known for its elegant syntax and developer-friendly features. Reverb, Laravel’s real-time event broadcasting system, makes it easy to integrate live updates into your applications. In this guide, we’ll walk through building a simple Laravel app with Reverb, showing how to set up real-time functionality step by step. Whether you're new to Laravel or looking to explore real-time features, this tutorial will help you get started quickly.

Install laravel

First let's install laravel.

composer create-project --prefer-dist laravel/laravel reverbapp

And inside reverbapp folder add php artisan serve and test the app.

Install Reverb

Let's install reverb. Give yes to all prompts appear. They will install reverb PHP packages and Node packages like echo and pusher-js

php artisan install:broadcasting

Now you can see inside .env these settings.

BROADCAST_CONNECTION=reverb
REVERB_APP_ID=981064
REVERB_APP_KEY=oi4rnynjhmgd5vvz024v
REVERB_APP_SECRET=uxtmtcqs30kh2vcqpt58
REVERB_HOST="localhost"
REVERB_PORT=8080
REVERB_SCHEME=http

VITE_REVERB_APP_KEY="${REVERB_APP_KEY}"
VITE_REVERB_HOST="${REVERB_HOST}"
VITE_REVERB_PORT="${REVERB_PORT}"
VITE_REVERB_SCHEME="${REVERB_SCHEME}"

Building the App

Lets create the event

php artisan make:event MessageSent

We'll modify this event to broadcast a simple $message object via 'public-messages' public channel. Here is the code

<?php

namespace App\Events;

use Illuminate\Broadcasting\InteractsWithSockets;
use Illuminate\Broadcasting\PrivateChannel;
use Illuminate\Broadcasting\Channel; // Public Channel
use Illuminate\Contracts\Broadcasting\ShouldBroadcast;
use Illuminate\Foundation\Events\Dispatchable;
use Illuminate\Queue\SerializesModels;

class MessageSent implements ShouldBroadcast
{
    use Dispatchable, InteractsWithSockets, SerializesModels;

    public $message;

    public function __construct($message)
    {
        $this->message = $message;
    }

    // Broadcast via public channel
    public function broadcastOn()
    {
        return new Channel('public-messages');
    }

    public function broadcastAs()
    {
        return 'message.sent';
    }
}

Let's create two routes and a view in Laravel:

One route to send data
One route with a view to receive data

This is send route

use Illuminate\Support\Facades\Route;
use App\Events\MessageSent;

Route::get('/send-message', function () {
    // Sending a simple object instead of a model
    $message = [
        'user' => 'John Doe',
        'text' => 'Hello from Laravel Reverb!',
        'timestamp' => now()->toDateTimeString(),
    ];

    // Fire the event
    broadcast(new MessageSent($message));

    return response()->json(['status' => 'Message broadcasted!']);
});

This is revive route.

Route::get('/receive-data', function () {
    return view('receive');
});

And view

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Reverb Broadcast</title>
    @vite(['resources/js/app.js']) {{-- Load JS --}}
</head>
<body>
    <h1>Listening for Messages...</h1>
    <pre id="output"></pre>

    <script>
        document.addEventListener("DOMContentLoaded", function () {
            window.Echo.channel("public-messages")
                .listen(".message.sent", (event) => {
                    console.log("Received:", event);
                    document.getElementById("output").textContent = JSON.stringify(event, null, 2);
                });
        });
    </script>
</body>
</html>

And you need to run npm run dev or npm run build to allow window.Echo

Combining with reverb

First let's start reverb server. Run this command in different cli

php artisan reverb:start

Now you can see websocket connection is made

But you need to open a new window and also the run this command for processing jobs that are queued for execution in the background.

php artisan queue:work

That is it. When you insert 'http://localhost:8000/send-message' in window you will see this in another window

And receive it from 'http://localhost:8000/receive-data'

Let's meet with another post about how to deploy this to server.

Effortless Laravel Deployment on Hostinger Using Git: A Step-by-Step Guide

vimuth — Fri, 24 Jan 2025 07:59:43 +0000

This tutorial talks about how to deploy a Laravel app on Hostinger Hpanel. And I'm talking about adding Node JS (Via NVM) build using composer and may more interesting things.

Here we imagine you use popular business plan on hostinger. But deploying on other plans are also same

1. Create a website on hostinger

Got to websites list, click "Add Website" button and select "Empty PHP/HTML website" from dropdown

After that you will be redirected to that domains dashboard. Inside this dashboard go to "Advanced -> SSH Access" and enable SSH status. And don't forget to add a password.

Then login with putty using these data.

2. Adding relevant aspects such as database creation and Node.js setup.

We are going to add relevant aspects. And let us start with database creation. First go to "Databases -> Management" section in your website dashboard and create a Database and a User.

Now database has created. Lets login to putty and get node installed.

To install Node.js on Hostinger using NVM (Node Version Manager), follow these steps:

Step 1: Install NVM (Node Version Manager)

Download and install NVM using cURL:

   curl -fsSL https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.4/install.sh | bash

Reload your shell configuration to apply changes:

   source ~/.bashrc

Verify NVM installation:

   command -v nvm

If installed correctly, it should return nvm.

Step 2: Install Node.js Using NVM

List available Node.js versions:

   nvm list-remote

Install the latest LTS version:

   nvm install --lts

Set the installed version as the default:

   nvm use --lts
   nvm alias default node

Verify the Node.js and npm versions:

   node -v
   npm -v

This should display the installed versions of Node.js and npm.

Step 3: Keep Node.js Available for All Sessions

Since Hostinger’s shared hosting resets the environment on logout, add the following line to ~/.bashrc or ~/.bash_profile to auto-load NVM:

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

Then, reload the shell:

source ~/.bashrc

Now, Node.js should work consistently across sessions.

3. Clone the website and get it running

Again login to putty. And go to your website directory.

cd /home/youruser/domains/yourdomain.hostingersite.com

User and domain can be easily found on website dashboard on Hostinger.

And then remove the public_html folder inside. Actually we are removing everything inside the folder

rm -rf /home/u749865644/domains/saddlebrown-spider-721569.hostingersite.com/*

I know public_html folder is needed in Hostinger hosting. But it's existence will make it hard to clone and deploy a Laravel app. We will add a public_html with a neat trick later

Now we should clone the Laravel app to your domain folder from git.

git clone https://github.com/your-git/your-repo.git .

Since the folder is empty we can easily clone our app here. And if your repository is private, try using a personal access token.

Now lets do a composer install. But there is an important point. Hostinger has installed both composer 1 and composer 2. And we need composer 2. So our command should look like this

composer2 install

Then install node packages.

npm install

now let's create the .env

cp .env.example .env

And don't forget to update that .env using 'nano .env' to access the db we created earlier.

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=hostingeruser
DB_USERNAME=hostingerdb
DB_PASSWORD=hostingerpassword

And make note that we can keep DB_HOST and DB_CONNECTION

Now lets generate keys.

php artisan key:generate

now let's run migrate and seed commands. And remember if there is an error, check weather password contains special characters and if so include it inside double quotes

DB_PASSWORD="hostingerpassword&$#@"

php artisan migrate
php artisan db:seed

Now lets create symbolic links. But there is a small alteration. If you run php artisan storage:link command there will be an error.

This error occurs because Hostinger disables the symlink() function for security reasons. Laravel uses symlink() to create a symbolic link from public/storage to storage/app/public when running above command.

So you will have to manually Create a Storage Link Using a Hard Link

ln -s /home/youruser/yourdomain.hostingersite.com/storage/app/public /home/youruser/yourdomain.hostingersite.com/public/storage

This is just a linux command to create a symlink or shortcut. just replace 'youruser' and 'yourdomain'.

now we have another important thing. Hostinger needs public_html to host and laravel needs public. To satisfy both what we can do is create a public_html symbolic link which will be linked to public folder

ln -s public public_html

now let's run npm build

npm run build

Now your website is ready. Build something useful and make the world a better place and make me proud. Cheers

Understanding var and let in JavaScript: When and Why to Use Each for Cleaner Code

vimuth — Sat, 26 Oct 2024 10:28:54 +0000

In JavaScript, variable declarations are fundamental, but choosing between var, let, and const can greatly impact code quality. Understanding when and why to use each helps create cleaner, more predictable code, essential for modern development.

var and let are both used to declare variables in JavaScript, but they have some key differences in how they handle scope, hoisting, and re-declaration.

Key Differences Between `var` and `let`

Scope
- var is function-scoped: When you declare a variable with var, it’s accessible throughout the entire function in which it’s declared.
- let is block-scoped: Variables declared with let are only accessible within the block (e.g., {...}) where they are defined, making it safer to use in most cases.
Hoisting
- Both var and let are hoisted to the top of their scope, but let is in a Temporal Dead Zone (TDZ) until the line where it’s defined, meaning you cannot access it before its declaration.
- var, on the other hand, is hoisted without the TDZ, so it’s accessible throughout its scope (though it will be undefined until its declaration).
Re-declaration
- var allows re-declaration of the same variable in the same scope, which can lead to unintended bugs.
- let does not allow re-declaration in the same scope, helping avoid accidental overwrites.

Example 1: Scope Difference

function testVar() {
  var x = 10;
  if (true) {
    var x = 20;  // Same `x` in function scope, reassigns the outer `x`
    console.log("Inside if-block:", x);  // Output: 20
  }
  console.log("Outside if-block:", x);  // Output: 20 (still the same `x`)
}

testVar();

With let:

function testLet() {
  let y = 10;
  if (true) {
    let y = 20;  // New `y` scoped to this block only
    console.log("Inside if-block:", y);  // Output: 20
  }
  console.log("Outside if-block:", y);  // Output: 10 (outer `y` is unchanged)
}

testLet();

In the testVar function, var declares a single x for the entire function scope, so reassigning x inside the if block also changes it outside the block. With let, y inside the if block is a separate variable from y outside, preserving each y's value in its own scope.

Example 2: Hoisting Difference

function hoistVar() {
  console.log(x);  // Output: undefined (due to hoisting)
  var x = 10;
  console.log(x);  // Output: 10
}

hoistVar();

With let:

function hoistLet() {
  console.log(y);  // Error: Cannot access 'y' before initialization
  let y = 10;
  console.log(y);  // This line would not be reached
}

hoistLet();

In hoistVar, var x is hoisted to the top of the function scope, but it’s undefined until the actual assignment. In hoistLet, trying to access y before it’s assigned results in a ReferenceError because let variables are hoisted but remain in a Temporal Dead Zone (TDZ) until their declaration.

Example 3: Re-declaration

function redeclareVar() {
  var x = 5;
  var x = 10;  // Allowed with `var`
  console.log(x);  // Output: 10
}

redeclareVar();

With let:

function redeclareLet() {
  let y = 5;
  let y = 10;  // Error: Identifier 'y' has already been declared
}

redeclareLet();

With var, re-declaring x in the same scope is allowed, which could cause unintended bugs. With let, re-declaring y in the same scope results in an error, helping to avoid accidental overwrites.

Summary

Scope: var is function-scoped; let is block-scoped.
Hoisting: var is hoisted without restriction, while let is in a Temporal Dead Zone.
Re-declaration: var allows it; let does not.

In general, let is recommended in modern JavaScript because it provides more predictable scoping and reduces the risk of unintended bugs.

Understanding Two-Way Data Binding in Vue 3: Creating Child Components, Passing Data to Parents, and Attribute Inheritance

vimuth — Sat, 07 Sep 2024 21:12:39 +0000

In this article, we will explore how to create child components in Vue 3, pass data between parent and child components, and leverage attribute inheritance for a more flexible and cleaner component design. We will cover practical examples and best practices to help you harness the full potential of Vue 3's capabilities, making your development process more intuitive and efficient.

Creating a Simple TextArea Component

Create a new Vue component file named TextArea.vue with the following content:

<template>
  <textarea
    :value="modelValue"
    @input="handleInput"
  ></textarea>
</template>

<script setup>
import { defineProps, defineEmits } from 'vue';

const props = defineProps({
  modelValue: String
});

const emit = defineEmits(['update:modelValue']);

const handleInput = (event) => {
  emit('update:modelValue', event.target.value);
};
</script>

Here’s an example of how you can use the TextArea component in a parent component:

<template>
  <div>
    <TextArea v-model="commentBody" />
    <p>Your comment: {{ commentBody }}</p>
  </div>
</template>

<script setup>
import { ref } from 'vue';
import TextArea from './TextArea.vue'; // Adjust the path as needed

// Define a ref to hold the textarea value
const commentBody = ref('');
</script>

Now watch carefully. We don't need to emit update value element from child component. Vue 3 does this for us.

Parent Component Listens for the update:modelValue Event: The parent component listens for the update:modelValue event because of the v-model directive:

<TextArea v-model="commentBody" />

Vue internally converts this v-model into the following:

<TextArea :modelValue="commentBody" @update:modelValue="val => commentBody = val" />

This means that whenever the update:modelValue event is emitted from the child component, the parent updates its commentBody variable with the new value (the value the user typed).

This two-way binding mechanism is how the data flows between the parent and the child component in Vue.

Understanding Attribute Inheritance

In Vue 3, any extra attributes (like class, id, or style) passed to a component that are not explicitly defined in props are automatically added to the root element of the template by default. This feature is known as attribute inheritance or attribute forwarding. This is a really cool and useful feature.

<TextArea v-model="commentBody" class="textclass" id="textid"/>

When you pass attributes like class or id, they automatically to the root element of a component.

In this example they (class and id) will apply to the <textarea> (root of child component) element.

test

vimuth — Sat, 07 Sep 2024 19:24:02 +0000

In modern web development, efficient component design and seamless data communication are crucial for building interactive and maintainable user interfaces. Vue 3, with its Composition API and syntax, introduces powerful tools to streamline component creation and data handling. One key feature of Vue 3 is attribute inheritance, which simplifies the management of dynamic attributes in components.</p> <p>In this article, we will explore how to create child components in Vue 3, pass data between parent and child components, and leverage attribute inheritance for a more flexible and cleaner component design. We will cover practical examples and best practices to help you harness the full potential of Vue 3's capabilities, making your development process more intuitive and efficient.</p>

Understanding Mass Assignment in Laravel: How fillable Protects Your Models

vimuth — Sat, 07 Sep 2024 09:43:06 +0000

In Laravel, mass assignment allows you to quickly create or update records by passing an array of attributes. While convenient, it can also expose your application to security risks if not handled correctly. That’s where the fillable property comes in—it ensures that only specific fields can be mass-assigned, protecting sensitive data. This article explains how fillable works, its advantages, and why it doesn’t apply when using the save() method and how to avoid this fillable if don't need that.

What is Mass Assignment

Mass assignment refers to assigning multiple attributes to a model at once using an array. It usually happens in one of the following ways:

1. Using create():

// Creating two users using mass assignment
User::create([
    'name' => 'Alice',
    'email' => 'alice@example.com',
    'password' => bcrypt('password123')
]);

User::create([
    'name' => 'Bob',
    'email' => 'bob@example.com',
    'password' => bcrypt('secret456')
]);

In this example, both create() calls use mass assignment to set multiple attributes at once.

2. Using update():

// Finding two users and updating their information using mass assignment
$user1 = User::find(1);
$user1->update([
    'name' => 'Alice Updated',
    'email' => 'alice_new@example.com'
]);

$user2 = User::find(2);
$user2->update([
    'name' => 'Bob Updated',
    'email' => 'bob_new@example.com'
]);

Here, the update() method allows multiple fields to be updated at once through mass assignment.

Issues of Mass Assignment

Using mass assignment without proper controls can introduce serious security vulnerabilities. Consider the following example in your controller:

public function store(Request $request)
{
    // This allows all fields from the request to be mass-assigned
    User::create($request->all());
}

This is risky. Imagine request have this

{
    "name": "Alice",
    "email": "alice@example.com",
    "password": "password123",
    "is_admin": true,
    "status": "active"
}

Imagine they are adding an Admin and change everything. This can lead to unauthorized privilege escalation or unintended account modifications.

fillable Array and how it prevents this issues

To prevent mass assignment of sensitive fields like is_admin and status, you can specify which fields are allowed for mass assignment using the fillable array in the User model.

class User extends Model
{
    // Define the fields that are allowed for mass assignment
    protected $fillable = ['name', 'email', 'password'];
}

With the fillable array defined as shown above, only the attributes listed in the array can be mass-assigned. This means that even if a request contains fields like is_admin or status, they will be ignored when using mass assignment methods like create() or update().

Notes to consider.

insert() method not considering fillables.

insert() is a query builder method, not an Eloquent model method, so it bypasses Eloquent's features like mass assignment protection, events, and model accessors/mutators.

User::insert([
    [
        'name' => 'Alice',
        'email' => 'alice@example.com',
        'password' => bcrypt('password123')
    ],
    [
        'name' => 'Bob',
        'email' => 'bob@example.com',
        'password' => bcrypt('secret456')
    ]
]);

Ignore fillable array if needed.

If you need to bypass the fillable array for a specific operation, you can use the unguard() method provided by Laravel's Eloquent model. This method allows you to disable mass assignment protection temporarily.

How to Use unguard()

Disable Mass Assignment Protection:
- You can use Model::unguard() to disable mass assignment protection for the entire application or a specific block of code.
Enable Mass Assignment Protection Again:
- After performing the operations where mass assignment protection is not needed, you should call Model::reguard() to re-enable it.

Example Usage:

Temporarily Disable Mass Assignment Protection

use Illuminate\Database\Eloquent\Model;

public function store(Request $request)
{
    // Temporarily disable mass assignment protection
    Model::unguard();

    // Validate the request data (if needed)
    $validatedData = $request->validate([
        'name' => 'required|string|max:255',
        'email' => 'required|email|unique:users,email',
        'password' => 'required|string|min:8',
    ]);

    // Prepare data for insertion
    $userData = [
        'name' => $validatedData['name'],
        'email' => $validatedData['email'],
        'password' => bcrypt($validatedData['password']),
        'is_admin' => $request->input('is_admin'),  // Example of bypassing fillable
        'status' => $request->input('status'),      // Example of bypassing fillable
        'created_at' => now(),
        'updated_at' => now(),
    ];

    // Insert the record
    User::insert($userData);

    // Re-enable mass assignment protection
    Model::reguard();
}

Key Points:

Use with Caution: unguard() bypasses the fillable protection, so use it carefully. Ensure that you validate and sanitize the data properly before inserting it into the database.
Scope of unguard(): It affects all models in the application during its scope. If you only need to bypass fillable protection for specific models or operations, it's better to handle it at the model level or within a specific code block.
Re-enable Protection: Always call Model::reguard() after performing operations that require unguard() to ensure that mass assignment protection is re-enabled for the rest of your application.

Database optimizing with Hugh datasets with MySQL.

vimuth — Thu, 05 Sep 2024 17:15:57 +0000

Efficient database performance is crucial for any application, and optimizing MySQL queries plays a key role in achieving that. As data grows, poorly written queries can cause significant slowdowns, leading to longer response times and higher resource consumption. By understanding how MySQL executes queries and applying optimization techniques like indexing, query restructuring, and proper data types, you can dramatically improve performance. Whether you’re handling small datasets or scaling to millions of records, optimized queries ensure smoother and faster interactions with your database, ultimately improving the user experience and reducing server load.

My database contains an employees table with approximately 7,852,118 rows.

I executed the following query:

SELECT * 
FROM employees
WHERE email = 'sbrakus@example.org'

The query took roughly 17 seconds to execute, though this duration may vary depending on server conditions.

Optimizing Queries by Selecting Only Relevant Fields

Selecting only the necessary fields, rather than retrieving all columns, can significantly reduce query execution time. Consider the following example:

SELECT email 
FROM employees
WHERE email = 'sbrakus@example.org'

Improving Performance with Indexing

One of the most effective ways to speed up queries is by using indexing. Let's start by creating an index on the email column:

CREATE INDEX idx_employees_email ON employees(email);

Now, when we run the same query:

SELECT email 
FROM employees
WHERE email = 'sbrakus@example.org';

The query should execute much faster, as the index allows MySQL to quickly locate the relevant records.

You’ll notice that the query now executes in just 0.020 seconds.

Addressing Indexing Limitations and Query Optimization

While indexing significantly improved the performance of queries on the email field, it doesn't impact queries that filter on non-indexed fields. For example:

SELECT email 
FROM employees
WHERE last_name = 'Halvorson';

This query will still be slow because last_name is not indexed. Similarly, fetching all records from the employees table:

SELECT * 
FROM employees;

Can be very time-consuming, especially with a large dataset.

To manage large result sets, consider using limits to restrict the number of rows returned:

SELECT * 
FROM employees 
LIMIT 1000 OFFSET 0;

This approach can help to retrieve data in smaller, more manageable chunks, reducing the load on your server and improving performance.

Understanding the Limitations of Query Limiting

Using the LIMIT clause to restrict the number of records returned can be effective in many scenarios, but it may not always yield the desired results. For instance:

SELECT * 
FROM employees 
WHERE last_name = 'Halvorson'
LIMIT 1000 OFFSET 0;

In this case, the query took 0.348 seconds to complete. The reduced execution time was due to the fact that 'Halvorson' is a relatively common last name. The query was able to stop early, having found 1,000 matching records before scanning the entire table. However, this approach may not be as effective in cases where the filtered criteria are less common or where data distribution is uneven.

Consider this query:

SELECT * 
FROM employees 
WHERE last_name = 'david'
LIMIT 1000 OFFSET 0;

Since 'david' does not exist in the employees table, the query had to scan all 7,852,118 records, resulting in a significantly longer execution time.

Adding an Index

Let's create an index on the last_name field to improve query performance:

CREATE INDEX idx_last_name ON employees(last_name);

With the new index in place, executing the following query:

SELECT * 
FROM employees 
WHERE last_name = 'david'
LIMIT 1000 OFFSET 0;

Runs significantly faster. The index allows MySQL to quickly locate relevant records, reducing the time needed to scan the entire table.

However, this B-tree index has its limitations. While it performs well with queries where the search string begins with a specific prefix, such as:

SELECT * FROM employees
WHERE last_name LIKE 'david%';

In this case, MySQL can efficiently use the index to find last_name values starting with "david."

But for LIKE queries with different wildcards, such as:

SELECT * FROM employees
WHERE last_name LIKE '%david';

SELECT * FROM employees
WHERE last_name LIKE '%david%';

The index may not be used effectively, resulting in slower query performance.

In these cases, MySQL indexes may not be sufficient. I will provide a tutorial on PostgreSQL indexing techniques to address these limitations.

Mastering User Experience: Understanding and Implementing Debouncing and Throttling in JavaScript

vimuth — Tue, 27 Aug 2024 17:23:50 +0000

In the fast-paced world of web development, user experience is paramount. One of the key aspects of ensuring a smooth and responsive interface is managing how and when events are processed. This is where debouncing and throttling come into play. These techniques are crucial for optimizing performance and enhancing the user experience by controlling the rate at which functions are executed. Whether you're dealing with input fields that trigger search queries, scrolling events, or resizing actions, understanding and implementing debouncing and throttling can make a significant difference in the responsiveness and efficiency of your web applications. In this article, we'll explore the concepts of debouncing and throttling, their differences, and practical implementations in JavaScript to help you master user experience design.

I'll explain them simple. Here's an example of making an API call with an input field using jQuery without using Lodash. This example will simulate making a call to a dummy API every time the user types something in the input field:

<label for="inputField">Type something:</label>
    <input type="text" id="inputField">

    <h2>API Response:</h2>
    <p id="apiResponse"></p>

    <script src="https://code.jquery.com/jquery-3.6.0.min.js"></script>
    <script>
        $(document).ready(function() {
            $('#inputField').on('input', function() {
                const value = $(this).val();

                // Make the API call when the input value changes
                $.ajax({
                    url: `https://jsonplaceholder.typicode.com/posts?q=${value}`,
                    method: 'GET',
                    success: function(response) {
                        $('#apiResponse').text(JSON.stringify(response));
                    },
                    error: function() {
                        $('#apiResponse').text('Error fetching data.');
                    }
                });
            });
        });
    </script>

If you check inspect element you will see that an API call goes to a server every time we type a letter.

It's true that we need the result for "example post". But we don't need to send API call and get results for e, ex, exa or exam. For that we can use Debouncing and Throttling

Debouncing

debouncing ensures that a function is executed only after a certain period of inactivity, reducing the number of function calls and improving performance. Let me explain it further.

const debouncedUpdate = _.debounce(function (value) {
                $('#debouncedOutput').text(value);
                console.log('Debounced Input:', value);
            }, 1000); // 1 second debounce

They wait 1000 milisecond or 1 second before send the API call. (Or change text in $('#debouncedOutput') according to this case).

Even though you sent three API calls for this, 'exa' now it waits 1 second (1000 milliseconds) after pressing first letter before sending an API call. If you press second letter before that API call will not go.

If you type into a search box, the function debouncedUpdate will wait for 1 second after the user stops typing before executing. So, if the user types "exa" and then types more characters within that second, the debounce delay resets and the function won’t execute until the user stops typing for a full second. This prevents unnecessary function calls or updates while the user is still typing.

Throttling

Check this example.

const throttledUpdate = _.throttle(function (value) {
                $('#throttledOutput').text(value);
                console.log('Throttled Input:', value);
            }, 1000); // 1 second throttle

Throttling works like this. After you start typing after every 1000 milliseconds the function runs until stop typing. And make note it will run initial call too.

Here’s how it works:

Initial Call: When the event first occurs (e.g., typing), the function executes immediately.
Subsequent Calls: The function will not execute again until the specified interval (e.g., 1000 milliseconds) has passed, even if the event continues to occur during that time.
Interval Execution: After the interval has passed, if there are additional events, the function will execute again and then wait for the next interval.

So, throttling limits how frequently the function is executed during continuous events, ensuring it only runs at a controlled rate.

This is a complete example if you want to check the behavior more

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Lodash Throttle and Debounce Example</title>

</head>

<body>
    <h1>Lodash Throttle and Debounce Example</h1>

    <label for="inputField">Type something:</label>
    <input type="text" id="inputField">

    <h2>Throttled Output:</h2>
    <p id="throttledOutput"></p>

    <h2>Debounced Output:</h2>
    <p id="debouncedOutput"></p>

    <!-- jQuery CDN -->
    <script src="https://code.jquery.com/jquery-3.6.0.min.js"></script>
    <!-- Lodash CDN -->
    <script src="https://cdn.jsdelivr.net/npm/lodash@4.17.21/lodash.min.js"></script>
    <script>
        $(document).ready(function () {
            // Throttle example: Limits the number of times the function can execute within a time frame
            const throttledUpdate = _.throttle(function (value) {
                $('#throttledOutput').text(value);
                console.log('Throttled Input:', value);
            }, 1000); // 1 second throttle

            // Debounce example: Delays the execution of the function until a certain amount of time has passed without triggering
            const debouncedUpdate = _.debounce(function (value) {
                $('#debouncedOutput').text(value);
                console.log('Debounced Input:', value);
            }, 1000); // 1 second debounce

            // Event listener for input field
            $('#inputField').on('input', function () {
                const value = $(this).val();
                throttledUpdate(value);
                debouncedUpdate(value);
            });
        });
    </script>
</body>

</html>

Eager loading, n+1 issue and query optimization in laravel

vimuth — Tue, 27 Aug 2024 08:22:18 +0000

In Laravel there are few ways to optimize queries. One way is eager loading. First let's see what is eager loading.

When you handle relationships between columns, The default way is Lazy loading. When you access a related model in Laravel, a separate query is made to the database to fetch that related data. This is known as lazy loading. Let us see with and example.

Assume you have two models: Post and Comment, where a Post has many Comments.

$posts = Post::all();

foreach ($posts as $post) {
    foreach ($post->comments as $comment) {
        // Each iteration fetches comments in a separate query
    }
}

Let us now see how this works in query level. Imagine you have N number of posts in your table. Above code will run N+1 queries. Let me explain how it happens,

First Query: Fetch All Posts

SELECT * FROM `posts`;

N Queries: Fetch Comments for Each Post
For each Post object in $posts, Laravel will perform a separate query to fetch the related comments. If there are "N" posts, it will run "N" queries, one for each post.

The query structure looks like this:

SELECT * FROM `comments` WHERE `comments`.`post_id` = 1 AND `comments`.`post_id` IS NOT NULL;
SELECT * FROM `comments` WHERE `comments`.`post_id` = 2 AND `comments`.`post_id` IS NOT NULL;
...
SELECT * FROM `comments` WHERE `comments`.`post_id` = N AND `comments`.`post_id` IS NOT NULL;

Summary of Queries:

1 Query to fetch all posts from the posts table.
N Queries to fetch comments for each post, where N is the number of posts retrieved in the first query.

Now you may see there are N+1 queries. This is called N+1 issue. For prevent this we use Eager Loading

Eager Loading

$posts = Post::with('comments')->get();

foreach ($posts as $post) {
    foreach ($post->comments as $comment) {
        // Comments are already loaded
    }
}

Here we use "with" eloquent method for eager loading. Let's see how this optimize things. Instead of N+1 queries it runs only two queries now.

Query to Fetch All Posts:

SELECT * FROM `posts`;

Query to Fetch All Related Comments:

SELECT * FROM `comments` WHERE `post_id` IN (1, 2, 3, ... , N);

Instead of N+1 queries in earlier now we have only two queries. And this increases the performance a lot.

After Eager Loading

In some cases also Eager Loading may be problematic. Let's see an example. Imagine Post model (posts table) have multiple relationships.

$posts = Post::with(['user', 'comments'])->get();

foreach ($posts as $post) {

}

This will result in three queries. Fetch posts, users related to posts and comments related to posts. Imagine you have millions of users and comments in your database. Then it will be better to take all these records using a single query.

In a scenario like this taking everything inside one query is faster than taking three queries and mapping. The reason is databases has optimized to face such scenarios. In theoretically speaking this is the reason

Single Query: Joins allow you to fetch all the related data in a single query, reducing the overhead of multiple database round trips.
Database-Level Optimization: Joins leverage the database's ability to optimize query execution, often resulting in faster data retrieval, especially with proper indexing.
Reduced Memory Usage: Since joins combine data into a single result set, they can be more memory-efficient, especially when you don't need to instantiate many related models in your application.

Instead of using with, you could use a join to fetch the data more efficiently:

$posts = Post::select('posts.*', 'users.name as author_name', 'comments.content as comment_content')
    ->join('users', 'posts.user_id', '=', 'users.id')
    ->join('comments', 'posts.id', '=', 'comments.post_id')
    ->get();

But if you check this query carefully you can see "users.name as author_name" and "comments.content as comment_content". This is because two tables having same column called 'name'. But for eager loading situations like this are automatically handled.

Bottom Line:

Joins: If you're dealing with multiple relationships and large datasets, using joins can be more efficient. This is because joins consolidate the data retrieval into a single, optimized query, minimizing the overhead of multiple queries and reducing memory usage.
Eager Loading: If you're not dealing with massive datasets or the relationships aren't too complex, eager loading is a safer and more convenient option. It automatically handles potential conflicts (like duplicate column names) and allows you to work with related models in a clean and organized way without needing to worry about query complexity.

When to Choose Which:

Joins: Ideal for scenarios where performance is critical, and you're dealing with large volumes of data. Use joins when you need to minimize the number of queries and optimize database-level operations.
Eager Loading: Best for smaller or moderate datasets where ease of use and code readability are more important than raw performance. It simplifies working with related data and avoids the manual handling required with joins.

Conclusion:

For large, complex relationships: Joins are typically better for performance.
For smaller, simpler scenarios: Eager Loading offers convenience and safety.

You could use tools like Laravel Telescope to see the queries and times for them.

Implementing Robust Retry Logic in Laravel Jobs for Reliable API Data Fetching

vimuth — Mon, 19 Aug 2024 10:11:03 +0000

Imagine you are fetching data from third party API inside your laravel backend. In modern web applications, integrating with third-party APIs has become commonplace. These external services often provide critical functionalities, from fetching user data to processing transactions. However, these APIs can sometimes fail due to various reasons such as network issues, service outages, or rate limits. Such failures can disrupt your application’s operations and negatively impact user experience.

To mitigate these risks, it’s essential to implement robust retry mechanisms that can handle these transient failures effectively. This is where Laravel Jobs come into play. Laravel’s job system allows you to perform background tasks asynchronously, including handling API requests. By using jobs, you can ensure that these tasks are retried automatically when they fail, without blocking the main application flow.

Jobs in Laravel provide a structured way to manage and retry failed tasks, making your application more resilient and reliable. They help offload time-consuming processes from the user’s immediate experience, improving performance and scalability. In this article, we’ll explore how to set up retry logic in Laravel Jobs to handle third-party API failures gracefully, ensuring that your application remains robust and responsive even in the face of external service issues.

Now let's see how to do this,

1.Creating a Job with Retry Logic

First let's create the job with this artisan command

php artisan make:job FetchApiDataJob

This is the retry logic.

public $tries = 5; // Number of retry attempts
public $backoff = 10; // Seconds to wait before retrying

This is the full code for job.

namespace App\Jobs;

use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;
use Illuminate\Support\Facades\Http;
use App\Models\YourModel; // Replace with your actual model
use Exception;

class FetchApiDataJob implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    public $tries = 5; // Number of retry attempts
    public $backoff = 10; // Seconds to wait before retrying

    public function handle()
    {
        try {
            $response = Http::get('https://jsonplaceholder.typicode.com/posts');

            if (!$response->successful()) {
                throw new Exception('API request failed with status: ' . $response->status());
            }

            $data = $response->json();

            foreach ($data as $item) {
                YourModel::updateOrCreate(
                    ['id' => $item['id']], // Adjust based on your model and data
                    [
                        'title' => $item['title'],
                        'body' => $item['body'],
                        // Additional columns
                    ]
                );
            }
        } catch (Exception $e) {
            $this->fail($e); // Trigger retry
        }
    }

    public function failed(Exception $exception)
    {
        \Log::error('FetchApiDataJob failed: ' . $exception->getMessage());
    }
}

For any reason if this API call fails and didn't give valid response below if condition fails. And when if condition fails the code throws an exception. And then try catch fails. When try catch fails it runs the API call again according to retry logic we showed before

if (!$response->successful()) {
     throw new Exception('API request failed with status: ' . $response->status());
}

2.Dispatch the Job from a Controller

To dispatch the job from a controller, you would typically do it in response to a user action, such as a form submission or a button click.

Here’s an example controller method that dispatches the job:

namespace App\Http\Controllers;

use App\Jobs\FetchApiDataJob;
use Illuminate\Http\Request;

class ApiController extends Controller
{
    public function fetchData()
    {
        // Dispatch the job to the queue
        FetchApiDataJob::dispatch();

        // Return a response to the user
        return response()->json(['message' => 'Job dispatched to fetch data.']);
    }
}

3.Running Queue Workers

Make sure to run this command to run job queues. In server you can use supervisor for this.

php artisan queue:work

4.Notes.

Imagine this API call takes lots of time to run and slow down the controller. For this also the calling Third party API inside a job is a great solution. And to increase performance more you can use redis queues instead db queues.

DEV Community: vimuth

How to Implement Stripe Payments with Payment Intents and Webhooks for Complete Payment Flow Management

1. Starting the Project:

2. Implementing Stripe Payment Intents

1. Set up the Environment

2. Create the Payment Intent Route

3. Frontend Implementation: Handling Stripe Payment

1. Add Stripe.js to Your HTML

2. Get the payment intent and confirm payment

3. Save the data with stripe webhook.

4. Run with Stripe CLI

Automate Laravel Deployment on Hostinger with GitHub Actions: A Step-by-Step Guide

Creating a Deployment Script for GitHub Actions

Create the GitHub Actions workflow file

Add repository secret values

Building a Simple Laravel App with Reverb: A Step-by-Step Guide

Install laravel

Install Reverb

Building the App

Lets create the event

Let's create two routes and a view in Laravel:

Combining with reverb

Effortless Laravel Deployment on Hostinger Using Git: A Step-by-Step Guide

1. Create a website on hostinger

2. Adding relevant aspects such as database creation and Node.js setup.

Step 1: Install NVM (Node Version Manager)

Step 2: Install Node.js Using NVM

Step 3: Keep Node.js Available for All Sessions

3. Clone the website and get it running

Understanding var and let in JavaScript: When and Why to Use Each for Cleaner Code

Key Differences Between var and let

Example 1: Scope Difference

Example 2: Hoisting Difference

Example 3: Re-declaration

Summary

Understanding Two-Way Data Binding in Vue 3: Creating Child Components, Passing Data to Parents, and Attribute Inheritance

Creating a Simple TextArea Component

Understanding Attribute Inheritance

test

Understanding Mass Assignment in Laravel: How fillable Protects Your Models

What is Mass Assignment

Issues of Mass Assignment

fillable Array and how it prevents this issues

Notes to consider.

Database optimizing with Hugh datasets with MySQL.

Optimizing Queries by Selecting Only Relevant Fields

Improving Performance with Indexing

Addressing Indexing Limitations and Query Optimization

Understanding the Limitations of Query Limiting

Mastering User Experience: Understanding and Implementing Debouncing and Throttling in JavaScript

Debouncing

Throttling

Eager loading, n+1 issue and query optimization in laravel

Eager Loading

After Eager Loading

Bottom Line:

When to Choose Which:

Conclusion:

Implementing Robust Retry Logic in Laravel Jobs for Reliable API Data Fetching

1.Creating a Job with Retry Logic

2.Dispatch the Job from a Controller

3.Running Queue Workers

4.Notes.

Key Differences Between `var` and `let`