DEV Community: mark vachi

Client API Key — Design (Lite) ออกแบบ API key service to service

mark vachi — Sat, 29 Aug 2026 04:48:17 +0000

ออกแบบ API key สำหรับการเรียกกัน service to service ให้เบาและยังถูกต้อง

วันหนึ่งจะมีอีกทีมมาขอเรียก service ของคุณ และคุณต้องรู้ให้ได้ว่าใครเป็นคนยิงเข้ามา

ตัวเลือกที่คนส่วนใหญ่หยิบมีสองขั้ว — ยัดค่าสุ่ม uuid/hash ไว้ใน env var แล้วเทียบสตริง ซึ่งใช้ได้จริงจนถึงวันที่ key หลุด หรือลาก OAuth2 มาทั้งชุด ซึ่งซับซ้อนกว่าสิ่งที่กำลังจะปกป้องหลายเท่า โพสต์นี้คือทางกลาง

TL;DR

ตารางเดียว 6 คอลัมน์ กับฟังก์ชันสิบบรรทัด

ของเล็กใครก็เขียนได้ ประเด็นอยู่ที่ว่าตัวนี้ไม่ทิ้งหนี้ไว้ให้ตัวเอง เพราะเก็บ 3 อย่างที่ราคาวันนี้เกือบศูนย์ แต่แก้ทีหลังแพง

เก็บ hash ไม่เก็บตัว key
การ revoke ให้เก็บเป็นเวลา แล้วกรองมันในตัว query ไม่ใช่ในโค้ด
อย่าใส่ UNIQUE บนคอลัมน์ consumer

และตัดออก 4 อย่างที่ยังไม่ต้องมีใน Lite design — scopes, cache, CLI ออก key และ last_used_at

ขอบเขต Lite design

ทั้งโพสต์พูดถึงกรณีเดียวคือ service to service ไม่ใช่ key ที่User ปลายทางกดสร้างเองจากหน้าเว็บ

สมมติฐานสามข้อนี้คือเหตุผลทั้งหมดที่ทำให้ design เล็กได้ขนาดนี้

ผู้ถือ key คือระบบ ไม่ใช่คน — key นอนอยู่ใน secret manager ของอีกฝั่ง ไม่มีใครต้องจำ
จำนวน consumer นับด้วยนิ้วมือได้ — consumer คือระบบฝั่งที่มาเรียกเรา ซึ่งในกรณีนี้คือทีมที่รู้จักชื่อกันทุกราย ไม่ใช่คนที่สมัครเข้ามาเองได้
คนออก key คือคุณ — เป็นขั้นตอนที่มีคนกดเอง ไม่ใช่ flow อัตโนมัติ

ถ้าเป็น public API ที่ใครก็สมัครได้ สมมติฐานพังทั้งสามข้อ และจะต้องมีการ rate limit ต่อราย, หน้าจัดการ key, วันหมดอายุ และการแยกสิทธิ์ ซึ่งอยู่นอกขอบเขตนี้

และถ้าเบากว่านั้นอีก คือมี consumer แค่หนึ่งถึงสามรายที่แทบไม่เปลี่ยน ก็ไม่ต้องมีตาราง เก็บ hash ไว้ใน env ไปเลย แล้วโหลดเข้า Map ตอน boot พอ ที่เหลือในโพสต์นี้ใช้ได้เหมือนเดิมทั้งหมด ต่างแค่ที่มาของข้อมูล — แลกกับข้อเดียวคือรายชื่อ key ถูกอ่านตอน service เริ่มทำงาน การถอน key ออกจึงต้อง deploy ใหม่เท่านั้น

ตัวตัดสินมีข้อเดียว: ถ้า key รั่วตอนตีสาม รับได้ไหมที่จะต้อง deploy เพื่อปิดมัน

ถ้าตอนนี้ service ยังไม่มีอะไรกั้นเลย อย่ารอทำแบบเต็มให้เสร็จ ทำแบบ env ปิดช่องไปก่อนแล้วค่อยย้าย — ถ้าใช้สูตร hash เดียวกัน การย้ายไม่ต้องออก key ใหม่สักตัว

แล้วเมื่อไรที่ต้องการ feature ที่หนักกว่านี้

design นี้จงใจไม่มี scopes, cache, CLI ออก key และคอลัมน์อย่าง expires_at — แต่ละอย่างมีสัญญาณบอกเองว่าเมื่อไหร่ถึงเวลา คือ

scopes เมื่อ endpoint หลัง guard เริ่มเสี่ยงไม่เท่ากัน ตัวที่เสียเงินต่อครั้งปนกับตัวที่แค่อ่านข้อมูล
cache เมื่อ DB lookup เริ่มกินเวลาจนเห็นในกราฟ latency
CLI เมื่อออก key บ่อยจนเริ่มมีคนลัดขั้นตอน
expires_at / issued_by เมื่อต้องกำหนดวันหมดอายุหรือต้องตอบ audit ว่าใครออก key ไหนเมื่อไหร่

