DEV Community: Rajesh Kumaravel

QueryVault: a documented home for your SQL

Rajesh Kumaravel — Tue, 28 Jul 2026 07:04:09 +0000

🌐 Visit Query Vault

The scariest key on any developer's keyboard is Enter, right after a query they didn't fully read...

Every team that runs a serious database has a second, unmanaged database: the queries people actually use. They live in text files, chat scrollback, and one colleague's memory — and they get re-derived under pressure, against production, with auto-commit on.

QueryVault is my answer, now open source under MIT: a desktop app (macOS/Windows) that makes those queries first-class — documented, searchable, shareable — and executes them behind deliberate guard rails.

Repo: https://github.com/rajeshkumaravel/queryvault

The two problems in the trench coat

The tribal-query mess is really two problems occurring at the same moment:

Knowledge — the query isn't documented anywhere structured. Wikis hold text, but nothing connects the doc to execution, so it drifts silently.
Safety — the tools people execute with are DBA-grade IDEs whose defaults trust the operator. That's wrong for the support engineer running someone else's UPDATE at 2 a.m.

You look the query up because you're about to run it somewhere that matters — so QueryVault handles both in one surface. A saved query carries a title, markdown notes, tags, and named bind parameters (:customer_id, detected outside strings and comments, prompted at run time, remembered per query). Search is SQLite FTS5 across titles, SQL, notes, and tags. And execution is where the opinions live.

The safety model

Four layers, each enforced as low in the stack as it can be:

Typed intent, scaled to risk. Anything that isn't a SELECT requires typing RUN. On a profile tagged prod, the dialog turns red and demands the profile name.
Nothing commits itself. Writes run with autoCommit: false on a long-lived per-profile connection. The status bar turns amber while changes are pending; quitting rolls back.
Review before commit. Every uncommitted statement is inspectable — rows affected, bind values, and for in-grid cell edits the exact old → new. Commit opens a totals confirmation with Roll back instead beside it.
Read-only profiles refuse writes in the main process — not a disabled button in the UI.

The statement classifier is deliberately conservative: DML, DDL, and PL/SQL are guarded — and so is anything starting with WITH, even though CTEs are usually reads. Proving a CTE read-only across dialects is exactly the cleverness that eventually produces a false negative on production. Four extra keystrokes vs. an incident: easy trade.

One Oracle-specific wrinkle, stated honestly: DDL commits implicitly on Oracle — no client can prevent it — so the pending-transaction model tracks DML only, and DDL is caught at the confirmation step.

Architecture: a security decision that organizes the code

Three boundaries do the work:

The renderer is untrusted. sandbox: true, contextIsolation: true, nodeIntegration: false. Its entire capability surface is one function — window.api.invoke(channel, …) — typed end-to-end by a single shared IPC contract (src/shared/ipc.ts). New capability = new channel in that map + a handler in the main process. There is no second path.
All database work lives in the main process behind a DatabaseAdapter interface with two implementations: OracleAdapter (node-oracledb Thin mode — pure TCP, no Oracle Instant Client to install) and DemoAdapter (the bundled SQLite demo dataset: 250k orders, 1k customers, 5k tickets, so every screen works with zero setup — and contributors never need Oracle).
Safety enforcement sits below the UI, so no renderer bug can bypass it.

Things deliberately not built

No cloud/sync. Sharing is explicit JSON export/import (titles, SQL, notes, tags — never passwords or bind values). A sync backend means accounts, a server attack surface, and a governance conversation; local-first keeps the threat model auditable.
No plugin runtime. Extensibility is the compile-time DatabaseAdapter interface. A plugin system inside an app holding DB credentials is a privilege-escalation surface; a PR implementing an interface is a code review.
No ORM. The app's own store is hand-written SQL on better-sqlite3 (synchronous, in the main process — which removes a class of async-consistency issues in transaction bookkeeping).
No auto-updater. That's a network call and a code-execution path. Updates are new installers on GitHub Releases.

The verifiable parts of the security posture

