Dalaxshan Makenthiran’s Post

View profile for Dalaxshan Makenthiran
Dalaxshan Makenthiran

🚀 Secure Your NestJS Apps with JWT & Prisma! In this guide, I show how to set up JWT-based authentication in a modern NestJS application using Prisma V7+ with PostgreSQL (Supabase). You’ll learn how to: i. Initialize Prisma and configure your database ii. Create user registration and login APIs iii. Hash passwords securely and generate JWT tokens iv. Protect routes with a JWT guard v. Easily test APIs using Postman Whether you’re building a full-stack web app or just starting with NestJS and Prisma, this step-by-step tutorial will help you implement a robust and secure authentication system in no time. 💡 Perfect for developers looking to combine NestJS, Prisma, and Supabase for modern web apps.

To view or add a comment, sign in

More Relevant Posts

  • View organization page for mololab
    mololab

    244 followers

    Every query in AloDB follows a real-time protocol between the server and your desktop app. Here's what happens when you ask a question: `MessageChat` (you) -> Server receives your question `EventThinking` (server) -> AI agent starts processing `EventQueryRequest` (server) -> Agent needs data, sends SQL with a unique RequestID Your app executes the query locally -> sends `MessageQueryResult` back `EventTextDelta` (server) -> AI streams the response `EventResponseComplete` (server) -> Done The key: the server sends SQL, your machine runs it. The server never connects to your database. Each query request gets a UUID. The server holds a channel waiting for the matching result. When your client sends back the `MessageQueryResult` with the right RequestID, the result is delivered through that channel to the waiting agent. Async request-response over a persistent WebSocket. Each chat session has its own WebSocket connection, so parallel conversations work without blocking. This is the architecture that keeps your credentials on your machine while still giving you AI-powered querying. Source code: github.com/mololab/alodb #WebSocket #GoLang #PostgreSQL #SoftwareArchitecture #DevTools

    • No alternative text description for this image

    To view or add a comment, sign in

  • View profile for Moaaz Hagag
    Moaaz Hagag

    In an era where data privacy is increasingly scarce, owning your communication channels is more important than ever. I’m excited to share my latest open-source contribution: ChatApp, a full-stack, real-time messaging application designed from the ground up for privacy and self-hosting. By utilizing Docker for the database infrastructure, you retain 100% control over your data. There are no third-party servers mining your conversations and no hidden telemetry—just your app and your data, running securely wherever you choose to deploy it. Beyond the privacy aspect, I wanted to build a chat experience that feels as robust as commercial alternatives. Here is a look under the hood: The Tech Stack: Frontend: React + Vite for a blazing-fast client experience. Backend: Node.js + Express + Socket.IO for seamless, real-time bidirectional communication. Database: PostgreSQL + Prisma ORM for structured, reliable data persistence. Scale: Optional Redis integration to support multi-instance Socket.IO, presence state, and typing indicators. Key Features: Ironclad Auth: JWT authentication with refresh tokens securely stored in httpOnly cookies. Optimistic UI: Messages are added locally to the UI immediately for a snappy feel, syncing seamlessly with the server’s acknowledgment. Rich Real-Time UX: Features read receipts, typing indicators, and live online/offline presence. Reliable History: Persisted messaging with cursor-based pagination for smooth scrolling through older chats. The project is released under the MIT License and includes easy-to-follow local setup instructions using Docker. I’d love for the developer community to check out the code, spin it up, and share feedback or contribute! Check out the repository here: https://lnkd.in/dtmqY_NY #OpenSource #WebDevelopment #ReactJS #NodeJS #SocketIO #Privacy #SelfHosted #Docker #SoftwareEngineering #PostgreSQL

    To view or add a comment, sign in

  • View organization page for OpenReplay
    OpenReplay

    4,192 followers

    Choosing PostgreSQL is the easy part — using it well in production is where most teams stumble. From schema designs that survive changing requirements to indexing strategies that actually improve performance and connection management that won't silently kill your app, this guide covers the practices that separate a working database from a reliable one.

    To view or add a comment, sign in

  • View profile for Sanskar Bhushankar
    Sanskar Bhushankar

    𝗦𝘂𝗽𝗮𝗯𝗮𝘀𝗲 𝗷𝘂𝘀𝘁 𝗳𝗶𝘅𝗲𝗱 𝗼𝗻𝗲 𝗼𝗳 𝘁𝗵𝗲 𝗾𝘂𝗶𝗲𝘁𝗲𝘀𝘁 𝗽𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝗿𝗶𝘀𝗸𝘀 𝗶𝗻 𝗯𝗮𝗰𝗸𝗲𝗻𝗱 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁. https://lnkd.in/dgynuKGu For years, anon and service_role keys were tied to a single JWT secret. If one leaked, the only fix was rotating the secret. That meant: • Frontend breaks • Backend breaks • Mobile apps stay broken until users update One leak could cause days or even weeks of downtime. In June 2025, Supabase fixed this. They introduced: 𝗦𝗯_𝗽𝘂𝗯𝗹𝗶𝘀𝗵𝗮𝗯𝗹𝗲 → 𝗿𝗲𝗽𝗹𝗮𝗰𝗲𝘀 𝗮𝗻𝗼𝗻 𝗦𝗯_𝘀𝗲𝗰𝗿𝗲𝘁 → 𝗿𝗲𝗽𝗹𝗮𝗰𝗲𝘀 𝘀𝗲𝗿𝘃𝗶𝗰𝗲_𝗿𝗼𝗹𝗲 Same permissions. Completely different system. Now: • Keys are independent • Rotate one without affecting others • Multiple secret keys per service • Secret keys blocked in browsers (401) • Instant revocation Under the hood: Old → JWTs tied to one secret New → Opaque keys via API Gateway Migration is simple: • Replace env variables • No SQL or RLS changes • Old and new keys work together Legacy keys are being phased out, and new projects already don’t include them. If you’re still on old keys, migrate before it becomes urgent. #Supabase #BackendDevelopment #APISecurity #PostgreSQL #SoftwareEngineering

    To view or add a comment, sign in

  • View organization page for PlanetScale
    PlanetScale

    13,686 followers

    Introducing Database Traffic Control: a Postgres traffic management system built into PlanetScale. Enforce flexible budgets on your database traffic to protect against unexpected and dangerous workloads. How it works: 1. Create budgets that target subsets of your query traffic 2. Specify which queries fall in those budgets based on query patterns, app names, custom tags, or Postgres users. 3. Set the resource limits each budget can consume Read more: https://lnkd.in/gFQUb_sm

    To view or add a comment, sign in

  • View profile for Muhammad Absar
    Muhammad Absar

    Your Django app is probably opening and closing database connections on every single request. This is Django's default behavior. A connection is established on the first query and torn down when the request finishes. For low-traffic apps, this is fine. But it becomes a serious bottleneck under load. The overhead of the TCP handshake and PostgreSQL authentication for every single request adds up quickly. It consumes CPU on both your app and database servers and can easily lead to connection exhaustion, where your database simply refuses new clients. Your app starts throwing errors, and users see failures. The solution is connection pooling. A connection pooler like PgBouncer sits between your Django application and your database. It maintains a pool of persistent connections to Postgres. When your app needs a connection, PgBouncer hands it a ready-to-use one from the pool instantly, bypassing the expensive setup process. When the request is done, the connection is returned to the pool, not closed. Setting Django's `CONN_MAX_AGE` for persistent connections is a good first step, but an external pooler gives you far more control and insight for serious production environments. Have you ever been bitten by database connection exhaustion in production? What was the fix? Connect with me if you're navigating similar scaling challenges. #Django #PostgreSQL #SystemDesign

    • This is Django's default behavior. A connection is established on the first query and torn down when the request finishes. For low-traffic apps, this is fine. But it becomes a serious bottleneck under load. The overhead of the TCP handshake and PostgreSQL authentication for every single request adds up quickly. It consumes CPU on both your app and database servers and can easily lead to connection exhaustion, where your database simply refuses new clients. Your app starts throwing errors, and users see failures. The solution is connection pooling. A connection pooler like PgBouncer sits between your Django application and your database. It maintains a pool of persistent connections to Postgres. When your app needs a connection, PgBouncer hands it a ready-to-use one from the pool instantly, bypassing the expensive setup process. When the request is done, the connection is returned to the pool, not closed. Setting Django's `CONN_MAX_AGE` for persistent connections is a good first step, but an external pooler gives you far more control and insight for serious production environments. Have you ever been bitten by database connection exhaustion in production? What was the fix? Connect with me if you're navigating similar scaling challenges. #Django #PostgreSQL #SystemDesign
    • This is Django's default behavior. A connection is established on the first query and torn down when the request finishes. For low-traffic apps, this is fine. But it becomes a serious bottleneck under load. The overhead of the TCP handshake and PostgreSQL authentication for every single request adds up quickly. It consumes CPU on both your app and database servers and can easily lead to connection exhaustion, where your database simply refuses new clients. Your app starts throwing errors, and users see failures. The solution is connection pooling. A connection pooler like PgBouncer sits between your Django application and your database. It maintains a pool of persistent connections to Postgres. When your app needs a connection, PgBouncer hands it a ready-to-use one from the pool instantly, bypassing the expensive setup process. When the request is done, the connection is returned to the pool, not closed. Setting Django's `CONN_MAX_AGE` for persistent connections is a good first step, but an external pooler gives you far more control and insight for serious production environments. Have you ever been bitten by database connection exhaustion in production? What was the fix? Connect with me if you're navigating similar scaling challenges. #Django #PostgreSQL #SystemDesign

    To view or add a comment, sign in

  • View organization page for Mongo Pilot
    Mongo Pilot

    32 followers

    New free tool: MongoDB Explain Plan Visualizer Paste your explain("executionStats") output. Get a visual stage tree, efficiency score, and performance recommendations instantly. No account. No connection string. Works in the browser. 🔗 https://lnkd.in/eYXQ_bGn Already using Mongo Pilot? You can copy the Raw JSON directly from the Stats button in the app. #MongoDB #Developer #WebDev #Database

    • No alternative text description for this image

    To view or add a comment, sign in

Image
Dalaxshan Makenthiran

263 followers

View Profile

Explore content categories