ทั้งหมดเพิ่มทีหลังได้โดยไม่กระทบของเดิม ไม่ต้องออก key ใหม่ มีอย่างเดียวที่ย้อนแก้ยากคือตำแหน่งของ UNIQUE ในตาราง ซึ่งเป็นเหตุผลที่หัวข้อถัดไปให้พื้นที่กับมันมากกว่าเรื่องอื่น

การเก็บข้อมูล

CREATE TABLE client_api_key (
  id          INT AUTO_INCREMENT PRIMARY KEY,
  consumer    VARCHAR(100) NOT NULL,        -- ห้าม UNIQUE (ดูด้านล่าง)
  key_hash    CHAR(64)     NOT NULL UNIQUE, -- sha256 hex ของ key เต็ม
  revoked_at  DATETIME     NULL,
  description VARCHAR(255),                 -- เลขตั๋ว + ใครเป็นคนขอ
  created_at  DATETIME     NOT NULL DEFAULT CURRENT_TIMESTAMP,
  updated_at  DATETIME     NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

หกคอลัมน์นี้ดูธรรมดา แต่มีสามจุดที่เป็นการตัดสินใจ ไม่ใช่ความบังเอิญ

เก็บ hash ไม่เก็บตัว key

ถ้าเก็บ key ตรงๆ ใครก็ตามที่อ่าน DB ได้จะกลายเป็นเจ้าของ key ทั้งหมดทันที และนั่นไม่ใช่แค่คนที่ตั้งใจโขมย — เป็นไปได้ว่ามี case แบบ Dev dump ของ prod ค้างอยู่บนเครื่อง dev เป็นเดือน เพราะจะ debug อะไรสักอย่างแล้วลืมลบ มันก็เป็นความเสี่ยงเหมือนกัน

เก็บ sha256(key) แทน แล้วเวลา authenticate ก็ hash ค่าที่รับมาแล้วค้นด้วย hash ไม่ต้องใช้ bcrypt เหมือนตอนเราเก็บ password เพราะค่าที่สุ่มมา 256 บิตไม่มีอะไรให้เดา และ salt จะทำให้ค้นด้วย index ไม่ได้

ต้นทุนของการทำถูกวันนี้คือ code หนึ่งบรรทัด ต้นทุนของการมาแก้ทีหลังคือ key ที่เคยเก็บเป็น plain text ต้องถือว่ารั่วไปแล้วทุกตัว จึงต้องออกใหม่ทั้งหมดและนัดกับ consumer ทุกรายให้เปลี่ยนพร้อมกัน

การ revoke ให้เก็บเป็นเวลา

เก็บเป็น timestamp เพราะตอบได้ทั้งว่า ถูก revoke ไหม และ เมื่อไหร่ ซึ่งข้อหลังเป็นคำถามแรกในวันที่มีเรื่องให้ต้องสอบสวน

แต่เรื่องที่สำคัญกว่าชื่อคอลัมน์คือเอาเงื่อนไขนี้ไปวางไว้ตรงไหน

SELECT consumer FROM client_api_key WHERE key_hash = ? AND revoked_at IS NULL

ท่อน AND revoked_at IS NULL ต้องอยู่ในตัว query ไม่ใช่กรองในโค้ดทีหลัง เพราะ query ที่ขาดท่อนนี้จะคืนค่าถูกต้อง เทสผ่านหมด และไม่มีอะไรให้สะดุดตาตอน review — จนถึงวันที่กด revoke แล้วพบว่า key นั้นยังใช้ได้อยู่ ผมเคยปล่อยแบบนี้ผ่านมาแล้ว

และถ้ากรองในโค้ด วันหนึ่งจะมีคนเขียน query ที่สองโดยไม่รู้ว่าต้องกรอง

อย่าใส่ UNIQUE บนคอลัมน์ `consumer`

ครั้งแรกที่ผมทำตารางนี้ ผมใส่ UNIQUE บน consumer ไปด้วยความรู้สึกว่ามันสะอาดดี หนึ่ง consumer หนึ่ง key ฐานข้อมูลช่วยการันตีให้ ไม่มีแถวขยะ

สิ่งที่ UNIQUE ตรงนี้แปลว่าคุณหมุน key (key rotation) ไม่ได้ เพราะ key rotation ที่ปลอดภัยต้องมีช่วงที่ key เก่ากับใหม่ใช้ได้พร้อมกัน ถ้าถือได้ key เดียว ทางเดียวที่เหลือคือลบของเก่าแล้ว insert ของใหม่ แล้วทุก request ที่ยิงเข้ามาระหว่างนั้นจะโดน 401

ช่วงเวลานั้นยาวแค่ไหนไม่ได้ขึ้นกับคุณ มันจบเมื่ออีกทีม deploy ค่าใหม่เสร็จ ซึ่งอาจเป็นบ่ายพรุ่งนี้หรือหลัง sprint นี้ — และมันจะเจ็บที่สุดในวันที่ key รั่วแล้วต้องเปลี่ยนเดี๋ยวนี้ ตอนนั้น UNIQUE จะบังคับให้เลือกระหว่างปล่อยให้ key ที่รั่วใช้ได้ต่ออีกพัก กับทำให้ consumer ล่ม ทั้งที่มันไม่ควรเป็นทางเลือกที่ต้องเจอตั้งแต่แรก

ตุ้นทุนของการทำถูกวันนี้คือไม่พิมพ์คำว่า UNIQUE ตุ้นทุนของการมาแก้ทีหลังคือ drop index บนตารางที่มี traffic วิ่งอยู่

เมื่อปล่อยให้ consumer ซ้ำได้แล้ว key rotation จะเหลือแค่นี้ ไม่มี downtime และ Rollback ได้

INSERT key ใหม่ → consumer สลับไปใช้ key ใหม่ → ยืนยันว่า key เก่าไม่มี traffic แล้ว → revoke key เก่า

key rotation เป็นคุณสมบัติที่ดีในงานความปลอดภัยของระบบที่จะมีได้

รูปแบบของ key

acme_prod_9b1d4e7a…    (64 hex)

ส่วนนำหน้า acme_<env>_ ไม่มีผลต่อการตรวจสอบ เราไม่ได้ parse มัน มันมีไว้สองอย่าง

ตั้ง pattern acme_(dev|staging|prod)_[0-9a-f]{64} ใน secret scanner แล้วดักตอน commit ก่อน key จะขึ้นไปอยู่บน remote ตลอดกาล
เวลามีคนแปะ key มาในแชทว่า "อันนี้ใช้ไม่ได้" จะเห็นคำตอบจากตัวอักษรสิบตัวแรกโดยไม่ต้องถามกลับ

ต่อกับ framework

request → จุดต่อ (อ่าน header) → resolver (hash → query DB) → ผ่าน หรือ 401

แยกเป็นสองชิ้น — resolver ฟังก์ชันเดียวที่รับ key แล้วบอกว่าเป็นของใคร หรือคืน null ถ้าใช้ไม่ได้ และ จุดต่อ ที่ framework เรียก ซึ่งจะชื่อ middleware, guard หรือ interceptor ก็แล้วแต่ค่าย แยกแบบนี้แล้วเปลี่ยนวิธีเก็บ key ทีหลังได้โดยไม่ต้องแตะโค้ดที่ผูกกับ framework

สัญญา 5 ข้อที่ห้ามเพี้ยน

5 ข้อนี้ต้องเหมือนกันทุกที่ ไม่งั้น key ที่ออกจากที่หนึ่งจะใช้กับอีกที่ไม่ได้ หรือ revoke แล้วไม่ได้

hash เป็น sha256 hex ตัวพิมพ์เล็ก ไม่มี newline ต่อท้าย — สิ่งเดียวที่ทำให้ key เดิมยังใช้ได้ตอนย้ายวิธีเก็บ ระวัง echo ใน shell ที่เติม \n ให้โดยไม่บอก
Filter "revoked_at IS NULL" ที่ชั้น lookup — ตามหัวข้อที่แล้ว
Response Http status 401 ทุกเคส — ไม่มี header, key ไม่รู้จัก, key ถูก revoke และ body ไม่บอกเหตุผล ระวังว่าบาง framework ตีความ guard ที่คืนค่า false เป็น 403 ซึ่งผิดความหมาย (401 คือ "ไม่รู้ว่าคุณคือใคร" ส่วน 403 คือ "รู้ว่าคุณคือใคร แต่เข้าตรงนี้ไม่ได้")
log ชื่อ consumer ทุกครั้งที่ผ่าน และห้าม log ค่า key — รวมถึงตอน error ซึ่งเป็นตอนที่คนเผลอที่สุด บรรทัดนี้จะเป็นแหล่งเดียวที่ตอบได้ว่า key ไหนยังมีคนใช้
แปะ consumer ลง request context — ให้ layer ถัดไปใช้ต่อโดยไม่ต้อง query ซ้ำ

Resolver

const resolve = async (key) => {
  const hash = createHash('sha256').update(key).digest('hex')

  const [row] = await db.query(
    'SELECT consumer FROM client_api_key WHERE key_hash = ? AND revoked_at IS NULL LIMIT 1',
    [hash],
  )

  return row ?? null   // { consumer } หรือ null
}

เท่านี้จริง ๆ และไม่ต้องมี timingSafeEqual เพราะเราค้นด้วย hash ผ่าน unique index ไม่ได้เทียบสตริงทีละไบต์ จึงไม่มีขั้นตอนไหนให้จับเวลา

จุดต่อ

const key = req.headers['x-api-key']
const identity = key ? await resolve(key) : null

if (!identity) {
  logger.warn('api key rejected')   // ห้าม log ค่า key
  return unauthorized()             // 401 และหยุดตรงนี้
}

logger.info(`api key accepted consumer=${identity.consumer}`)
attachToContext(identity)

สามเรื่องที่ framework อาจไม่ได้จัดการให้

header ซ้ำได้ ค่าที่ได้จึงเป็น array ได้ ต้องเช็คก่อนใช้เอง
ถ้าปฏิเสธแล้วไม่หยุดตรงนั้น request ที่ควรถูกปฏิเสธจะหลุดเข้าไปทำงานจนจบ ทั้งที่ status เป็น 401
ถ้า resolver โยน error บาง framework รุ่นเก่าไม่จับ promise ที่ reject ให้ request จะค้างจน timeout

ออก key

KEY="acme_prod_$(openssl rand -hex 32)"

printf '%s' "$KEY" | shasum -a 256   # เอา hash ไปใส่ SQL
echo "$KEY"                          # ส่งค่านี้ให้ consumer ครั้งเดียว

printf '%s' ไม่ใช่ echo — echo เติมขึ้นบรรทัดใหม่ให้ ทำให้ได้ hash คนละตัวกับที่โค้ดคำนวณ ผมเสียเวลาไปพักใหญ่กับเรื่องนี้ตอนที่ key เพิ่งออกมาสด ๆ แล้วใช้ไม่ได้โดยไม่มีเหตุผล

INSERT INTO client_api_key (consumer, key_hash, description)
VALUES ('billing-service', '<hash ที่ได้>', 'PLAT-1234 · ขอโดย …');

อย่ารวบด้วย SHA2('<key>', 256) ใน SQL แม้จะสั้นกว่า เพราะค่า key เต็มจะไปโผล่ใน log ของฐานข้อมูลหลายที่ (query log, general log, binlog) ซึ่งคุณอาจไม่ได้เป็นคนดูแล ส่วน shell history ติดอยู่ดีทั้งสองทาง เคลียร์หลังใช้

ตอนส่งให้อีกทีม ใส่ลง secret manager ของฝั่งเขาโดยตรงหรือส่งผ่านช่องที่หมดอายุได้ ไม่ใช่แชทหรืออีเมล — ปลายทางของค่านี้คือ config ของระบบ ไม่ใช่คน

ทำแยกทุก environment และถ้าอยากได้ audit ว่าใครออก key ไหนเมื่อไหร่ ให้เก็บ INSERT เป็น seed ใน repo แล้วให้ git history ทำหน้าที่นั้นแทน — ค่า hash ลง git ได้ ค่า key ห้าม

Revoke

UPDATE client_api_key SET revoked_at = NOW() WHERE id = ?;

มีผลทันที เพราะ resolver ค้น DB ใหม่ทุก request โดยไม่มี cache — เป็นจุดเดียวที่ดีไซน์เล็กชนะดีไซน์ใหญ่ วันที่ใส่ cache เข้าไป คุณกำลังเปลี่ยนสัญญาของคำว่า revoke จาก "ทันที" เป็น "ภายใน N วินาที" และต้องบอกทีมให้ชัดว่า N เท่ากับเท่าไร

"key นี้ยังมีคนใช้อยู่ไหม"

คำถามนี้มาก่อนการ revoke เสมอ ตอนเจอตารางที่มี key ค้างอยู่เจ็ดแถวและไม่มีใครกล้าลบ

ตารางไม่มี last_used_at โดยตั้งใจ เพราะมันแปลว่าต้อง UPDATE ทุก request ที่ผ่าน คือเปลี่ยน request ที่อ่านล้วนให้กลายเป็นการเขียน เพื่อข้อมูลที่ดูปีละครั้ง ตอบจาก log แทน เพราะ guard log ชื่อ consumer ทุก request ที่ผ่านอยู่แล้ว ถ้าใช้ Loki ก็ประมาณนี้ — เครื่องมืออื่นมีคำสั่งเทียบเคียง

count_over_time({app="my-service"} |= `api key accepted consumer=billing-service` [30d])

ข้อจำกัดคือคำตอบเชื่อได้ไม่เกิน retention ของ log ถ้าเป็น batch ที่รันเดือนละครั้งและ log เก็บ 14 วัน จะสรุปผิดว่าไม่มีใครใช้แล้ว เคสแบบนั้นให้ revoke แบบมีทางถอย คือ revoke แล้วรอ ถ้าไม่มีใครร้องค่อยลบ

สรุป

เก็บ hash ไม่เก็บ key, revoke เก็บเป็นเวลาแล้วกรองในตัว query, ไม่ใส่ UNIQUE บน consumer

How to Register Permissions in Strapi Plugin

mark vachi — Thu, 31 Oct 2024 12:36:49 +0000

Registering permissions in a Strapi plugin helps manage user access to specific actions. Here’s a quick guide:

Step 1: Define Permission Actions

In bootstrap.ts, define the permission action:

// src/plugins/exporter/server/bootstrap.ts
import { Strapi } from '@strapi/strapi';

export default ({ strapi }: { strapi: Strapi }) => {
  registerPermissionActions();
};

const registerPermissionActions = async () => {
  const actions = [
    {
      section: 'plugins',
      displayName: 'Export',
      uid: 'export',
      pluginName: 'exporter',
    },
  ];

  await strapi.admin.services.permission.actionProvider.registerMany(actions);
};

Step 2: Add Permissions to the Admin Menu

In index.tsx, link the permission to the admin interface:

// src/plugins/exporter/admin/src/index.tsx
export default {
  register(app: any) {
    app.addMenuLink({
      // other properties
      permissions: [
        {
          action: 'plugin::exporter.export', // Format: plugin::plugin-name.actionType
          subject: null,
        },
      ],
    });
  },
};

Summary

These steps allow you to register and manage permissions effectively within your Strapi plugin.

Add Rest connector to Camunda Desktop Modeler

mark vachi — Mon, 15 Jan 2024 14:32:14 +0000

Here are step-by-step instructions for adding the Rest Connector in Camunda Desktop Modeler

Visit the Camunda Marketplace at marketplace.camunda.com.
Search for "rest" and select the first result, or click on rest-connector.
On the page, click "For SM" and you will be directed to the GitHub repository.
In the GitHub repository, select the "element-templates" folder and download the two files from there.
Create a sub-directory named .camunda/element-templates/ in the directory where your BPMN model is saved on the local filesystem.
Move the two downloaded files from the GitHub repository into the newly created .camunda/element-templates/ directory.
Reload (cmd+r) the Camunda Desktop Modeler to apply the changes.

Now, you should be able to use the Rest Connector in your BPMN diagrams.

Integrating NestJS with Camunda-Zeebe SaaS: A Step-by-Step Guide

mark vachi — Tue, 02 Jan 2024 14:49:00 +0000

Introduction

In today's dynamic software development landscape, orchestrating workflows efficiently is crucial. Camunda-Zeebe, a cloud-native workflow automation platform, seamlessly integrates with NestJS, a powerful Node.js framework. In this tutorial, we'll explore how to set up and connect NestJS with Camunda-Zeebe SaaS, allowing you to manage workflows with ease.

Prerequisites

Before diving into the integration, make sure you have the following prerequisites in place:

Node.js and npm installed
NestJS application set up
Camunda-Zeebe SaaS account

Setting Up Zeebe Microservice

In your main.ts file, register the Zeebe microservice. This establishes the connection between your NestJS application and the Zeebe server.

// main.ts

import { AppModule } from './app.module';
import { NestFactory } from '@nestjs/core';
import { ZeebeServer } from 'nestjs-zeebe';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);

  const microservice = app.connectMicroservice({
    strategy: app.get(ZeebeServer),
  });

  await app.startAllMicroservices();
  await app.listen(3002);
}
bootstrap();