Network: no outbound requests except to your configured Oracle DBs. Enforced by CSP default-src 'self' in src/renderer/index.html (blocks fetch/XHR/WebSocket/remote images — a tracking pixel pasted into a note can't load) and by bundling Monaco locally instead of a CDN.
Credentials: Electron safeStorage (macOS Keychain / Windows DPAPI). Encrypted blob on disk; plaintext never reaches the renderer.
Supply chain: two runtime dependencies — better-sqlite3 and oracledb. Everything else is build-time and compiled in.
Disclosure: SECURITY.md routes reports through GitHub private advisories, and explicitly classifies any third-party network contact as a vulnerability.

And the disclosed gap: builds are unsigned for now — right-click → Open on macOS, dismiss SmartScreen on Windows, or build from source.

Performance posture (no invented numbers)

No published benchmarks — the story is structural: virtualized grid, rows streamed in 5,000-row batches, a hard 50,000-row display cap so renderer memory is bounded, CSV export that streams all rows to disk regardless of the cap, FTS5 for search. The ~23-scenario Playwright suite exercises all of it against the 250k-row demo dataset — and the README's screenshots are generated by that suite, so the docs can't drift from the real UI.

Limitations & roadmap

Oracle-only today; unsigned builds; macOS is Apple-silicon only; no TCPS/wallet yet; cell editing is intentionally narrow (single-table SELECTs, edit refused unless exactly one row matches); no result filtering or snapshot diffing yet.

Roadmap: signing/notarization, TCPS/wallet, Postgres and SQL Server adapters, snapshot diffing, grid filtering, Linux packaging.

If this matches a problem you have: it's free, MIT, and works out of the box on demo data. A star on ⭐ (https://github.com/rajeshkumaravel/queryvault) helps others find it; issues and discussions are open, and PRs are warmly reviewed — a new DatabaseAdapter would be a genuinely great first contribution. Tell me where it breaks.

And that’s it!

I hope you found this article useful, and as always, thanks for reading!

Happy Coding!
RK

Kafka Offset Harbor: a local-first desktop window into Apache Kafka

Rajesh Kumaravel — Tue, 28 Jul 2026 06:48:14 +0000

🌐 Visit Kafka Offset Harbor

Kafka is the backbone of event-driven systems, but its data is invisible by design: there's no built-in window onto what's actually flowing through a topic. Answering "did this message arrive?", "why is this consumer behind?", or "can we replay from Tuesday?" usually means assembling CLI flags from memory.

Kafka Offset Harbor is my answer: a free, MIT-licensed desktop app (macOS, Windows, Linux-from-source) for browsing topics and messages, watching consumer lag, resetting offsets, and administering topics — built local-first, so your broker credentials never leave your machine.

Repo: https://github.com/rajeshkumaravel/kafka-offset-harbor

Why not the existing options?

CLI tooling is complete but hostile to exploration — right for automation, wrong for "show me what's in this topic."
Self-hosted web UIs invert the trust model: you deploy a service, hand it broker credentials, put it behind auth, and patch it forever. Reasonable for a platform team; overkill and a new attack surface for one engineer poking at staging.
Commercial desktop tools proved the form factor, but closed source is a hard sell in the security-reviewed environments where a Kafka GUI matters most.

The gap: a desktop tool whose security story is inspectable — where "credentials never leave your machine" is a property you verify in source, not a promise in a policy.

What you get

Explore — brokers (controller flagged), topics with partition/replication counts, consumer groups, all in one filterable tree; multiple saved connections with dev/stage/prod colour badges.
Read — fetch from newest/oldest/a specific offset/a timestamp, per partition or all; a virtualized grid smooth at thousands of rows; contains/regex/JSONPath filters across key, value, headers; payloads in the Monaco editor (pretty JSON/XML, raw, hex); tombstones, sizes and headers surfaced; JSON/CSV export.
Fix consumers — colour-coded per-partition lag, group state/members/assignments; offset resets to earliest/latest/offset/timestamp, guarded to idle groups only.
Produce & administer — keys, tombstones, custom headers, repeat-N test data, JSON-array import; topic create/delete, partition expansion, config editing.
Demo cluster — a full in-memory cluster (topics, messages, lagging groups) built in. Every feature works with zero setup and zero network access, because it's the real UI on a fake backend.

Architecture: the process boundary is the security boundary

Electron gives you a privileged Node.js main process and a Chromium renderer. Harbor's rule: everything sensitive — Kafka networking, credential decryption, disk persistence — lives only in main. The React renderer is untrusted display logic: it never sees a password and never opens a socket.

The renderer and main talk through one typed invoke bridge, against a contract declared in src/shared/ipc.ts. Every call returns a structured result envelope — success or typed error — so broker failures surface as values, not cross-process exceptions. Because CI type-checks both processes against the same contract, the app's entire privileged surface is readable in a single file, and extending it without declaring shapes is a compile error.

The adapter seam

Main reaches Kafka only through a ClusterAdapter interface with two implementations: KafkaJsAdapter (real clusters via kafkajs — PLAINTEXT, SSL/TLS, SASL PLAIN/SCRAM, AWS MSK IAM) and DemoAdapter (the in-memory demo cluster). The UI can't tell them apart — which is why demo mode is a first-class feature, UI development needs no broker, and a future backend is a third implementation rather than a rewrite.

Fetches are bounded (a window relative to newest/oldest/offset/timestamp — never an unbounded tail), and rendering is virtualized (TanStack Virtual), so cost tracks the viewport, not the topic size. No formal benchmarks yet — that's stated honestly, and the posture is structural.

The trade-offs, defended

Electron costs a Chromium runtime's memory. It buys one codebase with native installers on two platforms, the Monaco editor as a payload inspector (half the tool's value), and safeStorage — direct OS-keychain integration (Keychain/DPAPI/libsecret) with no custom crypto.