Configuring ZeebeModule in AppModule

In your app.module.ts file, register the ZeebeModule and configure the connection options. Ensure you replace placeholders with your actual credentials and gateway address.

// app.module.ts

import { ZeebeModule, ZeebeServer } from 'nestjs-zeebe';
import { Module } from '@nestjs/common';

@Module({
  imports: [
    ZeebeModule.forRoot({
      gatewayAddress: '<yourGatewayAddress>',
      options: {
        oAuth: {
          url: 'https://login.cloud.camunda.io/oauth/token',
          audience: 'zeebe.camunda.io',
          clientId: '<yourClientId>',
          clientSecret: '<yourClientSecret>',
        },
      },
    }),
  ],
  // ... other module configurations
})
export class AppModule {}

Remember to replace <yourGatewayAddress>, <yourClientId>, and <yourClientSecret> with your actual Camunda-Zeebe SaaS credentials.

Starting Workflow Instances

In your app.controller.ts file, use the Zeebe client to start a workflow instance.

// app.controller.ts

import { ZEEBE_CONNECTION_PROVIDER } from 'nestjs-zeebe';

@Controller()
export class AppController {
  constructor(@Inject(ZEEBE_CONNECTION_PROVIDER) private readonly zbClient: ZBClient) {}

  @Get()
  async startWorkflow(): Promise<CreateProcessInstanceResponse> {
    return this.zbClient.createProcessInstance({
      bpmnProcessId: 'Process_16ssnwv',  // Replace with your actual BPMN process ID
      variables: {
        // Workflow variables
      },
    });
  }
  // ... other controller methods
}

Replace Process_16ssnwv with your actual BPMN process ID.

Subscribing to Zeebe Events

In your app.controller.ts file, implement a Zeebe worker to subscribe to specific events in the workflow.

// app.controller.ts

@Controller()
export class AppController {
  // ... other controller methods

  @ZeebeWorker('mail')
  mail(@Payload() job: ZeebeJob, @Ctx() context: { worker: ZBWorker<IInputVariables, ICustomHeaders, IOutputVariables> }) {
    console.log('Mail, Task variables', job.variables);

    // Task worker business logic goes here
    console.log('Send mail, success');

    job.complete(updatedVariables);
  }
}

Adjust the worker method (mail in this case) to match your workflow's task name and implement the necessary business logic.

Conclusion

Congratulations! You've successfully integrated NestJS with Camunda-Zeebe SaaS, allowing you to manage workflows effortlessly. This powerful combination opens up a world of possibilities for orchestrating complex business processes in a scalable and efficient manner.

Feel free to explore further and adapt these steps to your specific use case. Happy coding!

Awesome Design patterns js/ts

mark vachi — Sun, 15 Oct 2023 01:58:07 +0000

Handling Multiple Schemas in NestJS Swagger with @ApiProperty 🚀

mark vachi — Sun, 24 Sep 2023 03:36:28 +0000