kafkajs over librdkafka bindings: the C client is faster, but a GUI's bottleneck is the human. Pure JS means the Kafka path needs no compile toolchain anywhere, keeping the parallel macOS/Windows CI build simple and the contribution barrier low. The only native module is better-sqlite3 (the connection store), isolated via the standard unpacked-module config.

Deliberately absent: telemetry, analytics, crash reporting, auto-update pings, cloud sync. "No phoning home" is only credible if it's total. Even the welcome-screen greeting comes from the system clock, because the obvious implementation (a weather API) ships your IP to a third party.

Security posture, verifiably

Credentials: encrypted via OS keychain, stored in local SQLite, decrypted only in main at connect time. The IPC contract has no call that returns a secret. MSK IAM stores no secret at all — short-lived tokens minted from your local AWS credential chain via aws-msk-iam-sasl-signer-js.
Network: outbound connections go to your configured brokers, full stop (plus AWS STS iff you use MSK IAM). Three runtime dependencies; none of the app source makes HTTP requests.
Supply chain: better-sqlite3's install-time binary downloader (prebuild-install + its HTTP/tar chain) is explicitly excluded from the packaged app — commented and auditable in electron-builder.yml.
Distribution: public GitHub Actions build (.github/workflows/release.yml) → tagged Releases. Builds are currently unsigned — disclosed, not hidden; signing is on the roadmap.
Guardrails: offset resets refuse non-idle groups with an explanation; full local reset requires typing CONFIRM.

Try it

Grab an installer from Releases and hit Explore the demo cluster — no broker needed. Against a real one:

git clone https://github.com/rajeshkumaravel/kafka-offset-harbor.git
cd kafka-offset-harbor && npm install && npm run dev

# optional local broker with seeded topics + a lagging consumer group
docker build -t koh-kafka:local docker/
docker run -d --name koh-kafka -p 9092:9092 koh-kafka:local
./docker/seed.sh

Limitations & roadmap

No Schema Registry/Avro decoding yet (binary payloads show raw/hex); Linux installers pending; builds unsigned pending certificates; MSK IAM uses the default AWS credential chain (no per-connection profile picker yet); explorer, not monitor — nothing pages you.

Roadmap, roughly in order: Schema Registry/Avro, Linux packaging, code signing, saved queries, measured performance baselines.

Get involved

It's MIT and contributions are genuinely wanted — ⭐ star the repo, open an issue, argue with a trade-off in discussions, or pick up a roadmap item (Schema Registry is the big one). What do you use to look inside Kafka today?

And that’s it!

I hope you found this article useful, and as always, thanks for reading!

Happy Coding!
RK

I Built a Browser So My Debugging Tools Could Stop Being Extensions

Rajesh Kumaravel — Tue, 28 Jul 2026 06:27:21 +0000

🌐 Visit Sheaf Browser

Every web developer's debugging toolchain is four browser extensions in a trench coat: modify headers, format JSON, edit cookies, mock requests. Each install wants access to every site you visit, and Manifest V3 has been quietly narrowing what the interesting ones are allowed to do.

Sheaf Browser takes a different route: move the tools below the extension sandbox entirely. It's a small open-source browser (Electron, MIT) where the four tools are native plugins in the browser's main process — the layer that actually owns the network.

Here's the what, why, who, when, where, and how — plus the security model, which is the real story.