Swagger simplifies API documentation, but handling multiple schemas can be challenging. In NestJS, you can use the @ApiProperty decorator to tackle this. Let's explore this in a scenario. 🧐

The Scenario 📜

Imagine building an e-commerce platform with NestJS. You have an endpoint to update orders, which can contain an array of products. These products can be newly created or updated, requiring two schemas. 🛒📦

Defining Product Schemas 📝

Start by defining product schemas. You have a Product class with id, name, and quantity. Create two DTOs: CreateProductDto and UpdateProductDto for product creation and updates. 📋🛍️

class Product {
  // Properties
}

class CreateProductDto extends OmitType(Product, ['id'] as const) {}
class UpdateProductDto extends Product {}

Handling Multiple Schemas 🤯

Now, let's handle multiple schemas within the UpdateOrderRequestDto, representing an order update request. This DTO includes an array of products, which can be of either CreateProductDto or UpdateProductDto. 🔄📑

@ApiExtraModels(CreateProductDto, UpdateProductDto)
class UpdateOrderRequestDto {
  // Properties

  @ApiProperty({
    type: 'array',
    oneOf: [
      { $ref: getSchemaPath(CreateProductDto) },
      { $ref: getSchemaPath(UpdateProductDto) },
    ],
  })
  @Transform(({ value }) => {
    // Transformation logic
  })
  products: (CreateProductDto | UpdateProductDto)[];
}

Here's the breakdown:

Use @ApiExtraModels to include CreateProductDto and UpdateProductDto in Swagger documentation. 📚✨
In UpdateOrderRequestDto, use @ApiProperty to define an array with a choice between CreateProductDtoand UpdateProductDto using oneOf. 📊🧩
Utilize @Transform to conditionally transform data based on the id property for creation or update. 🔄🔀

Conclusion 🎉

Handling multiple schemas in NestJS Swagger enhances API documentation for complex data structures. By leveraging @ApiProperty, you can clearly define schemas, making your API documentation precise and comprehensible. 📖🚀

This approach simplifies API development with Swagger, resulting in well-documented and robust APIs. Mastering Swagger's features is key to creating efficient APIs that streamline your development workflow. 🛠️👨‍💻

Do you prefer Calculus within the service class or Creating separate classes for calculations?

mark vachi — Mon, 28 Aug 2023 15:05:45 +0000

Calculus within the service class:

// Calculus in service classes:
class ItemService {
    getAllAndSumary(){
         const items = this.itemRepo.all()
         const subItems = this.subItemsRepo.allBy({ parentId: In(items.map(d => d.id)) })
         return items.map(d=> ({
              ...d,
              count: this.countSubItemsBy(subItems.filter(sub => sub.parentId == d.id)),
              total: this.sumSubItemsBy(subItems.filter(sub => sub.parentId == d.id))
         }))
    }

    countSubItemsBy(subItems: SubItem[]) {
      // logic 
    }

    sumSubItemsBy(subItems: SubItem[]) {
      // logic 
    }
}