What

Four tools, first-class, written from scratch:

Tool	Does
Letterhead	Add / replace / remove request and response headers; substring, glob (`example.com/*`) or regex scoping; profiles swap rule sets; the icon pulses while a rule is live on the current page
Folio	Every JSON response becomes a searchable, collapsible tree with copy-path on any key; `sheaf://folio` is a paste-anything scratchpad
Imprint	Read and edit cookies including `HttpOnly`, plus localStorage / sessionStorage
Mailroom	Stub, redirect, block or delay any request; record the session; export HAR

Plus the browser around them: tabs, private windows, ranked omnibox, bookmarks, downloads, find-in-page, docked resizable DevTools, and device simulation (viewport + DPR + UA) that works while DevTools is open.

Why

Three facts, one conclusion:

MV3's declarativeNetRequest is a static rule table with hard limits — designed so ad blockers can be audited, and consequently so debugging tools can't really exist.
HttpOnly cookies are invisible to extension JavaScript by definition — but not to the browser itself. The flag restricts page JS, not the embedder.
Electron doesn't implement declarativeNetRequest at all. An MV3 header extension in any Electron app installs, renders, and silently does nothing — so bundling existing extensions was never an option.

If you already keep a second browser for dev work (you do), the conclusion follows: build the second browser properly.

Who

For: developers, QA, and support engineers debugging web apps daily; security teams that prefer one inspectable MIT codebase over four third-party extensions with total site access.

Not for: daily driving. No Widevine, no sync, no password manager, no Web Store — deliberate non-goals. Mixing your personal sessions back into the dev browser would recreate the problem it solves.

When

Reach for it when you need to: send an Authorization or feature-flag header to one origin; read an API response as a tree; edit an HttpOnly session cookie in place; stub a flaky endpoint or delay a request to reproduce a race; export a HAR for a ticket; test a mobile viewport with DevTools open.

Where — one layer down

Sheaf browser capabilities all come from a single placement decision: the tools run in the browser's main process, below the extension sandbox. session.webRequest sees every request and response with no rule ceilings and no permission grants. The same asymmetry repeats everywhere — hard or impossible as an extension, straightforward as the embedder.

How

flowchart TB
    subgraph main["Main process"]
        TM["TabManager"]
        PH["PluginHost"]
        SQL["SQLite repos"]
        PROT["sheaf:// & sheaf-stub://"]
    end
    subgraph window["One BrowserWindow"]
        CHROME["Chrome renderer (React)"]
        TAB["Tab = WebContentsView, one per tab"]
        DT["DevTools view"]
        SPL["Splitter view"]
    end
    OVL["Omnibox overlay window"]
    CHROME -- IPC --> TM
    TM --> TAB & DT & SPL
    PH -- "session.webRequest" --> TAB

The compositing constraint. Each tab is a WebContentsView — a native Chromium view composited over the React-rendered chrome. Native views ignore DOM z-index, so nothing in the DOM can appear above page content — ever. Every overlay is therefore native too: the omnibox dropdown is a separate frameless window, DevTools is its own docked view, and the drag-to-resize splitter is a third thin view. Find your platform's compositing boundary in week one; it designs your component architecture for you.

The single-listener rule. Electron permits one webRequest listener per event per session — a second registration silently replaces the first. All plugins therefore register typed handlers with one PluginHost, which owns the real listeners: header handlers fold over the header map in order, the first mock rule to answer a request wins, and the host attaches per session so private windows get the same rules over a throwaway in-memory session.

Mocking without a proxy. Stubs are served from an internal sheaf-stub:// protocol; block/delay/redirect act directly in the pipeline; a completion-time recorder exports HAR.

sequenceDiagram
    participant Page
    participant PH as PluginHost
    participant SP as sheaf-stub://
    Page->>PH: GET /api/flaky-endpoint
    PH->>PH: mock rule matches (stub)
    PH-->>Page: redirect → sheaf-stub://…
    Page->>SP: fetch
    SP-->>Page: user-defined status / headers / body

Shared rule matching. Rule types and the URL matcher are one shared module compiled into both the UI and the network layer — the "rule is live here" pulse uses the same matcher that enforces the rule, so the interface can't lie about what the pipeline will do.

Security

The part that justifies the whole project:

Permission model, deleted. No "access to all sites" grants — the tools are the browser. Runtime dependency tree: two MIT packages (better-sqlite3, adm-zip); neither touches the network.
Isolation. One renderer process per tab; context isolation on; no Node in page contexts; typed preload-mediated IPC; javascript: URLs in the omnibox are never executed.
Zero own traffic — verified. No telemetry, no update pings, no third-party APIs. Favicons are captured locally at bookmark time; the new-tab greeting is clock-driven; spellcheck is macOS-native only. npm run verify launches the built app, records every request across a full scripted feature pass, and fails on anything unexpected — after first proving the recorder captures real traffic against a local echo server. Observers must earn trust before their silence means anything.
Provenance. A clean-room rule in CONTRIBUTING keeps GPL/AGPL implementations away from this MIT tree — contributors don't read competing sources while building a feature.
Distribution honesty. Unsigned builds, with the Gatekeeper/SmartScreen friction documented per platform; private vulnerability reporting via SECURITY.md; Electron's Chromium CVE stream treated as a standing upgrade obligation.

Limits, stated plainly

No DRM, no sync, partial Chrome-extension compatibility (DevTools-panel extensions mostly work; MV3 network extensions can't work in any Electron app), and throttling/touch emulation blocked on a CDP-vs-DevTools conflict — all on the record in the README.

Try it

Grab a build from Releases, or:

git clone https://github.com/rajeshkumaravel/sheaf-browser
cd sheaf-browser && npm install && npm run dev

npm run verify runs the same verification suite CI runs — including the network-silence check.

If the architecture interests you, ⭐ star the repo — https://github.com/rajeshkumaravel/sheaf-browser. Issues for header cases and rule syntax that annoy you, Discussions for arguing with a trade-off, PRs for the open problems — JWT decoder plugin, CDP throttling, shareable team rule sets. CONTRIBUTING.md (clean-room rule included) has the details.

And that’s it!

I hope you found this article useful, and as always, thanks for reading!

Happy Coding!
RK

Demystifying NPM and NPX: A Dive into Package Management

Rajesh Kumaravel — Tue, 13 Feb 2024 10:57:26 +0000

Demystifying NPM and NPX: A Dive into Package Management

In the ever-evolving landscape of web development, efficient package management has become an integral part of the workflow. Among the tools that have significantly shaped this ecosystem, npm (Node Package Manager) stands out as a key player. To complement npm, a tool called npx was introduced, adding a layer of versatility to the package management process.

The Birth of npx

As projects and their dependencies grew in complexity, developers encountered challenges in managing and executing packages seamlessly. npm addressed these issues by providing a centralized repository for JavaScript libraries and a reliable way to install, manage, and share packages. However, as projects expanded, the need for an improved execution environment became evident.

Enter npx, a tool bundled with npm (versions 5.2.0 and higher) to tackle the intricacies of package execution. Prior to npx, executing binaries from packages installed via npm required adding those binaries to the system's PATH. This approach had its drawbacks, including potential conflicts and difficulties in version management.

With npx, the execution of packages is streamlined. It allows developers to run binaries from packages without the need for a global install, making it easier to manage project-specific dependencies. Additionally, npx enables the execution of binaries from packages that are not globally installed, resolving the issue of having to specify the full path to the executable.

A Closer Look at npm

npm, the backbone of the Node.js package ecosystem, is used to install, manage, and share packages of code. It facilitates the discovery and distribution of packages, making it an essential tool for developers building applications with JavaScript, whether for the front end or back end.

The npm registry is a vast collection of open-source packages, providing developers with a rich set of tools, libraries, and frameworks to enhance their projects. Installing a package is as simple as running the command npm install <package-name>, and npm takes care of fetching and installing the specified package along with its dependencies.

npm not only excels in package installation but also facilitates version management. Developers can specify the desired version of a package in the project's package.json file, ensuring consistency across different environments and team members.

Unveiling npx's Power

While npm handles package installation, npx focuses on package execution. With npx, developers can run binaries from packages without installing them globally or specifying their full path. This dynamic execution environment enhances the flexibility and portability of JavaScript applications.

One of the noteworthy features of npx is its ability to run the latest version of a package, even if it's not installed globally. For example, running npx create-react-app my-app initiates a new React application using the latest version of Create React App without the need to install it globally beforehand.

Practical Use Cases

1. Running Commands from Packages

npx eslint --init

In this example, npx is used to initialize ESLint in a project without the need for a global ESLint installation. The command fetches the latest version of ESLint and executes it with the --init flag, guiding the user through the setup process.

2. Executing One-off Commands

npx serve

Here, npx serve runs a local development server using the 'serve' package without the necessity of installing 'serve' globally. This is particularly useful for ad-hoc tasks and quick development setups.

3. Trying Out New Tools

npx create-react-app my-new-app

Creating a new React application using Create React App is a common scenario. With npx, developers can try out the latest version of Create React App without installing it globally. This keeps the project's dependencies neatly scoped.

Conclusion

npm and npx, working hand in hand, provide a comprehensive solution for managing and executing JavaScript packages in modern development workflows. npm excels in package installation and version management, while npx adds a layer of convenience by facilitating the execution of packages without the need for global installs.

As the JavaScript ecosystem continues to evolve, these tools remain crucial for developers seeking efficient and scalable package management solutions. Whether you're a seasoned developer or just starting your journey, understanding npm and npx is fundamental to harnessing the full potential of the JavaScript ecosystem.

And that’s it!

I hope you found this article a useful primer for getting started with npx, and as always, thanks for reading!

Happy Coding!
RK

Introducing Github Dashboard: Open Source Project for Analytics and Data Visualisation

Rajesh Kumaravel — Wed, 28 Jun 2023 06:00:51 +0000

Introduction

Today, I am thrilled to announce the release of GitHub Dashboard, an open source project built using Node JS, Angular, Vercel, and Nx. This project aims to provide a comprehensive and intuitive way to analyse and visualise data from GitHub repositories. With OAuth login for authentication, GitHub Dashboard enables users to fetch repository discussions and pull requests data, empowering them to gain valuable insights through high-level metrics, cards, and graphs

Authentication and Data Retrieval

GitHub Dashboard leverages OAuth login for secure authentication, ensuring that only authorised users will be allowed to access the platform. By granting necessary permissions, users will be able to fetch discussions and pull requests data from public repositories. This feature allows developers, project managers, and data enthusiasts to explore and analyse repository activities effortlessly

Analytics and Data Visualisation

One of the key highlights of GitHub Dashboard is its powerful analytics and data visualisation capabilities. The dashboard presents a user-friendly interface, displaying insightful cards and interactive graphs that provide a bird's-eye view of repository metrics. With just a glance, users can quickly assess crucial statistics such as the count of discussions, pull requests, contributors, and more. These visual representations make it easier to grasp the repository's overall health and engagement

Flexibility and Customisation

GitHub Dashboard is designed to be highly flexible and customisable. Users can seamlessly navigate through different public repositories and switch between various projects of interest

Tech Stack

GitHub Dashboard is built using a powerful combination of technologies, including:

Node.js: A server-side JavaScript runtime environment, providing a scalable and efficient backend
Angular: A popular frontend framework for building robust and interactive web applications
Vercel: A cloud platform for static sites and serverless functions, ensuring reliable hosting and deployment
Nx: A powerful extensible development framework for building monorepo-based applications, improving code sharing and maintainability

Acknowledgments

Completing the GitHub Dashboard project wouldn't have been possible without the support and contributions of my amazing friends. Their dedication, expertise, and guidance have been instrumental in bringing this project to life.
I want to express my heartfelt gratitude to Mathew Jose Pallan, Harshit T Rao, Darshan Nagesh and Shreevas Karanth for their valuable input, feedback, and encouragement throughout this journey

Conclusion

With GitHub Dashboard, analysing and visualising data from public repositories has been made much easier and simpler. Be it a developer or a project manager or a data enthusiast, this open source project provides a powerful tool to gain actionable insights and understand the health and engagement of GitHub repositories.

Thank you for your support, and I look forward to your feedback

Explore Github Dashboard...

Happy Coding!

Angular Simple Slick without dependencies

Rajesh Kumaravel — Tue, 28 Feb 2023 05:56:25 +0000

Before we begin…

Let us understand why angular plugins developed using jQuery raises concern about compatibility and integration.

jQuery and Angular are both JavaScript libraries that provide different approaches to building web applications, and as such, they can be hostile to each other when used together. Some of the reasons why jQuery is hostile with Angular include

Conflicting syntax
jQuery and Angular have different syntaxes and ways of doing things, which can lead to conflicts and errors. For example, Angular uses directives and data binding to update the DOM, while jQuery uses selectors and methods
Performance overhead
Using jQuery along with Angular can result in performance overhead, as both libraries will be loaded and executed. This can impact the speed and efficiency of your application
Incompatibility issues
jQuery was not designed to work with Angular, and using the two together can result in incompatibility issues. This can cause errors and unexpected behaviour, making it difficult to diagnose and fix problems
Maintenance complexity
Using both libraries together can lead to code that is more complex and difficult to maintain. This can make it harder to make changes and updates to your codebase
Duplicate functionality
Many of the features and functionality provided by jQuery are already available in Angular. Using both libraries can result in duplicate functionality, which can increase the size and complexity of your codebase
Different approaches to DOM manipulation
jQuery is primarily a DOM manipulation library, while Angular provides a full-featured framework for building web applications. The different approaches to DOM manipulation can result in conflicts and inconsistencies when using both libraries together

Overall, while it is possible to use jQuery with Angular, it is generally not recommended due to the conflicts and challenges that can arise. It's generally best to stick with Angular's built-in capabilities and avoid using jQuery unless absolutely necessary

Angular Simple Slick / ngxslick is a lightweight and very complete Angular library for rendering simple slideshow of elements without any 3rd party dependencies

Supports dots and arrow navigation
Custom styling
Multi row support

Demo
NPM Plugin

Installation
Import in Angular
Options

Installation



$ npm i ngx-simple-slick --save

Import in Angular



import { BrowserModule } from '@angular/platform-browser';

import { NgModule } from '@angular/core';

import { NgxSlickModule } from 'ngx-simple-slick';



import { AppComponent } from './app.component';



@NgModule({

  declarations: [

    AppComponent

  ],

  imports: [

    BrowserModule,

    NgxSlickModule

  ],

  providers: [ ],

  bootstrap: [ AppComponent ]

})

export class AppModule { }



// demo.component.ts

export class DemoComponent implements OnInit {

  dataObj = new Array(10);

  constructor() { }

ngOnInit(): void {

  }

}



// demo.component.html

<ngxslick [dots]=true [loadStatus]="'done'">

   <ngxslick [dots]=true [loadStatus]="'done'">

      <ng-container *ngFor="let card of dataObj; let i = index">

        <div class="card">

          <figure>

            <img src="https://via.placeholder.com/150x150?text=NG%20Slick" />

            <figcaption>Card {{ i + 1 }}</figcaption>

          </figure>

        </div>

      </ng-container>

    </ngxslick>

</ngxslick>

Options

Option	Type	Required	Values	Description
loadStatus	@Input String	Optional	done / fetching	Status whether data loading is complete or fetching
dots	@Input Boolean	Optional	true / false	Dots navigation enabled if true; default arrow navigation is enabled
left	@Input String	Optional		Custom class for left navigation arrow
right	@Input String	Optional		Custom class for right navigation arrow

Wrapping Up

Why jQuery is hostile with Angular ?
Angular Simple Slick plugin without any dependencies

And that’s it!

I hope you found this article a useful primer for getting started with ngxslick, and as always, thanks for reading!

Check this out npm package for more reference NGX Slick

Happy Coding!
RK

How to write and publish your first NPM package

Rajesh Kumaravel — Mon, 19 Oct 2020 05:56:16 +0000

Before we begin…

Before we begin this, you should have the following things set up.

GitHub account
NodeJS and npm installed
npm account

Choosing a package name

You need to check whether the name is available for the npm package. If you are publishing unscoped (public) package; the name of the package should be unique.

However, if you are publishing a scoped (private) package then name does not have to be unique and name takes the format of @npm_username/package-name
Read more on

Initializing the npm package

Create a new directory and initialize using npm init

$ npm init

Initializing package will ask you a few questions for setup.
The default package.json file will be created in your project directory

{
  "name": "number-to-comma-format",
  "version": "1.0.0",
  "description": "Convert a number to comma separated format",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "RAJESH K",
  "license": "MIT"
}

Create the Node module

The main field in package.json defines the entry point of your package.

Let's create index.js file

$ touch index.js

Add the following code to index.js

'use strict'

const defaultOptions = {
  minimumFractionDigits: 2,
  maximumFractionDigits: 2
};

/**
 * @param  {Number} num - Number to be converted
 * @returns - Formatted number format
 */
function formatNumberToComma(num) {
  return Number(num).toLocaleString('en', defaultOptions);
}

module.exports = formatNumberToComma;

Add a README

It's a good idea to include documentation for your package so others know how to use it
Generally, a README should cover

Description of what your package does
Installation and usage instructions
Example code
Contribution guidelines
License used by the package Choosing the right license

Test your package locally

It is recommended to test your package locally before publishing to npm

Create and initialize new project outside package directory
Package can be installed by the following command

npm install number-to-comma-format

The problem with this is that your package is still not published yet so it isn't in npm. You need to reference your package locally while developing and testing it.
You could install the package using an absolute path to the package.

npm install /home/rajesh/dev/number-to-comma-format

Initialize Git

Create a new repository in github for your package and push the source code to git

git init
git add .
git commit -m "Initial commit"
git remote add origin https://github.com/rajeshkumaravel/numbertocommaformat.git
git push origin master

Publish the package to npm

Sign in to npm
You'll be prompted to enter username, password and email address which was used while registering to npm

npm login

Now you can publish your package to npm by

npm publish

Wrapping Up

VOILA...! Your package is now published on npm.

Initialize npm init
Add node module/source code
Test your package locally
git initialize
Publish package npm publish

And that’s it!

I hope you found this article a useful primer for getting started with publishing on npm, and as always, thanks for reading!

Check this out npm package for more reference Node express request id Source

Happy Coding!
RK

Google Firebase Functions : Setting and accessing environment variable

Rajesh Kumaravel — Fri, 11 Sep 2020 05:18:31 +0000

It's always a good idea to externalize application keys/secrets from code.
Google Firebase Functions has a feature that allows you to specify environment variables of key/value pairs using Firebase CLI and can be accessed by your code at runtime.

Set env variable

firebase functions:config:set config.key="SECRET_KEY" config.pass="SECRET_PASS"

NOTE: You must redeploy functions to make the new configuration available.

Deploy functions

firebase deploy --only functions

Accessing env variables

const secretKey  = firebase.config().config.key;
const secretPass = firebase.config().config.pass;

Retrieve all variables

firebase functions:config:get

Output:

{
  "config": {
    "key": "SECRET_KEY",
    "pass": "SECRET_PASS"
  }
}

Unset a variable

firebase functions:config:unset config.key

Let's consider using a file where we can keep all the environment variables.

env.json, a file that will contain all our environment variables.

{
  "config": {
    "host": "domain",
    "key": "SECRET_KEY",
    "pass": "SECRET_PASS"
  }
}

How to deploy the variables with the env.json file?

firebase functions:config:set env="$(cat env.json)"

Great! Now we can make a bulk update of our variables and keep track of them.

DEV Community: Rajesh Kumaravel

QueryVault: a documented home for your SQL

🌐 Visit Query Vault

The two problems in the trench coat

The safety model

Architecture: a security decision that organizes the code

Things deliberately not built

The verifiable parts of the security posture

Performance posture (no invented numbers)

Limitations & roadmap

Kafka Offset Harbor: a local-first desktop window into Apache Kafka

🌐 Visit Kafka Offset Harbor

Why not the existing options?

What you get

Architecture: the process boundary is the security boundary

The adapter seam

The trade-offs, defended

Security posture, verifiably

Try it

Limitations & roadmap

Get involved

I Built a Browser So My Debugging Tools Could Stop Being Extensions

🌐 Visit Sheaf Browser

What

Why

Who

When

Where — one layer down

How

Security

Limits, stated plainly

Try it

Demystifying NPM and NPX: A Dive into Package Management

Demystifying NPM and NPX: A Dive into Package Management

The Birth of npx

A Closer Look at npm

Unveiling npx's Power

Practical Use Cases

1. Running Commands from Packages

2. Executing One-off Commands

3. Trying Out New Tools

Conclusion

Introducing Github Dashboard: Open Source Project for Analytics and Data Visualisation

Introduction

Authentication and Data Retrieval

Analytics and Data Visualisation

Flexibility and Customisation

Tech Stack

Acknowledgments

Conclusion

Angular Simple Slick without dependencies

Before we begin…

Table of contents

Installation

Import in Angular

Options

Wrapping Up

How to write and publish your first NPM package

Before we begin…

Choosing a package name

Initializing the npm package

Create the Node module

Add a README

Test your package locally

Initialize Git

Publish the package to npm

Wrapping Up

Google Firebase Functions : Setting and accessing environment variable

Set env variable

Deploy functions

Accessing env variables

Retrieve all variables

Unset a variable