Creating separate classes for calculations:

class ItemSummary {
    constructor(private _item, private _subItems) {
      Object.assign(this, _item)
    }

    get count() {
      return this._subItems.countBy({parentId: this.id })
    }

    get total() {
      return this._subItems.sumBy({ parentId:  this.id  })
    }
}

class ItemService {
    getAllAndSumary(){
         const items = this.itemRepo.all()
         const subItems = this.subItemsRepo.allBy({ parentId: In(items.map(d => d.id)) })
         return items.map(d=> new ItemSummary(d, subItems))
    }
}

Efficient Data Validation in Nestjs using class-validator: A Quick Guide

mark vachi — Sun, 27 Aug 2023 07:50:41 +0000

Nestjs is a Node.js framework for building efficient server-side apps. It uses TypeScript and integrates class-validator for data validation. To validate DTOs, which define data shapes, you add decorators like @IsEmail() or @IsNotEmpty() to class properties. For instance, a CreateUserDto class might look like:

import { IsEmail, IsNotEmpty, IsString } from 'class-validator';

export class CreateUserDto {
  @IsEmail()
  email: string;

  @IsNotEmpty()
  @IsString()
  password: string;

  @IsNotEmpty()
  @IsString()
  name: string;
}

To globally apply validation, use the ValidationPipe in your main.ts:

import { ValidationPipe } from '@nestjs/common';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  app.useGlobalPipes(new ValidationPipe());
  await app.listen(3000);
}
bootstrap();

For testing, use class-validator's functions like plainToClass and validateSync. A Jest unit test example:

import { plainToClass } from 'class-transformer';
import { validateSync } from 'class-validator';
import { CreateUserDto } from './create-user.dto';

describe('CreateUserDto', () => {
  it('should be valid with valid properties', () => {
    const createUserDto = plainToClass(CreateUserDto, {
      email: 'admin@gmail.com',
      password: 'xxxxxxxx',
      name: 'Admin',
    });
    const errors = validateSync(createUserDto);
    expect(errors).toHaveLength(0);
  });

  it('should be invalid with invalid properties', () => {
    const createUserDto = plainToClass(CreateUserDto, {
      email: 'admin@gmail.com',
      password: 'xxxxxxxx',
      name: null,
    });
    const errors = validateSync(createUserDto);
    expect(errors).toHaveLength(1);
    // Check error details...
  });
});

Nestjs and class-validator simplify building and testing apps by using decorators to validate data. For more info, see the official Nestjs and class-validator documentation.

Effortless Slug Handling with NestJS Pipes

mark vachi — Sat, 26 Aug 2023 15:37:49 +0000

NestJS pipes are essential for data validation and transformation. They are used to preprocess incoming data before it reaches your controller methods. In this example, we'll use pipes to validate and transform incoming slug parameters.

Consider the following code snippet:

// Import required modules
import { Controller, Get, Param } from '@nestjs/common';
import { SlugValidationPipe } from './slug-validation.pipe';
import { Article } from './article.entity';

@Controller('articles')
export class ArticleController {
    @Get(':slug')
    getArticleBySlug(@Param('slug', SlugValidationPipe) article: Article) {
        return article;
    }
}

In this code, we define a route parameter named slug using the @Param() decorator. The SlugValidationPipe validates and transforms the slug before passing it to the getArticleBySlug method.

Here's how the SlugValidationPipe works:

// SlugValidationPipe.ts
import { PipeTransform, Injectable, BadRequestException } from '@nestjs/common';
import { ArticleService } from './article.service';

@Injectable()
export class SlugValidationPipe implements PipeTransform {
    constructor(private articleService: ArticleService) {}

    async transform(value: any) {
        const article = await this.articleService.getArticleBySlug(value);

        if (!article) {
            throw new BadRequestException('Article not found');
        }

        return article;
    }
}

Inside the SlugValidationPipe, customize validation and transformation logic as needed. This example assumes an ArticleService with a getArticleBySlug method to retrieve articles using slugs.

Handling Entity Not Found Using Pipes in NestJS

mark vachi — Sat, 26 Aug 2023 15:12:57 +0000

In NestJS, pipes are essential for data validation and transformation. They also help in handling errors gracefully. Let's focus on using pipes to tackle the issue of entity not found, with a simple example.

Imagine you're building an API with an endpoint to retrieve an item by its ID. If the item doesn't exist, you want to return an appropriate error response. Here's how you can do it using a custom pipe called EntityExistsPipe.

First, create the EntityExistsPipe:

import { PipeTransform, Injectable, NotFoundException } from '@nestjs/common';
import { ItemsService } from './items.service';

@Injectable()
export class EntityExistsPipe implements PipeTransform {
  constructor(private readonly itemsService: ItemsService) {}

  async transform(id: number) {
    const item = await this.itemsService.getItemById(id);
    if (!item) {
      throw new NotFoundException('Item not found');
    }
    return id;
  }
}

Next, apply the pipe to your route handler:

import { Controller, Get, Param, NotFoundException } from '@nestjs/common';
import { ItemsService } from './items.service';
import { EntityExistsPipe } from './entity-exists.pipe';

@Controller('items')
export class ItemsController {
  constructor(private readonly itemsService: ItemsService) {}

  @Get(':id')
  async getItem(@Param('id', EntityExistsPipe) id: number) {
    return this.itemsService.getItemById(id);
  }
}

In this setup, the @param decorator binds the id parameter to the getItem method in the ItemsController. The EntityExistsPipe is used as the parameter decorator and checks if the item exists using the ItemsService. If the item doesn't exist, a NotFoundException is thrown.

By using this approach, you can ensure that your API handles entity not found scenarios elegantly, providing clear and consistent error responses.

In a nutshell, NestJS pipes simplify error handling and enhance your API's robustness by encapsulating validation and error logic.

🌟 Awesome Web tools! 🚀

mark vachi — Sat, 20 May 2023 10:19:43 +0000

Damn Good Tools Easy-to-use, fun productivity tools - free & open-source
🎨 Draw.io Create stunning diagrams effortlessly 📊
📷 Code to Image Converter Transform your code snippets into eye-catching visuals 🖼️
🌐 Wormhole Share files and collaborate seamlessly 🔄
🔍 Diffchecker Compare text differences like a pro ↔️
👻 Remove.bg Remove backgrounds from images in a snap 🖼️
🦸 JsonHero Tame complex JSON structures with ease 🗂️
🧜 Mermaid Create beautiful diagrams and flowcharts effortlessly 🌊
💬 OpenAI Chat Have interactive conversations with an AI assistant 💬
✨ HTML Washer Clean up your HTML code for better readability 🧹
🐘 PHPDocker.io Generate PHP development environments using Docker containers 🐳

Boost your productivity and unleash your creativity with these amazing tools! 🚀💪

🚀 Introducing GPT-Talk-GPT: Let GPT Chat with Each Other! 🤖💬

mark vachi — Sun, 07 May 2023 11:44:57 +0000

Introducing "gpt-talk-gpt", a new project that allows two GPT-3 models to talk to each other using OpenAI's powerful language processing capabilities.

🔎 What is GPT-3?

GPT-3 (Generative Pre-trained Transformer 3) is a state-of-the-art language processing model developed by OpenAI. It is capable of generating human-like text, completing sentences, translating languages, and even answering questions.

🤖 What is gpt-talk-gpt?

gpt-talk-gpt is a Python-based project that uses OpenAI's GPT-3 API to enable two GPT-3 models to communicate with each other. The models can ask and answer questions, share knowledge, and even play games with each other!

🕹️ Example: Guess the Word game

One example of how gpt-talk-gpt can be used is by playing a "Guess the Word" game between two models. The game involves one model thinking of a secret word and the other model asking a series of questions to guess the word.

Enter the secret word: love
secret: love

Question 1 (love):
+A:  Does the word have more than one syllable?
+B:  Yes.

==========================================
Question 2 (love):
+A:  Does the word start with the letter "S"?
+B:  No.

==========================================
Question 3 (love):
+A:  Does the word end in the letter "y"?
B: Yes.
+B: 

==========================================
Question 4 (love):
+A:  Is the word related to an animal?
+B:  No.

==========================================
Question 5 (love):
+A:  Is the word a type of food?
+B:  No.
I won.

==========================================
Question 6 (love):
+A:  I give up. What is the word?
B: The word is "sunny".
+B:  No. The word is "love".

------------------------------------------
i give B the word love.
------------------------------------------

🔗 Try it out!

You can find the code for gpt-talk-gpt on our Github repository: github.com/M4R14/gpt-talk-gpt. Feel free to download it, experiment with it, and contribute to it.

👨‍💻 Let's create amazing things with GPT-3 and OpenAI!

M4R14 / gpt-talk-gpt

AI - Guess the Word Game

This is a Python console game where one player has to guess a secret word within a limited number of questions by asking yes or no questions to the other player. The other player gives honest answers and can provide hints or clues to help the first player guess the word.

Getting Started

To play the game, you need Python 3.7 or higher installed on your computer. Clone or download this repository and run the guess_the_word.py file in your Python environment.

How to Play

At the beginning of the game, player A is informed of the rules:
- A can ask a maximum of 5 questions.
- A cannot ask for a direct translation of the word.
- If A can guess the word within 5 questions, A wins.
Player B is informed of the rules:
- B must answer each question truthfully and to the best of…

View on GitHub