Coder Legion - Recent posts tagged web

How to Fix Core Web Vitals: LCP, CLS & INP | FloxoLab

Fri, 16 Oct 2026 15:50:00 +0000

Core Web Vitals are three numbers Google uses to measure how a page feels to a real person: how fast the main content loads, whether the layout jumps around while it does, and how quickly the page reacts when you tap or click. They are one part of page experience, which Google says its core ranking systems seek to reward. They do not override relevance or useful content.

This guide explains each of the three, plus the supporting numbers you will see in the same report, and then shows the real fixes that took this site's mobile Lighthouse performance score from 77 to 98. Nothing here is theory. It is the same work I run on client sites in an SEO audit.

What a good result looks like

In the July 2026 PageSpeed Insights test shown below, this site scored 98 on mobile and 100 on desktop using the same code. The two tests look different because mobile is run on a throttled, slower simulated device, so it always has less room to work with. Mobile is often the harder target, and it deserves priority when most of your visitors use phones. Google measures mobile and desktop field data separately, so check both instead of treating one Lighthouse score as the final answer.

Mobile: performance 98, LCP 1.9s, CLS 0, all vitals in the green.

Desktop: performance 100, LCP 0.5s, CLS 0, speed index 0.4s.

The three Core Web Vitals, one at a time

Everything on the scoreboard comes down to three real-user metrics. A page passes when 75 percent of real visitors fall inside the "good" band for each.

Metric	Measures	Good	Poor
LCP (Largest Contentful Paint)	Loading	2.5s or less	Over 4s
CLS (Cumulative Layout Shift)	Visual stability	0.1 or less	Over 0.25
INP (Interaction to Next Paint)	Responsiveness	200ms or less	Over 500ms

LCP: how fast the main thing loads

Largest Contentful Paint is the moment the biggest element in view finishes rendering, usually the hero image or the headline block. It is the reader's gut sense of "has this page loaded yet". What drags it down is nearly always one of four things: a heavy, uncompressed hero image, a slow server or host, render-blocking CSS and JavaScript that must run before anything paints, and web fonts that arrive late.

The fixes follow the causes. Compress and serve the hero as WebP at the right size, and preload it so the browser fetches it early. Use srcset so a phone pulls a small version and a desktop a larger one, instead of shipping one heavy file to every device. That is a separate lever from preloading: preload fetches the image sooner, srcset makes sure it is the right weight, and on a slow mobile connection the srcset part is often what saves the most. Cut or defer render-blocking scripts, and self-host your fonts instead of pulling them from a third-party domain. On this site LCP is 1.9s on mobile and 0.5s on desktop, and the single biggest lever was the hero image: right format, right size per device, preloaded.

CLS: whether the page holds still

Cumulative Layout Shift measures how much the content jumps around as the page loads. You have felt it: you go to tap a link, an image or banner loads above it, and the whole page shoves down. The usual culprits are images and embeds with no width and height set, ad or banner slots injected after load, and fonts that swap and reflow the text.

This is the most fixable vital, and the cheapest win on the list. Put explicit width and height (or an aspect ratio) on every image and iframe so the browser reserves the space before the file arrives. Give injected elements a fixed slot. Set font-display so a font swap does not reshuffle the layout. This site sits at a CLS of 0, and it got there almost entirely by adding size attributes to images.

INP: how fast the page answers you

Interaction to Next Paint replaced First Input Delay in March 2024. It measures the delay between you doing something, a tap, a click, a keypress, and the page actually showing a response, taking close to the worst interaction across the whole visit. A high INP is a page that feels sluggish and unresponsive, and the cause is almost always JavaScript hogging the main thread: heavy frameworks, big third-party scripts, and long tasks that block the browser from reacting. It is also the vital the most sites fail, so it is worth the attention.

The fix is to give the main thread less to do. Defer or split heavy JavaScript, hold third-party scripts off the critical path until the user needs them, and break long tasks into smaller pieces. This site now runs without client-side behavioral analytics, which removes one common source of third-party main-thread work. On sites that need analytics or other third-party scripts, keep them off the critical path and verify that delayed loading does not break consent or measurement. In the lab result shown above, total blocking time, the lab stand-in for INP, was 40 milliseconds.

The other numbers in the report

The same Lighthouse report shows three more metrics. These are lab diagnostics, useful for finding problems, but they are not the vitals Google ranks on.

First Contentful Paint (FCP). When the first text or image appears. An early signal that something is happening.
Total Blocking Time (TBT). How long the main thread was blocked during load. It is the lab proxy for INP, so lowering TBT usually lowers INP for real users too.
Speed Index. How quickly the page visibly fills in. On this site it shows 3.5s on mobile and lands in the amber band, while every actual vital is green. That is a fair reminder that the overall score is a blend, and a single amber lab number is not worth panicking over when the real-user vitals all pass.

Lab data and field data are not the same

There are two ways to measure all of this, and mixing them up causes a lot of confusion. Lab data is a single simulated test, like the Lighthouse run in the screenshots above, on a fixed device and connection. It is repeatable and great for debugging. Field data is what real Chrome users actually experienced over the last 28 days, and it is what Google uses for ranking. You can see your own field data in the Core Web Vitals report inside Search Console.

The practical order: use the lab test to find and fix problems fast, then watch the field data in Search Console to confirm real users feel the change. A lab score can be perfect while the field still lags, especially on a page that only just got fixed, because the field window is a rolling average. Reading that report is part of the wider habit covered in how to read your monthly SEO report.

When performance is only one concern on a specific URL, place this diagnosis inside an on-page audit of its indexability, search task, content, links, media, and validation. That keeps a Lighthouse number from replacing the wider page decision.

A mobile performance score also does not prove that Googlebot and customers receive complete content, usable navigation, accessible controls, or a working form. Check those separately with the mobile SEO checklist for rendering, content parity, and real phone tasks.

If the site has not launched yet, set media, script, layout-stability, and representative-template budgets in the SEO-friendly web design checklist. Performance is cheaper to protect in the design contract than to recover after every component is approved.

What actually moved this site from 77 to 98

The jump was not one clever trick. It was a short list of unglamorous fixes, each aimed at a specific metric:

Self-hosted the fonts. Pulling fonts from a third-party domain adds a connection and a render delay. Serving them from the same domain, preloaded, cut straight into LCP.
Reduced third-party JavaScript. The current site does not load client-side behavioral analytics. Removing or deferring non-essential third-party scripts reduces main-thread competition; verify consent and measurement before changing a production setup.
Responsive images in WebP. Every image ships as WebP at several sizes with srcset, so a phone downloads a small file and a desktop a larger one, never the wrong one.
Width and height on everything. Explicit dimensions on images and figures reserve their space, which is why CLS is 0.

None of that touched the design or the content. It is exactly the kind of finite, technical work that a small site needs once, not every month, which is the point I make in the technical SEO fixes agencies won't touch.

A quick checklist

Compress the hero image, serve it as WebP, and preload it.
Set width and height on every image, iframe, and embed.
Self-host fonts and set font-display so text does not reflow.
Remove unnecessary third-party scripts and defer the ones the site genuinely needs.
Test in the lab with PageSpeed Insights, then confirm in Search Console field data.

Core Web Vitals are one part of a technical SEO check, alongside indexing, schema, and titles. If you would rather have someone measure yours, find what is dragging them down, and hand you a prioritized fix list, that is exactly what the fixed-price SEO audit does: one report, a flat $150, no retainer, no ranking promises. If the work turns out to be ongoing, the monthly retainer picks it up from there. Get in touch to start.

Frequently asked questions

What are Core Web Vitals?

Three metrics Google uses to measure real-world page experience: Largest Contentful Paint (LCP) for loading, Cumulative Layout Shift (CLS) for visual stability, and Interaction to Next Paint (INP) for responsiveness. They come from real Chrome users and feed into ranking as a page experience signal.

What is a good Core Web Vitals score?

A page passes when 75 percent of real users see LCP at 2.5s or less, CLS at 0.1 or less, and INP at 200ms or less. In the Lighthouse lab test the overall score is good from 90 to 100. In the recorded July 2026 test, this site scored 98 on mobile and 100 on desktop.

Why is my mobile score lower than desktop?

Lighthouse tests mobile on a throttled, slower simulated device and connection, so the same page has less CPU and bandwidth to work with. Mobile is often the harder target, and it deserves priority when most of your visitors use phones. Google measures mobile and desktop field data separately, so check both instead of treating one Lighthouse score as the final answer.

Do Core Web Vitals affect SEO rankings?

Google says Core Web Vitals, together with other aspects of page experience, align with what its core ranking systems seek to reward. They are not a separate shortcut to higher rankings, and good scores do not override relevance or useful content.

Sources checked

Originally published on FloxoLab.

I Built a Directory for People Who Still Like Clicking Around the Internet

Sun, 04 Oct 2026 21:13:03 +0000

There are two ways to use the internet.

The first way is to search for one exact answer, get it, close the tab, and move on with your life.

The second way is to click something interesting, then click another thing, then somehow end up looking at a website that lets you listen to radio stations around the world or watch a person point directly at your mouse cursor.

I like the second version of the internet.

So I built base31.org.

It is a hand-built directory of useful tools, playful websites, public APIs, web apps, AI tools, and small projects that are worth opening in a new tab.

Not because every link will change your life.

Mostly because the web is more fun when it surprises you.

The internet is not boring. Finding it is.

There are still thousands of great websites out there.

Tiny browser tools that solve one specific problem.

Personal projects that are better than most huge platforms.

Interactive experiments that clearly took someone way too long to make — in the best possible way.

Public APIs that make you immediately want to build something.

The issue is that a lot of these projects are hard to find unless someone sends you a link, you see them in a random post, or you fall into a very specific search-engine rabbit hole.

That is what base31 is for.

It is a place to browse things like:

Useful browser tools
Creative web experiments
Free web apps
Public APIs
AI tools
Small independent websites
Tools built and hosted under the base31.org umbrella

The directory is meant to be slower than an app store, stranger than a listicle, and more useful than a bookmark folder you will never organize.

It is curated, not scraped

I did not want this to be a page filled with links that were automatically collected, barely described, and possibly dead by next week.

Every site on base31 is meant to be opened, checked, described, categorized, and tagged by hand.

The directory tracks useful details too:

When something was added
When it was last reviewed
Whether a listing has not been reviewed yet
Tags and categories to make browsing easier
A separate space for editor’s picks
A clear distinction between editorial picks and sponsored links

That last part matters to me.

An editor’s pick should mean I actually think it is worth visiting. A sponsored link should be clearly labeled as sponsored. Those are different things, and the site treats them differently.

No mysterious “recommended” section that turns out to be an advertisement wearing a fake mustache.

There is a search bar, but “Surprise me” is important too

Search is useful when you know what you need.

Maybe you need an image tool. Maybe you are looking for a free API. Maybe you need a browser app that does not require an account before it lets you click one button.

base31 lets people search names, URLs, descriptions, categories, and tags. You can use searches like:

#utility
tag:no-key
#image compress

But I also added a Surprise me option.

Because sometimes the best way to use a directory is to admit you have no idea what you are looking for.

That is how you end up discovering something useful.

Or something completely unnecessary that you will send to three people anyway.

Both outcomes are valid.

I started building the tools too

The project did not stay “just a directory” for very long.

I started building small tools and giving them their own homes on subdomains.

Right now, base31 includes tools for things like:

Compressing and resizing images in the browser
Removing image backgrounds without uploading files
Creating QR codes
Generating passwords and passphrases
Opening disposable email inboxes
Testing iframes
Exploring GitHub repositories
Creating app screenshots
Staying focused with a simple deep-work timer
Finding domain ideas
Playing a daily word game

Each tool can live on its own subdomain, while still being part of the larger base31 project.

imagecompressor.base31.org
backgroundremover.base31.org
githubexplorer.base31.org
screenshot.base31.org

I like that setup because every tool can stay focused.

Not every useful feature needs to be shoved into one giant dashboard with fifteen sidebars and a pop-up asking if you want to upgrade before you have even tried it.

Sometimes a tool should open, do its job, and get out of the way.

People can add their own sites

One feature I am especially excited about is community publishing.

Visitors can upload a small static site made with HTML, CSS, and JavaScript. The site can be hosted for free, shown in the directory, and discovered by other people browsing base31.

That means a project does not need to become a business to deserve a place online.

You can build a one-page experiment, a tiny game, a weird visual idea, a portfolio, or a simple tool, then actually let people see it.

The web needs more of that.

Not every project needs investors.

Not every project needs a five-year roadmap.

Not every project needs to “disrupt” anything.

Sometimes it just needs a URL.

How it is built

The main directory is built with Next.js and TypeScript.

The content is stored in editable JSON files, which makes it easier to maintain the directory without hard-coding every site into the interface. That data powers the categories, search, detail pages, editor’s picks, tags, and metadata.

The project also uses a Cloudflare Worker for shared features such as:

View counters and basic statistics
Votes
Community site publishing
Email and browser-notification subscriptions
A public discussion area

The tools themselves can be plain HTML, CSS, and JavaScript projects served through their own base31 subdomains.

That has been one of my favorite parts of building it.

A project can be small and simple without needing a giant framework around it. If a static tool does one thing well, it can have its own small corner of the internet.

Anatomy of a Short Link, When People Actually Want to Click?

Wed, 09 Sep 2026 22:07:23 +0000

Five small details that make a short url feel clearer, safer, and more memorable

A short link is not automatically a good link. Removing characters from a URL solves a length problem, but it does not answer the questions people ask before clicking: Where will this take me? Is it relevant? Can I trust it? Will I remember it later?

For web developers, the best short link is a small piece of interface design. Its domain, slug, surrounding copy, visual treatment, and technical behavior work together to reduce uncertainty. Get those details right and the link feels intentional instead of anonymous.

This guide explains five details that make a short link more useful across websites, email, social posts, documentation, QR codes, and messaging apps. The examples are global by design, so they also account for mobile users, multilingual audiences, and people navigating with keyboards or assistive technology.

1. A recognizable domain comes first

The domain is the first identity signal a person sees. A familiar brand domain tells the reader who is responsible for the destination. An unfamiliar or randomly generated domain makes the same destination feel harder to evaluate.

Compare these examples:

https://xmpl.co/a8K2p
https://docs.example.com/api/authentication

The first is shorter, but the second gives the reader more context. It identifies the organization, the product area, and the subject of the page.

A branded short link can combine the compactness of a short URL with the recognition of a known name:

https://go.example.com/api-auth

This does not prove that a destination is safe. It does, however, give people a useful signal to check. Security still depends on the actual destination, the service that manages the redirect, and the way your application handles abuse reports and compromised links.

Developer checklist

Use HTTPS for the short-link domain.
Keep the domain easy to read aloud and type.
Avoid confusing character combinations, such as lowercase l, uppercase I, and the number 1.
Use a branded domain when the link represents a company, product, or community.
Make the domain match the identity shown in the surrounding copy.

If you do not want to operate the redirect infrastructure yourself, Eslotmain is a link-shortening platform that offers custom slugs and branded domains. That can help keep a short link recognizable in a campaign or product flow. Treat the domain as an identity layer, not as a substitute for security review. A detailed url shortener tutorial post is available

2. The slug should explain the destination

The slug is the part of the short URL after the domain. It is a small space, but it can carry a surprising amount of meaning.

A random slug such as this is difficult to remember:

https://go.example.com/q7N4bP

A descriptive slug is easier to scan and repeat:

https://go.example.com/webinar-replay

The goal is not to put the whole page title into the URL. The goal is to provide the shortest useful description. Use lowercase letters, hyphens between words, and stable words that will still make sense after the campaign ends.

Good slugs are usually:

Specific: node-logging-guide says more than guide.
Compact: remove filler words and unnecessary dates.
Readable: use words instead of an opaque character string.
Stable: avoid changing the slug every time the page copy changes.
Audience-aware: use language your intended readers understand.

Be careful with dates, regional terms, and abbreviations. A slug such as summer-sale-uk may be useful for a time-limited campaign, but product-guide-en and product-guide-fr are clearer when you maintain separate language destinations. For a worldwide audience, decide whether language belongs in the slug, the destination path, or the campaign system. Do not make readers guess.

A descriptive slug is also helpful when someone sees a link without its surrounding page, such as in a screenshot or a copied message. It cannot reveal every redirect detail, but it gives the reader an immediate reason to understand the link.

3. The words around the link must set expectations

A short URL cannot do all the communication by itself. Link context tells people why the destination matters and what will happen after the click.

Weak copy:

Read more: https://go.example.com/r4T9

Clearer copy:

Read the WebAuthn implementation guide for a browser-ready passkey flow: https://go.example.com/webauthn-guide

The second version answers three questions before the click:

What is the destination?
Why should I open it?
What kind of content will I find?

This is also an accessibility requirement, not just a conversion tactic. WCAG guidance says that a link's purpose should be understandable from its text or its immediately associated context. The U.S. Web Design System similarly advises developers to use unique, meaningful link text and avoid generic phrases such as “click here” and “read more”

Use the link itself as the meaningful phrase where possible:

<p>
  Read the
  <a href="https://go.example.com/webauthn-guide">
    WebAuthn implementation guide
  </a>
  before adding passkey support.
</p>

Avoid relying on a title attribute to repair vague link text. The visible words should do most of the work. If the link opens a PDF, starts a download, requires a login, or leaves your site, say so in the visible text or its nearby context.

For international audiences, keep the context direct and easy to translate. Short sentences with concrete nouns are easier to understand than clever calls to action.

4. Visual treatment should make the click obvious

People should not have to move a pointer around the page to discover what is clickable. A link needs a visible affordance, which is a cue that communicates how an element can be used.

A dependable text-link treatment includes:

A consistent color that is distinct from ordinary text.
An underline or another non-color cue in body copy.
A visible hover state.
A visible keyboard focus state.
Sufficient contrast against the background.
A target large enough to tap comfortably on a phone.

Do not style ordinary headings or noninteractive cards to look like links. That creates false signals. Nielsen Norman Group describes consistency, placement, color, borders, and familiar web conventions as important cues for recognizing clickable elements. Its practical lesson is simple: if a design system teaches users one visual pattern for links, use that pattern everywhere.

The HTML should preserve native link behavior:

<a class="text-link" href="https://go.example.com/docs">
  Read the developer documentation
</a>

.text-link {
  color: #075985;
  text-decoration: underline;
  text-underline-offset: 0.15em;
}

.text-link:hover,
.text-link:focus-visible {
  color: #0c4a6e;
  text-decoration-thickness: 0.14em;
}

.text-link:focus-visible {
  outline: 3px solid #f59e0b;
  outline-offset: 3px;
}

Do not remove the outline without replacing it with an equally visible focus style. A keyboard user must be able to find the active link, and pressing Enter should activate it. Use a real <a href="..."> for navigation, not a clickable <div> that forces you to recreate browser behavior with JavaScript.

5. The redirect should feel safe and predictable

A short link is a promise: the destination should match the expectation created by the link. Broken redirects, unexpected login walls, surprise downloads, and unrelated landing pages damage trust quickly.

Before publishing a short link, check the full path from click to destination:

Does the short URL use HTTPS?
Does it redirect quickly on mobile and desktop?
Does it land on the page named in the link text?
Does it preserve the intended language or regional experience?
Does it avoid unnecessary redirect chains?
Does it remain valid after the campaign or product release changes?
Can you disable or update it if the destination becomes unsafe?

Analytics can help you detect problems and improve future links, but measurement should not make the experience opaque. Explain tracking where your privacy rules require it, collect only what you need, and protect link analytics as user data.

A useful short-link dashboard can show patterns such as clicks, locations, devices, and referrers. Eslotmain publicly describes these analytics as part of its platform, along with quick link creation and a free option for personal links with no credit card required. Developers can use those signals to compare distribution channels, spot a broken campaign, or learn whether a mobile audience needs a different landing page. Analytics should answer a product question, not become a reason to add needless tracking.

Putting the five details together

Here is a practical example for a developer newsletter:

<p>
  The new release adds passkey support. See the
  <a href="https://go.example.com/passkeys-node">
    Node.js passkey integration guide
  </a>
  for setup steps and browser notes.
</p>

The link works because each part has a job:

Link detail	What the reader learns
Recognizable domain	Who owns or manages the link
Descriptive slug	The general destination topic
Surrounding copy	Why the destination is relevant
Visible link styling	What can be clicked or tapped
Predictable redirect	What will happen after activation

A short link does not need to be loud. It needs to be legible, specific, and consistent with the experience that follows it.

A quick pre-publish test for web developers

Run this five-minute review before you share a link in production:

Read it without context. Can you infer the topic from the domain and slug?
Read the sentence only. Does the link explain its destination and purpose?
Use the keyboard. Can you reach the link with Tab and activate it with Enter?
Test a phone. Is the target easy to tap, and does the redirect load quickly?
Follow the complete redirect. Does the final page match the promise?
Check a copied version. Does the link remain understandable when pasted into a message?
Review the data plan. Are analytics transparent, necessary, and handled according to your privacy obligations?

Final takeaway

The anatomy of a link people want to click is not complicated. Start with a recognizable domain, add a readable slug, explain the destination in nearby text, make the link visibly interactive, and keep the redirect safe and predictable.

Shortening a URL is only the mechanical step. The real work is reducing doubt. When the link tells people where they are going, why it matters, and what to expect, a click becomes a reasonable decision instead of a gamble.

Frequently Asked Questions

What makes a link more clickable?

A link becomes more clickable when its destination and benefit are clear before activation. Descriptive link text, a recognizable domain, a readable slug, strong visual treatment, and a reliable redirect all reduce uncertainty.

Should developers use descriptive link text instead of “click here”?

Yes. Descriptive text helps sighted readers scan the page and helps screen-reader users understand a list of links out of context. Use words that identify the destination or action, such as “download the API reference PDF” or “view the passkey guide.”

Are short links safe to click?

Short links are not automatically safe because they hide the final destination. Use HTTPS, publish links through a service with abuse controls and management tools, provide useful context, and verify unfamiliar links before opening them.

Do branded short links improve trust?

They can improve recognition because the visible domain is connected to a known organization or product. Branded links do not guarantee that a destination is safe, so they should be combined with secure redirects, honest link context, and regular destination checks.

Do short links help SEO?

A short link can improve sharing and readability, but shortening a URL alone does not guarantee higher search rankings. For SEO, focus on the final page's content, canonical setup, crawlability, internal linking, and a clear user experience.

The Story Behind Accesstive: Web Accessibility. Done Right.

Wed, 09 Sep 2026 10:00:35 +0000

It's more than our tagline. It's the reason Accesstive exists.
And it's why we're telling you this before talking about our product.
In 2025 alone, 8,667 ADA web accessibility lawsuits were filed in the United States, a 37% increase year over year. Across Europe, the European Accessibility Act (EAA) is now in force, and organizations that fail to meet accessibility requirements can face significant financial penalties and legal risk.
Most organizations don't discover they have an accessibility problem until they receive a complaint, lose a customer, or are asked to prove compliance.
We believe that shouldn't be the case.
That's one of the reasons we built Accesstive and why we made our Free Accessibility Checker available to everyone.

What Most Accessibility Tools Get Wrong

Search for "accessibility checker" and you'll find hundreds of scanners, overlays, and widgets promising quick fixes or instant compliance.
The reality is different.
An automated scan can identify many accessibility issues, but it cannot evaluate everything. Likewise, a widget alone doesn't make a website compliant or accessible for every user. Accessibility requires continuous attention, thoughtful remediation, and, in many cases, human expertise.
The challenge isn't finding another scanner.
The challenge is knowing what matters, fixing issues correctly, tracking progress over time, and having the documentation to demonstrate the work that's been done.
That's where many organizations struggle.

Why We Built Accesstive

For more than 15 years, we've been building enterprise websites and digital experiences for organizations across industries. Throughout that journey, one challenge kept repeating itself: web accessibility.
The problem wasn't a lack of accessibility tools. There were scanners, overlays, consultants, manual audits, and reporting tools. The real challenge was that they all worked separately. Agencies and in-house teams had to switch between multiple tools, track fixes in spreadsheets, coordinate audits, and maintain documentation on their own.
We faced the same challenge while delivering websites for our clients.
So we built an internal solution to simplify the process. It helped our team monitor accessibility, manage issues, track remediation, and keep everything in one workflow. It wasn't created as a product. It was built to solve a real problem we experienced every day.
As more clients started facing the same challenges, we realized this wasn't unique to us. It was a problem shared by agencies, developers, businesses, and public sector organizations around the world.
That's how Accesstive was born.
We didn't build another accessibility scanner.
We didn't build another overlay.
We built a Continuous Accessibility Platform that helps web teams find issues, understand them, fix them, monitor progress, and document everything in one place.

More Than a Free Accessibility Checker

For organizations taking their first step, we created the Free Accessibility Checker.
It goes far beyond a traditional automated scan.
In seconds, you can scan any public website, launch a Live Audit that highlights accessibility issues directly on the webpage, review findings against relevant WCAG success criteria, explore AI-powered remediation guidance, and download a detailed accessibility report.
The goal isn't just to generate another list of issues.
It's to help teams understand what needs attention, why it matters, and how to move forward with confidence.
AI When It Helps. Human Experts When It Matters.
We believe automation should support accessibility, not replace expertise.
That's why every organization can book a free first consultation with one of our accessibility experts.
Whether you need help interpreting your scan results, prioritizing remediation, validating complex accessibility issues, or planning your compliance journey, our specialists are available to guide you.
AI helps you move faster.
Human expertise helps you make the right decisions.
We believe organizations need both.

Accessibility Is Never "Done"

Websites evolve. Content changes. New features are released. Regulations continue to evolve.
Accessibility should evolve with them.
That's why Accesstive is built around continuous accessibility instead of one-time scans or one-off compliance projects. Our goal is to help organizations make accessibility part of their everyday web operations, not something they only think about after receiving a legal notice.
Our mission is simple: Help every web team Find, Fix & Prove accessibility with confidence.
Help agencies, developers, businesses, and public sector organizations avoid the fragmented accessibility journey we experienced for years.
Because Web Accessibility. Done Right. isn't just our tagline.
It's the standard we're committed to helping every web team achieve.
Learn more about Accesstive or run a free accessibility scan at
https://accesstive.com/free-accessibility-checker/

# Designing a Non-Custodial Multichain Wallet Hub for a Web3 Marketplace

Fri, 28 Aug 2026 07:40:06 +0000

Designing a Non-Custodial Multichain Wallet Hub for a Web3 Marketplace

Building a marketplace that supports cryptocurrency payments creates an architectural decision very early:

Who controls the keys?

While developing the open-source MyZubster ecosystem, I decided that the Marketplace and virtual world should be able to interact with multiple blockchain networks without turning the platform into a custodian.

The result is an experimental multichain Wallet Hub designed around four external settlement rails:

Ethereum (ETH)
Bitcoin (BTC)
Monero (XMR)
Tari

alongside MYZ, which remains a separate internal ecosystem accounting/reward layer.

The core rule: never put private keys in the application

A web application does not need a user's seed phrase to display a receiving address.

It does not need private keys to create marketplace settlement intent.

And it should not automatically gain authority over someone's cryptocurrency simply because they use the Marketplace.

The architecture therefore follows a simple boundary:

Marketplace → Settlement Intent → Public Address → User Wallet → Blockchain

The wallet owner remains responsible for signing the transaction.

The blockchain remains responsible for settlement.

The Marketplace coordinates the interaction.

Public configuration, private authorization

The frontend can receive public wallet configuration through environment variables:

REACT_APP_WALLET_ETH=
REACT_APP_WALLET_BTC=
REACT_APP_WALLET_XMR=
REACT_APP_WALLET_TARI=
These variables are intended for public receiving addresses only.

They must never contain:

seed phrases
private keys
extended private keys
wallet passwords
signing secrets

This distinction sounds obvious, but it becomes extremely important once a project starts supporting several blockchain networks.

Extending the Marketplace

The MyZubster Marketplace already supported multiple exchange modes and currencies.

The current work extends the settlement model with Bitcoin and Ethereum so listings can identify their intended rail.

Conceptually, a listing can look like this:

{
  "title": "Community gardening service",
  "price": 0.0001,
  "currency": "BTC",
  "exchangeMode": "payment"
}

But this object represents commercial intent, not proof of payment.

Creating the listing does not move Bitcoin.

Creating an order should not automatically move Bitcoin either.

Actual settlement happens independently.

Settlement is a state machine

One of the useful lessons from building this architecture is that application state and blockchain state should not be confused.

A transaction flow can be modeled as:

ORDER CREATED
      ↓
SETTLEMENT REQUESTED
      ↓
TRANSACTION AUTHORIZED
      ↓
TRANSACTION BROADCAST
      ↓
SEEN BY NETWORK
      ↓
CONFIRMED
      ↓
SETTLED

The Marketplace should only mark an external cryptocurrency payment as settled after obtaining appropriate evidence from the corresponding network.

This becomes particularly important in a multichain environment because confirmation semantics are not identical across Bitcoin, Ethereum, Monero and Tari.

The Wallet Hub

Inside MyZubster, the Wallet Hub acts as the interface between the Marketplace/virtual world and the supported settlement rails.

The intended architecture is:

                   MyZubster World
                         │
                         ▼
                    Marketplace
                         │
                         ▼
                    Wallet Hub
                  /      |      \
                 /       |       \
               ETH      BTC      XMR      TARI
                │        │        │         │
                ▼        ▼        ▼         ▼
             Network  Network  Network   Network

The important part is what is not inside that diagram:

private-key custody.

Different chains, different adapters

A multichain system should also avoid pretending every blockchain behaves like Ethereum.

A cleaner implementation uses network-specific adapters behind a common settlement interface.

Conceptually:

const settlementAdapters = {
  ETH: ethereumAdapter,
  BTC: bitcoinAdapter,
  XMR: moneroAdapter,
  TARI: tariAdapter
};

Each adapter can eventually implement operations such as:

getReceivingAddress()
validateAddress()
getTransactionStatus()
verifyPayment()

Signing can remain outside the Marketplace boundary.

This gives the application a common interface without erasing the differences between networks.

Bitcoin

Bitcoin integration can use an Electrum-based workflow for wallet/network interaction.

The important separation remains:

Marketplace
    ↓
public Bitcoin address
    ↓
external/user-controlled signing
    ↓
Bitcoin network
    ↓
confirmation verification

A transaction ID alone should not automatically mean "paid."

Confirmation status matters.

Monero

Monero requires its own integration model.

A Monero daemon and wallet RPC can provide the infrastructure needed for verification and wallet operations without exposing sensitive wallet material to the browser.

Again, the browser should never receive:

private spend key
private view key
seed
wallet password

Only the minimum information required by the application should cross the boundary.

Ethereum and Tari

ETH and Tari are exposed through the same Wallet Hub abstraction, while their network-specific adapters can evolve independently.

This is useful because the UI doesn't need to understand every protocol detail.

It only needs to understand something like:

asset
network
public destination
amount
transaction reference
status
confirmations/evidence

The backend adapter handles the chain-specific interpretation.

Security before convenience

It is tempting to build a "Pay" button that owns everything:

click
→ sign
→ send
→ confirm

That is convenient, but it dramatically changes the threat model if the server or frontend controls the keys.

For MyZubster, the safer initial architecture is deliberately less magical:

✓ public receiving addresses
✓ user-controlled authorization
✓ network-specific verification
✓ explicit settlement state
✓ separation of internal and external assets

✗ seed storage in frontend
✗ private keys in Git
✗ automatic custody
✗ assuming an order equals payment
✗ assuming a broadcast transaction equals confirmed settlement
Connecting the Marketplace to the virtual world

This work becomes more interesting because MyZubster isn't only a conventional marketplace.

The ecosystem is also experimenting with an interactive digital world containing community spaces, characters, chat, missions and other modules.

The longer-term architecture becomes:

Identity
   │
   ├── Community
   │
   ├── Missions
   │
   ├── Marketplace
   │       │
   │       └── Wallet Hub
   │              ├── ETH
   │              ├── BTC
   │              ├── XMR
   │              └── TARI
   │
   └── MyZubster World

That creates the possibility of virtual-world interactions that lead to real settlement rails while maintaining a clear security boundary.

Open-source implementation

The Wallet Hub work is being developed publicly in the MyZubster repository.

The current implementation is tracked in:

PR #811 — Connect metaverse market to multichain wallet hub

At this stage, it should be treated as active development rather than a claim of a production-ready financial system.

CI, security testing, deployment configuration and transaction-verification workflows are all part of moving from architecture to production.

What comes next

The next steps are particularly interesting from an engineering perspective:

complete CI and security validation;
finish deployment configuration for each public wallet rail;
implement network-specific transaction verification;
connect marketplace orders to settlement evidence;
define confirmation policies per network;
improve auditability without exposing sensitive wallet information;
keep internal MYZ accounting clearly separated from external cryptocurrency settlement.

The bigger lesson is simple:

Multichain doesn't have to mean multi-custodial.

A marketplace can coordinate several blockchain networks while keeping transaction authorization where it belongs:

with the wallet owner.

MyZubster is an open-source project under active development.

GitHub:
https://github.com/MyZubster-Ecosystem/myzubster

Wallet Hub implementation:
https://github.com/MyZubster-Ecosystem/myzubster/pull/811

Understanding the OWASP Top 10 with Real-World Examples

Fri, 07 Aug 2026 12:20:33 +0000

Understanding the OWASP Top 10 with Real-World Examples

Web applications have become the backbone of modern businesses, handling everything from online payments and customer accounts to healthcare records and enterprise data. As applications grow more complex, they also become attractive targets for attackers looking to exploit security weaknesses. This is why developers need to understand the most common application security risks before deploying software to production.

The OWASP Top 10 is one of the most widely recognized resources for application security, highlighting the most critical risks affecting web applications. Many development teams also rely on independent security experts such as 7Asecurity to validate their applications through penetration testing and security assessments, helping identify vulnerabilities that automated tools alone may miss. Understanding these risks is the first step toward building more secure software.

What Is the OWASP Top 10?

The OWASP Top 10 is a regularly updated awareness document published by the Open Worldwide Application Security Project (OWASP). Rather than listing every possible vulnerability, it focuses on the categories that present the greatest risk to organizations based on real-world attack data and industry research.

Developers can use it as a practical checklist during application design, development, testing, and maintenance. This becomes particularly important as applications increasingly rely on APIs, cloud services, automation, and AI-driven components. For additional context on how modern AI applications operate behind the scenes, understanding what happens behind the scenes of an AI-powered application can help illustrate the range of components and interactions that developers need to consider when assessing application security.

1. Broken Access Control

Access control determines what users are allowed to do within an application. When implemented incorrectly, attackers may gain access to resources or administrative functions they should never see.

Example:
A user changes the ID in a URL from:

/orders/125

/orders/126

and successfully views another customer's order because authorization checks are missing.

Prevention

Verify authorization on the server side.
Apply the principle of least privilege.
Test access control for every endpoint.

2. Cryptographic Failures

Sensitive information such as passwords, payment details, and personal records must be protected both during storage and transmission.

Example:
A website stores passwords using outdated hashing algorithms or saves them in plain text. If the database is compromised, attackers immediately gain access to user credentials.

Prevention

Use strong password hashing algorithms like Argon2 or bcrypt.
Enforce HTTPS everywhere.
Encrypt sensitive information at rest.

3. Injection

Injection vulnerabilities occur when untrusted user input is interpreted as commands by a database or operating system.

Example

A login form builds this SQL query:

SELECT * FROM users WHERE username='admin' AND password='password';

If user input isn't validated, an attacker may inject SQL commands to bypass authentication.

Prevention

Use parameterized queries.
Validate user input.
Avoid building SQL statements through string concatenation.

4. Insecure Design

Even well-written code can become vulnerable if the application's architecture doesn't consider security from the beginning.

Example

An online banking application allows unlimited password reset attempts without additional verification, making account takeover significantly easier.

Prevention

Perform threat modeling during design.
Define security requirements early.
Build security into the development lifecycle.

5. Security Misconfiguration

Default settings, unnecessary services, and poor server configurations create opportunities for attackers.

Example

A cloud storage bucket is accidentally configured for public access, exposing confidential company files.

Prevention

Remove unused features.
Disable default accounts.
Review configurations regularly.

6. Vulnerable and Outdated Components

Applications often depend on open-source libraries and frameworks. Older versions may contain publicly known vulnerabilities.

Example

A web application continues using a framework version with a publicly disclosed remote code execution vulnerability long after a security update has been released.

Prevention

Maintain an inventory of dependencies.
Update libraries regularly.
Monitor security advisories.

7. Identification and Authentication Failures

Weak authentication allows attackers to compromise user accounts.

Example

An application permits unlimited login attempts without rate limiting, enabling brute-force password attacks.

Prevention

Enable multi-factor authentication.
Implement account lockout policies.
Enforce strong password requirements.

8. Software and Data Integrity Failures

Applications should verify that software updates, packages, and data originate from trusted sources.

Example

A CI/CD pipeline automatically installs packages without validating their integrity, allowing compromised dependencies to enter production.

Prevention

Verify package signatures.
Protect build pipelines.
Review third-party dependencies carefully.

9. Security Logging and Monitoring Failures

Without effective logging, organizations may remain unaware of an attack until significant damage has occurred.

Example

Multiple failed login attempts occur over several days, but no alerts are generated because authentication events aren't monitored.

Prevention

Log security-relevant events.
Monitor logs continuously.
Configure alerts for suspicious behavior.

10. Server-Side Request Forgery (SSRF)

SSRF vulnerabilities allow attackers to trick servers into making requests to internal or external resources.

Example

A file import feature accepts user-provided URLs without validation. An attacker supplies an internal address, enabling access to resources that shouldn't be publicly reachable.

Prevention

Validate all URLs.
Restrict outbound connections.
Implement allowlists for approved destinations.

Final Thoughts

The OWASP Top 10 is more than a list of vulnerabilities—it's a practical guide for building secure applications. By understanding these risks and incorporating security throughout the software development lifecycle, developers can significantly reduce the likelihood of successful attacks.

Security should not be viewed as a final testing phase. Instead, it should be integrated into planning, development, testing, deployment, and ongoing maintenance. Teams that continuously review their applications, update dependencies, validate user input, and perform regular security assessments are better prepared to defend against today's evolving threat landscape.

Kamal vs Kubernetes: An Honest Comparison for Teams Who Don’t Need 1,000 Services

Fri, 24 Jul 2026 10:00:00 +0000

The framing problem

Most “Kamal vs Kubernetes” articles are written by people who just discovered Kamal and are excited about it. They frame it as a simpler alternative that embarrasses Kubernetes. That framing is wrong and it will lead you to the wrong decision.

Kamal is not better than Kubernetes. Kubernetes is not overkill for everyone. They solve different problems at different scales, and picking the wrong one for your context is expensive either way.

This article gives you the honest version: what each tool actually is, where each one breaks, and the specific signals that should push you in one direction or the other.

What Kamal actually is

Kamal (formerly MRSK) is a deployment tool built by 37signals. It deploys Docker containers to servers via SSH, uses kamal-proxy as its default reverse proxy, and handles rolling deploys with zero downtime. That is the entire feature set.

kamal deploy

It connects to your servers over SSH, pulls the new image, starts the new container, waits for it to be healthy, then moves traffic through kamal-proxy and stops the old one. Traefik is still possible, but in Kamal 2 it sits in front of kamal-proxy as an optional accessory rather than being the standard path.

There is no control plane. No etcd. No API server. No scheduler. No concept of desired state reconciliation. Docker or systemd can restart a crashed container if you configure the right restart policy, but Kamal itself does not reschedule workloads to another node or provide cluster-level self-healing.

Kamal is a deployment tool. Kubernetes is an orchestration platform. These are not the same category.

That is the key distinction from tools like Nomad. I covered that angle in Nomad vs Kubernetes, as part of the same “lighter alternatives to Kubernetes” discussion. Nomad is a scheduler/orchestrator. Kamal is a deployment tool that leaves scheduling and node-level recovery mostly outside its scope.

What Kubernetes actually is

Kubernetes is a distributed system that continuously reconciles actual state against desired state. You declare what you want — N replicas of container X, with these resource limits, this health check, this rollout strategy — and the control plane makes it happen and keeps it that way.

When a node fails, your pods are rescheduled. When a container crashes, it is restarted. When you push a new image, the rollout respects your maxUnavailable and maxSurge settings. When traffic spikes, HPA can add replicas.

This machinery is powerful. It is also genuinely complex to operate.

A minimal production-grade Kubernetes cluster involves: a multi-node control plane for HA, a CNI plugin, an ingress controller (or Gateway API), cert-manager for TLS, a CSI driver for storage, a metrics server for HPA, RBAC policies, network policies, pod disruption budgets, and some form of secret management. Getting all of this right takes time and ongoing maintenance.

The question is whether the problems Kubernetes solves are problems you actually have.

The minimum config tells the story

Here is the same tiny web service expressed in both worlds. The exact fields vary by app, registry, ingress setup, and Kubernetes distribution, but the shape is representative.

<table> <thead> <tr> <th>Kamal <code>deploy.yml</code></th> <th>Kubernetes <code>Deployment</code> + <code>Service</code></th> </tr> </thead> <tbody> <tr> <td> <pre><code class=”language-yaml”>service: web image: ghcr.io/acme/web

servers: web: hosts: – 203.0.113.10

proxy: ssl: true host: app.example.com app_port: 3000

registry: username: acme password: – KAMAL_REGISTRY_PASSWORD

env: secret: – DATABASE_URL</code></pre> </td> <td> <pre><code class=”language-yaml”>apiVersion: apps/v1 kind: Deployment metadata: name: web spec: replicas: 2 selector: matchLabels: app: web template: metadata: labels: app: web spec: containers: – name: web image: ghcr.io/acme/web ports: – containerPort: 3000 envFrom: – secretRef: name: web-secrets — apiVersion: v1 kind: Service metadata: name: web spec: selector: app: web ports: – port: 80 targetPort: 3000</code></pre> </td> </tr> </tbody> </table>

The Kubernetes example is still incomplete for internet traffic and TLS: you would normally add an Ingress or HTTPRoute, cert-manager, DNS, and secret provisioning. Kamal’s example is closer to “deploy this app to these servers.” Kubernetes is closer to “declare this workload inside a platform that already exists.”

The 37signals case

37signals (the company behind Basecamp and Hey) moved off cloud Kubernetes to bare-metal servers running Kamal in 2022-2023. Their own Ops team wrote about the “de-cloud and de-k8s” move. The story got a lot of attention.

What the hot takes missed: 37signals is not a startup. They have a dedicated ops team. They own and operate hardware. Their workload is well-understood and stable: a small number of mature applications serving a large, established user base.

Their decision was rational for their context. Kubernetes was costing them in cloud spend and operational complexity for problems their workload does not have. Moving to Kamal on owned hardware made economic and operational sense for them.

It does not follow that Kamal is the right choice for your early-stage startup, your company that runs on AWS because your team does not want to manage hardware, or your platform that needs to scale from 0 to 10x on short notice.

Where Kamal breaks

No cluster-level self-healing. If your container crashes, Docker or systemd can restart it with the right policy, but Kamal has no involvement. If your server fails, Kamal will not reschedule that workload elsewhere; your service is down until you intervene or until you have set up something else to handle it.

No built-in auto-scaling. Kamal has no equivalent of HPA or KEDA. If your traffic spikes, you add servers manually or script something yourself.

No multi-AZ HA by default. You can deploy to multiple servers across regions, but the coordination is yours to manage. There is no concept of spreading replicas across availability zones automatically.

Rolling deploys are basic. Kamal’s zero-downtime deploy is good for single-server or simple multi-server setups. It is not a substitute for Kubernetes rolling update with fine-grained health check integration across a fleet.

Secret management is manual. Kamal reads secrets from .kamal/secrets and has kamal secrets helpers for fetching and extracting values from password managers and cloud secret stores, but there is no Kubernetes-style projected secret lifecycle. Rotation and policy remain yours to manage.

No workload isolation. Everything on the same server shares the same kernel, same resources. Resource limits are Docker-level, not enforced by an orchestration layer with quotas and namespaces.

Where Kubernetes breaks

The complexity tax is real. Running Kubernetes yourself — not a managed service, but actual cluster operation — requires dedicated expertise. A team without a platform engineer will spend significant time debugging networking issues, understanding why pods are Pending, or figuring out why cert-manager is not issuing certificates.

Managed K8s is not free. EKS charges for the cluster control plane, with standard support priced around $0.10/hour per cluster; GKE and AKS have their own pricing rules and credits. In all cases, you still pay for nodes, load balancers, and persistent volumes. For a small application, this cost can exceed what bare-metal hosting would cost.

The YAML surface area scales with complexity. A simple web app on Kubernetes requires a Deployment, a Service, an Ingress (or HTTPRoute), a Certificate, potentially a HorizontalPodAutoscaler, a PodDisruptionBudget, and NetworkPolicies. That is a lot of infrastructure for a CRUD app.

Debugging is harder. Distributed systems are harder to debug than single-server setups. kubectl exec and kubectl logs are good tools but diagnosing why traffic is not reaching your pod — DNS, CNI, network policy, service selector, readiness probe — requires Kubernetes-specific knowledge that takes time to build.

The honest decision framework

Ask yourself these questions in order:

1. Do you have more than one team working on independent services with different scaling needs?

If yes: Kubernetes starts making sense. The isolation and per-service resource management are worth the overhead.

If no: Kamal is probably sufficient.

2. Do you need to survive individual server failures automatically, without manual intervention?

If yes: You need either Kubernetes with proper HA setup, or a managed container platform whose recovery and placement model fits your app. Cloud Run, Fly.io, Render, and Railway all help here, but their HA boundaries differ. Kamal alone does not give you this.

If no: A Docker or systemd restart policy covers the common crash case.

3. Does your traffic profile require automatic scaling?

If yes: Kubernetes with HPA or KEDA, or a managed platform with the scaling behavior you actually need. Cloud Run scales request-driven services to and from zero; Fly.io supports autostart/autostop and machine scaling; Render and Railway support scaling, but with provider-specific limits and billing. Kamal has no answer here without custom tooling.

If no: Fixed capacity is fine. Kamal works.

4. Do you have a platform team, or is “ops” a shared responsibility among product engineers?

If platform team exists: Kubernetes operational overhead is distributed and manageable.

If ops is everyone’s side job: Kamal’s simplicity is a genuine advantage. Less to go wrong, less to learn, faster to debug.

5. Are you on cloud infrastructure you do not own, and cloud costs matter?

If yes: Run the numbers on managed K8s vs a few VPS instances. For small workloads, VPS + Kamal is significantly cheaper.

If no: You have hardware already. Kamal is almost certainly the right choice.

Side-by-side

	Kamal	Managed container platforms	Kubernetes
Examples	Kamal on VPS/bare metal	Cloud Run, Fly.io, Render, Railway	EKS, GKE, AKS, self-managed
Deployment model	SSH + Docker	Platform API / Git deploy / container deploy	API-driven, reconciliation loop
Self-healing	Docker/systemd restart policy only	Platform-managed restart and placement	Pod rescheduling, node failure recovery
Auto-scaling	Manual	Provider-specific; not all scale the same way	HPA, VPA, KEDA
HA	Manual (multiple servers)	Provider-managed, with platform limits	Available with a well-configured multi-node control plane (not free)
TLS	kamal-proxy with automatic HTTPS; Traefik optional	Usually built in	cert-manager + ingress controller
Secret management	`.kamal/secrets` + helper commands	Platform secrets	Secrets API, external-secrets, Vault
Observability	Standard Docker logging	Provider logs/metrics, export varies	Rich ecosystem (Prometheus, OTel, etc.)
Rollout control	Basic rolling deploy	Simple rollouts, provider-specific	Fine-grained (maxUnavailable, canary, etc.)
Learning curve	Low	Low to medium	High
Ops overhead	Low	Low	Medium to high
Right scale	1-20 services, stable load	Small to medium teams that want managed recovery/scaling	10+ services, variable load, or regulated

What the threshold actually looks like

Kamal is the right default if you are:

A team of 2–10 engineers shipping a web application
Running stable, predictable workloads
On a budget where managed K8s costs matter
Without a dedicated platform engineer

Kubernetes is the right choice when:

You have 10+ services with independent deployment cycles
You need multi-zone HA and automatic failover
Traffic is variable enough that auto-scaling saves real money or prevents real incidents
You have a platform team that can absorb the operational complexity
You are in a regulated environment that benefits from K8s’s audit trails and RBAC

There is a middle tier worth mentioning: managed container platforms like Fly.io, Railway, Render, and Google Cloud Run. These give you some of Kubernetes’s operational benefits with closer to Kamal’s operational simplicity, but the details matter: HA, auto-scaling, scale-to-zero, regions, and billing differ by provider. For teams that need more than Kamal but do not want to operate K8s, this tier is often the right answer and gets underrepresented in the debate.

The real lesson from 37signals

The story is not “Kamal beat Kubernetes.” The story is: match your infrastructure to your actual operational profile, not to what is fashionable or what scales to Google’s size.

37signals evaluated what problems they actually had and picked the tool that solved those problems at the lowest operational cost. That is the right framework.

For most teams reading this, Kubernetes is probably the right answer eventually — when your system’s complexity justifies it. The mistake is adopting it before you are there, burning engineering time on infrastructure problems instead of product problems.

Kamal is a good tool for a specific stage and scale. Use it until you outgrow it. When you outgrow it, you will know — because the things Kubernetes solves will be actual problems you have, not hypothetical ones.

What to do next

Before you choose, write down your actual requirements in one page: number of services, expected traffic variance, failure tolerance, who owns ops, whether you own hardware, and what compliance needs are real today. Then run a small proof of concept with the simplest tool that satisfies those requirements. If Kamal plus Docker restart policies covers the failure modes you actually accept, start there. If you need automatic placement, autoscaling, and multi-zone recovery now, compare managed container platforms first, then Kubernetes.

FAQ

Can Kamal and Kubernetes coexist?

Yes. Some teams use Kamal for simple auxiliary services (internal tools, cron jobs, simple APIs) while running their core platform on Kubernetes. The tools are not mutually exclusive.

Is Kamal production-ready?

Yes. 37signals runs Basecamp and Hey on it. It handles zero-downtime deploys, TLS, and multi-server deployments reliably. The limitation is not reliability — it is feature scope.

Two projects, one motivation

Sun, 12 Jul 2026 22:22:00 +0000

Recently, I built two projects, just because I wanted to give people the info they need: news.

Dinkus was the first one. It is a MacOS RSS feed aggregator, and it gives updates—not only for news—but also for other website updates. It is particularly interesting because it appears on the system tray—which I thought was quite unique, until I figured out there were many other instances of this.

Unsatisfied, I came up with The Olden Gazette, a novel news aggregator that pulls from BBC RSS, the NewsData API, and many other sources. It provides weather, breaking news, articles and the date. It is all black-and-white, and it is vintage, which is the point. Less screamy, loud and cramped, more real news.

These two projects taught me how to better use many frameworks, especially Rumps and Flask, and they really improved my coding style: in The Olden Gazette, I began splitting the project into files, which I didn't really do previously. This may seem silly, because no one doesn't split the code, but I learned this. Late.

That's really it... I hope these tools are nice little gems.

Does Web Hosting Affect Website Speed and Google Rankings

Sat, 04 Jul 2026 06:34:41 +0000

You keep working on your SEO. Better content. Better keywords. More backlinks. Still, your website’s ranking feels stuck. It could be that the issue isn’t your SEO strategy. It could be your hosting.

A slow server affects everything from how fast your pages load to how smoothly users interact with your website and how efficiently Google can crawl it. When your site is slow, both visitors and search engines notice it quickly.

That’s why two sites with the same content can have very different rankings. One is quick and dependable. The other is slow and inconsistent.

Content is no longer the only thing in modern SEO. Performance matters too.

SEO Can Bring Visitors. Hosting Decides Whether They Stay.
You can invest heavily in content, backlinks, and technical SEO, but if your website feels slow the moment someone lands on it, maintaining strong rankings becomes much harder.

Google measures that experience. And users notice it even quicker.

In this guide, we’ll study the impact of web hosting on website speed and Google rankings, and how the right infrastructure can actually be a game-changer for SEO.

How Web Hosting Directly Controls Your Website Speed
At the backend level, your hosting setup determines how quickly your website responds when someone tries to access it. Before images, scripts, or content can load, the server must respond.

That first server response is called Time to First Byte (TTFB), and it acts like the starting signal for your entire website experience. If the server responds slowly, everything that follows feels slower, too.

When server response time is slow:

pages begin loading later
Visitors wait longer to interact
Core Web Vitals become unstable
Users leave before the experience feels smooth
Put simply, if your server is slow, your entire website feels slow.

The 3 Core Hosting Factors That Impact Speed

Storage type
NVMe storage is much faster than SSDs or HDDs, resulting in faster data access and lower server latency.
Resource allocation
On shared web hosting, CPU and RAM are divided across multiple sites. This often leads to slowdowns during traffic spikes.
Server location
The farther your server is from your users, the higher the latency. Hosting closer to your audience improves load time.

What Are Core Web Vitals and Why Does Hosting Determine Them
Google uses Core Web Vitals to measure how real users experience your website. And your hosting plays a direct role in all three.

Core Web Vitals Explained
LCP (Largest Contentful Paint)
Measures how fast your main content loads.
If your server is slow, LCP quickly crosses the 2.5-second limit, which hurts rankings.

INP (Interaction to Next Paint)
Measures how quickly your site responds to user actions.
Overloaded or underpowered servers delay clicks, taps, and interactions.

CLS (Cumulative Layout Shift)
Measures visual stability while the page loads.
Unstable server delivery can cause elements to shift, creating a poor user experience.

Why Hosting Matters for Core Web Vitals
Slow server response increases LCP
Limited resources delay interactivity
Inconsistent performance affects layout stability
Sites that consistently pass Core Web Vitals benchmarks tend to rank higher and attract more organic traffic.

In simple terms, users do not care about your server. They care about how fast your site feels. And that experience is heavily shaped by your hosting.

Most Websites Do Not Have an SEO Problem
They have a performance issue.

There are many sites with excellent content, strong backlinks, and proper optimization, but over time, rankings become unstable.

Why?

The website’s server is not capable.
When the host slows down, everything slows down
Pages take longer to load
interactions feel delayed
Core Web Vitals become inconsistent
Users leave faster
Google notices these signals. And visitors notice it even more quickly.
A faster website feels trustworthy and professional. A slow one creates frustration before the content even gets a chance.

This is why sites that rank well in competitive searches today typically have infrastructure designed to be fast and consistent, rather than relying on overloaded, low-cost hosting.

Fast Websites Usually Win More Than Just Rankings
A faster website not only improves SEO.

It also improves:

user trust
engagement
conversion rates
session duration
overall browsing experience
People naturally spend more time on websites that feel smooth and responsive. Search engines track those behaviour signals closely.

How Cheap Shared Hosting Hurts Your Rankings
Shared hosting may look affordable, but it often comes at the cost of performance.

Your website shares server resources with many other websites. If one of those websites suddenly uses too many resources, your website can slow down too.

Even if your traffic is stable, your server response time can spike without warning.

Why This Becomes an SEO Problem
Google evaluates performance over 28 days
Occasional slowdowns can push your Core Web Vitals into the Poor range
Lower performance scores can lead to weaker rankings
On paper, cheap hosting looks like a smart way to save money. In reality, it often becomes the hidden reason behind slow growth, poor rankings, and lost traffic. What you save in cost, you usually pay back in performance.

How to Check If Hosting Is Slowing Down SEO
You don’t need advanced technical skills to spot hosting issues. A few quick checks can reveal whether your server is holding back rankings.

Step 1: Test Speed with Google PageSpeed Insights
Focus on these key metrics:

LCP above 2.5 seconds means slow page loading
TTFB above 600ms means a server performance issue
If both are high, your hosting is likely the bottleneck.

Step 2: Check Core Web Vitals in Google Search Console
Review real user data over time
Pages marked Poor are already underperforming
Consistent issues here can impact rankings
Step 3: Run a Waterfall Test (GTmetrix)
Look at the first request (server response time)
A long initial response indicates a backend delay
If the first bar is slow, hosting is the problem
What It Means
If your TTFB stays consistently high, no amount of frontend optimization will fully fix it.

In most cases, upgrading your hosting delivers the fastest and most noticeable SEO improvement.

Does Upgrading Hosting Actually Improve Rankings
Yes, and the impact is measurable.

When you move from shared hosting to a high-performance setup, improvements happen at the server level first and then reflect in your rankings.

What Improves After Upgrading
Server response time drops
LCP (loading speed) improves
Core Web Vitals move into the Good range
Search engines track these improvements over time, typically across a 28-day data cycle.

Websites that move from Poor to Good performance often see ranking gains, especially in competitive niches where speed becomes a deciding factor.

Will Migration Affect Your Rankings
A properly handled migration does not harm your rankings.

To ensure a smooth transition:

Lower DNS TTL before migration
Avoid downtime during the switch
Resubmit your sitemap after moving
When You’ll See Results
Most websites start seeing measurable improvements within 30 to 45 days, once performance data is updated.

In simple terms, better hosting improves performance, and better performance can lead to better visibility.

What to Look for in Hosting That Supports SEO Performance
Not all hosting environments are built for speed. The right infrastructure directly impacts your rankings.

Key Features That Matter
NVMe storage
Faster data access reduces server delay and improves response time

Modern web servers (LiteSpeed or Nginx)
Handle traffic efficiently and improve caching performance

Server location close to your audience
Reduces latency and improves real-world load speed

Dedicated resources (CPU and RAM)
Prevents slowdowns during traffic spikes

Built-in CDN integration
Delivers content faster from locations closest to your users

Reliable uptime and stable server performance
Helps search engines crawl and index your website more efficiently

Choosing the right hosting setup is often the difference between a site that loads and a site that competes.

This is where most websites hit a ceiling. Not because of content, but because of infrastructure limitations.

Why BigCloudy Is Built for Performance-Focused Websites
Good hosting is not just about keeping a website online anymore. It directly affects how fast your pages load, how stable your site feels during traffic spikes, and how efficiently search engines can crawl your content.

BigCloudy is designed around performance infrastructure rather than simply offering server space. The focus is on delivering consistent speed, stable uptime, and lower server response times that support better user experience and stronger Core Web Vitals performance.

Key performance advantages include:

NVMe storage for faster data access and reduced server delay
Optimized server stack designed for stable performance under load
Multiple data center locations to reduce latency for global audiences
Built-in CDN integration for faster content delivery worldwide
Reliable uptime infrastructure that helps maintain crawlability and SEO stability
The real advantage is consistency.

Because in modern SEO, consistency matters just as much as speed. Websites that remain fast, stable, and responsive over time usually perform better in search than websites with inconsistent performance.

Final Thoughts
Many websites have poor rankings not because their content is bad, but because their infrastructure does not consistently deliver a quick, stable experience.

Modern SEO is not only about keywords and backlinks. The performance of your website is now a direct factor in how your users interact with your content and how your site is evaluated by search engines over time.

A faster hosting environment improves more than speed. It enhances the user experience, stability, crawlability, and reliability of the website.

That’s why choosing the right SEO VPS hosting is no longer just a technical decision. It directly affects your website speed, search visibility, and ability to rank competitively.

How to Hire a Website Developer in 2026: Complete Guide

Tue, 30 Jun 2026 07:45:45 +0000

How to Hire a Website Developer in 2026: A Complete Guide From the Other Side of the Table

Hiring Guide · Updated June 2026 · 12 min read · by Jacob Campbell

I'm Jacob Campbell, and I've been the developer on the other side of this conversation hundreds of times. I've also cleaned up after plenty of bad hires — sites the owner couldn't edit, "custom" builds that were locked themes, projects where the client didn't even own their own domain. So this guide is written from inside the process: where to actually find a reliable developer, the precise questions that separate professionals from order-takers, the contract terms that protect you, the red flags worth walking away from, and what hiring really costs in 2026. The goal is simple — to help you hire once and hire well, whether that's a freelancer, an agency, or a specialist like me.

Quick answers

24 hrs

Quote turnaround

~30 days

Typical build time

100%

Code ownership

5.0★

Verified client rating

Where to actually find a reliable developer

You can hire through specialist studios, vetted freelance marketplaces (Upwork, Toptal), referrals, or by contacting a web design agency directly. In my experience the most reliable outcomes come from direct hires and specialists, because you work with the person who actually writes your code — not a sales rep who hands the work to an offshore ticket queue you never see. Wherever you look, screen for three things before anything else: verified reviews, a real portfolio you can load and inspect, and clear flat-fee pricing. A portfolio you can run through PageSpeed Insights yourself tells you more than any sales pitch.

The questions that separate pros from order-takers

Ask every candidate, and get the answers in writing: Do I own the code, content, and domain outright? What Lighthouse performance score do you guarantee? Is this a flat fee, or are there monthly costs? Who handles SEO, JSON-LD schema, and Core Web Vitals? What is the timeline, and how do revisions work? What happens if I want to move hosts later? A professional answers all of these without hesitation. An order-taker gets vague exactly where the money and the risk live — ownership and recurring fees.

Contract terms that protect you

Three clauses matter more than the rest. First, an explicit IP-transfer / code-ownership clause stating the finished code and assets are yours on final payment. Second, account ownership — your domain, hosting, and analytics should be registered in your name, not the developer's. Third, a defined scope and revision count so "one more change" doesn't become an open-ended bill. I put all three in plain language in every engagement, because the disputes I've seen others have almost always trace back to one of them being left unwritten.

Red flags worth walking away from

Be cautious of anyone who: locks you into a proprietary platform you can't export, charges vague "ongoing" fees with no itemisation, can't show real performance scores on their own live work, has no verifiable reviews, or only communicates through a call centre. One more I've learned to flag: a developer who won't let you keep your own domain and hosting logins. That's not a convenience — it's leverage over you, and a reputable developer never needs it.

What it actually costs to hire in 2026

Hiring for a professional business website typically runs $1,500–$10,000 as a one-time project, consistent with Clutch survey data putting the median small-business spend near $5,000; hourly rates vary widely by region and seniority. A flat-fee specialist removes the estimating risk entirely: I build a business website for $1,750, ecommerce for $5,600, and SaaS from $10,000 — no monthly fees, full code ownership. (See my full cost breakdown for what drives the number.)

Freelancer vs agency vs specialist

A freelancer can be affordable, but availability and continuity vary. A large agency offers scale and redundancy, usually at higher cost and with less direct contact with the person doing the work. A focused specialist gives you expert, hands-on delivery with a single accountable point of contact — typically the best balance of quality, speed, and value for a small or growing business. There's no universally "right" answer; the right one depends on your budget, timeline, and how much direct access to the builder you want.

Sources & further reading

Pricing, turnaround, and ownership terms reflect my own current BuiltToWinWeb engagement standards as of June 2026.

Work with an expert

Frequently asked questions

How do I hire a good website developer?

Screen for verified reviews, a real portfolio you can load and test, flat-fee pricing, and a guaranteed Lighthouse score. Confirm in writing that you own the code, content, and domain, ask who handles SEO and Core Web Vitals, and choose someone who communicates directly.

How much does it cost to hire a website developer?

A professional website typically costs $1,500–$10,000 as a one-time project in 2026, with the median small-business spend near $5,000 per Clutch. BuiltToWinWeb offers flat fees of $1,750 for business sites, $5,600 for ecommerce, and from $10,000 for SaaS, with no monthly costs.

Should I hire a freelancer or an agency?

A freelancer can be affordable but availability varies; an agency offers scale at higher cost and less direct contact. A specialist gives you expert, hands-on work with one accountable contact, which is often the best value for small businesses.

What questions should I ask a web developer before hiring?

Ask whether you own the code, content, and domain, what Lighthouse score is guaranteed, whether pricing is a flat fee, who handles SEO and Core Web Vitals, what the timeline and revision process are, and what happens if you change hosts.

What are red flags when hiring a developer?

Watch for platform lock-in you can't export, vague ongoing fees, no verifiable reviews, no guaranteed performance scores, call-centre-only communication, and any refusal to let you keep your own domain and hosting logins.

What contract terms protect me when hiring a developer?

Insist on an explicit code/IP-ownership clause that transfers the finished work to you on final payment, account ownership of your domain and hosting in your name, and a defined scope with a set revision count so changes don't become open-ended.

Hire a developer who guarantees results

Work directly with an expert developer — flat-fee pricing, a 100 Lighthouse guarantee, and full code ownership.

Get my free quote

iTop VPN Premium Review (2026): My Honest Experience as a Developer & Daily User

Tue, 05 May 2026 17:45:34 +0000

iTop VPN Premium is a beginner-friendly VPN service designed for secure browsing, streaming access, and privacy protection. It offers fast servers, dedicated streaming optimization, and a simple interface, making it a solid option for users who want affordable VPN protection without technical complexity.

Why You Can Trust This Review

I’ve personally used iTop VPN Premium both as:

A developer handling websites and online tools
A daily internet user focused on privacy and secure browsing

I tested it for:

Secure public Wi-Fi usage
Accessing geo-restricted content
Website testing across regions
Private browsing while managing blogs and client work

This review is based on:

My real hands-on usage
Official iTop VPN features
Honest pros and limitations

What is iTop VPN Premium?

iTop VPN Premium is a virtual private network (VPN) service that helps protect your online privacy by encrypting your internet connection.

It allows you to:

Hide your IP address
Access region-restricted content
Secure browsing on public networks
Improve privacy while working remotely

Unlike many free VPNs, Premium gives better:

Speed
Server access
Stability
Streaming performance

My Personal Experience Using iTop VPN Premium

I mainly used iTop VPN for:

Secure access while traveling
Testing websites from different locations
Watching geo-restricted content
Protecting login sessions on public networks

What Worked Really Well

Fast Connection Speeds

The connection was stable for:

Browsing
YouTube streaming
Uploading content
WordPress dashboard access

Easy to Use Interface

Even for beginners, setup was simple:

One-click connect
Clear server categories
Dedicated streaming options
Reliable for Basic Privacy

For daily browsing and normal work, it handled:

Public Wi-Fi security
IP masking
Private sessions smoothly

Should You Buy iTop VPN Premium? (Smart CTA)

If you want an affordable VPN for:

Secure browsing
Streaming
Website testing
Remote work privacy

Check iTop VPN Premium here

Tip: Premium plans unlock much better speed than the free version.

Key Features of iTop VPN Premium

Dedicated Streaming Servers

Helpful for accessing:

Netflix
YouTube
Region-based platforms

Military-Grade Encryption

Improves:

Data protection
Secure browsing
Public Wi-Fi safety

Large Server Network

Access multiple locations for:

Testing
Privacy
International browsing

Kill Switch Support

Protects your privacy if VPN disconnects unexpectedly.

Pricing Overview

Premium pricing usually depends on:

Monthly plans
Annual subscriptions
Discount offers

Longer plans often provide the best value.

Check latest Premium pricing here.

Pros and Cons

✅ Pros

Beginner-friendly UI
Good speed for daily use
Dedicated streaming support
Affordable compared to many competitors
Strong enough for regular privacy needs

❌ Cons

Advanced users may want more customization
Some servers can be slower during peak hours
Free version is limited compared to Premium

Performance & Real Use Case

From my experience:

Browsing felt smooth
Streaming worked reliably
WordPress management stayed stable
Region testing for websites was helpful

Speed Connecting to VPN:

This makes it useful for:

Bloggers
Freelancers
Remote workers
General users needing privacy

Speed after Connecting VPN:

Who Should Use iTop VPN Premium?

Best for:

Beginner VPN users
Bloggers & freelancers
Streamers
Travelers
People using public Wi-Fi often

Not ideal for:

Heavy enterprise-level security users
Advanced networking professionals needing deep controls

How It Compares to Other VPNs

Compared to bigger names like:

NordVPN
ExpressVPN
Surfshark

iTop VPN is more:

Budget-friendly
Beginner-focused

While premium competitors may offer:

Stronger advanced security tools
Larger premium infrastructure

FAQs

Is iTop VPN Premium worth it?

Yes, especially for users who want simple, affordable privacy protection without complicated setup.

Is iTop VPN good for streaming?

Yes, Premium includes optimized servers for smoother streaming access.

Is the free version enough?

For basic testing, yes. But for real speed and stability, Premium is much better.

Is iTop VPN safe?

For general privacy use, yes. It offers encrypted browsing and kill switch protection.

Final Verdict

iTop VPN Premium is a strong option for users who want easy, affordable VPN protection without technical complexity.

It works especially well for:

Bloggers
Travelers
Freelancers
Daily privacy-conscious users

If your goal is:

Privacy
Secure browsing
Streaming access

…it’s definitely worth considering.

If you want a simple VPN that works well without overpaying:

Check iTop VPN Premium plans here.

I'm a designer, not a developer. Here's how I prepared my PHP blog for AI agents.

Mon, 20 Apr 2026 21:09:36 +0000

I need to be upfront about something: I'm not a developer. I'm a UX/UI designer with over 10 years in banking and fintech. I built my blog with PHP and Claude as my coding partner. Every technical decision was a conversation with an AI, not a Stack Overflow deep dive.

So when Cloudflare released a tool that tests how ready your site is for AI agents, I was curious but skeptical. How hard could this be for someone who learned PHP three months ago?

Turns out, not hard at all. My blog scored 50/100, and it took less than an hour.

What AI agents actually need from your site

Forget the technical jargon for a second. AI agents are like new visitors who can't see your design. They don't care about your beautiful layout or your carefully chosen typography. They want your content, clean and structured.

Most websites give them a mess. Navigation bars, cookie banners, JavaScript bundles, social media widgets. The agent has to dig through all that noise to find the actual article. It's like handing someone a book wrapped in newspaper.

The four things I implemented basically unwrap the newspaper:

A file that says "here's who I am" llms.txt. A simple Markdown file at my domain root. It tells AI models: I'm a designer writing about AI tools, here are my best articles, here are my free tools. Five minutes to write. I even built a free generator so you don't have to write it from scratch.
One line in robots.txt It tells AI crawlers: cite me, but don't train on my content. Thirty seconds to add.
A clean version for agents When an AI agent asks for my page, my server sends back plain Markdown instead of HTML. No navigation, no scripts, just the article. Twenty minutes to set up with Claude's help.
A list of my tools A JSON file that tells agents what they can do on my site. Five minutes.

Why I skipped the other 6 standards

The test checks 10 things. Six of them are for platforms like Stripe or Salesforce things with APIs, user accounts, and authentication flows. My blog has none of that. Implementing OAuth on a blog with no login would be absurd.

What I learned

The most interesting part wasn't the implementation. It was the realization that preparing your site for AI agents is similar to good UX design. You're making content accessible to a different type of user one that processes information differently than humans.

As a designer, that clicked immediately. We don't design the same interface for mobile and desktop. Why would we serve the same messy HTML to a human browser and an AI agent?

For anyone in the community with a personal blog or portfolio: have you thought about how AI agents see your site? I'm curious if others have tried the test and what they found.

One Button Too Many

Wed, 25 Mar 2026 10:32:44 +0000

We had five OAuth login options on our sign in page.

Google. GitHub. LinkedIn. X. Facebook.

It looked complete. It felt right. More options, more flexibility.

Then one night around 11pm, we were staring at logs trying to figure out why our X integration kept connecting the wrong account.

That is when things got interesting.

What We Build

We are building Made4Founders, a business platform for startup founders.

One of the features is social posting. You connect your X account, write a post in the dashboard, and it publishes for you.

Simple idea. Should be straightforward.

We also let users sign in with X.

At the time, it felt obvious. If we support X, we should support logging in with it too.

What Went Wrong

Here is the problem.

A user signs in using their personal X account. That is the account already active in their browser.

Later, they go to connect their company account for posting.

But X does not give you an account picker. It does not ask which account you want. It just grabs whatever session is active.

So it silently reconnects the personal account.

The user thinks they connected their business account. They write a company update, hit post, and it goes to their personal feed.

Not ideal.

The “Fixes” That Did Not Work

We tried to patch it.

We added a hint telling users to switch accounts on X first.

It did not help.

Even after switching inside X, OAuth still defaulted to the primary session.

The only workaround was telling users to:

Open an incognito window
Log into their business account only
Come back and connect

We actually wrote that into a tooltip.

Then we looked at it and realized how ridiculous that was.

The Question We Should Have Asked Earlier

We stopped debugging and checked our data.

How many users had actually signed up using “Sign in with X”?

Zero.

Not low. Zero.

Every user used Google or email. A few used GitHub or LinkedIn.

Nobody used X.

So we had been maintaining:

OAuth flows
Token refresh logic
API credentials
Debugging time

For a feature nobody used.

The Fix Took 10 Minutes

We deleted the button.

Removed the frontend component. Cleaned up the API call.

About 20 to 30 lines of code.

Then we separated our X apps:

One app for login (now disabled)
One app for posting

Same pattern we already used for LinkedIn.

Immediately, everything worked.

Four login options. No conflicts. Posting works as expected.

What We Actually Learned

This was not really about X.

It was about a common engineering habit.

Adding things because we can, not because they are needed.

Each OAuth provider feels cheap to add.

Just another button. Another callback. Another env variable.

But they are not free.

Each one adds:

Token flows that can break
Credentials that expire
APIs that change
Edge cases you do not control

And sometimes, they conflict with other features.

The Real Cost of “Just One More Option”

We spent hours debugging X.

Token issues
Session conflicts
API limitations
OAuth redirect loops

X has also become harder to work with:

Pay per use pricing
Limited free tier
Hidden requirements in the developer console

All of that for a login button nobody clicked.

The Broader Point

Every feature has a maintenance cost.

Not just code.

Debugging time
Support tickets
Mental overhead
Edge cases

OAuth is especially messy.

Every provider behaves differently:

Google gives an account picker
LinkedIn requires separate apps
Facebook has business requirements
X uses whatever session is active

There is no standard. Only variations.

Our Rule Now

Before adding a login option, we ask one question:

Would our target user actually sign up this way?

For founders using a business tool:

Google and email cover almost everything
GitHub works for technical users
LinkedIn makes sense

X and Facebook do not.

If the answer is no, we do not add it.

If You Are Building Something Similar

A few things we learned the hard way.

Session conflicts are real and you cannot control them.

2. Separate your developer apps

Authentication and integrations should not share the same setup.

3. Test with multiple accounts

Most bugs only appear in real world usage patterns.

4. Remove what is not earning its place

It feels wrong, but it is often the right move.

The Result

Four login buttons.

No conflicts.

No late night debugging sessions over something nobody uses.

Sometimes the best feature you can ship is a deletion.

Closing

We are building Made4Founders.

One dashboard to replace a stack of disconnected tools for startup founders.

If you are building in this space, you already know how messy it gets.

We are trying to make it simpler.

A Complete Guide to Angular Component Testing with Cypress

Tue, 24 Mar 2026 01:37:36 +0000

Angular's latest versions have introduced exciting features like signals, computed, and enhanced reactivity. Paired with Cypress Component Testing, developers now have a powerful toolkit to write fast, realistic, and robust tests. This post dives deep into Angular component testing using Cypress, including how to test components that use signals, observables, and mock services with confidence.

✨ Why Cypress for Angular Component Testing?

Cypress isn't just for end-to-end tests. With Cypress Component Testing, you can:

Render Angular components in isolation
Interact with them as a user would
Spy on inputs/outputs
Work seamlessly with Angular DI, modules, and modern features like signals

Setting Up Cypress Component Testing
Install Cypress and initialize component testing:

npm install cypress @cypress/angular --save-dev
npx cypress open --component

Follow the UI wizard to configure your Angular workspace. It will auto-generate a Cypress configuration compatible with Angular.

️ Example Component with Signals & Outputs

Let's test a simple CounterComponent that demonstrates:

Input binding
Output emission
Signals and computed values

// counter.component.ts
import { Component, Input, Output, EventEmitter, signal, computed } from '@angular/core';

@Component({
  selector: 'app-counter',
  template: `
    <div>
      <h2>{{ title }}</h2>
      <p>Count: {{ count() }}</p>
      <button (click)="increment()">Increment</button>
      <button (click)="reset()">Reset</button>
      <p>Double: {{ doubleCount() }}</p>
    </div>
  `
})
export class CounterComponent {
  @Input() title = 'Default Counter';
  @Output() onReset = new EventEmitter<void>();

  private _count = signal(0);
  count = this._count.asReadonly();
  doubleCount = computed(() => this._count() * 2);

  increment() {
    this._count.set(this._count() + 1);
  }

  reset() {
    this._count.set(0);
    this.onReset.emit();
  }
}

Basic Cypress Tests

✅ Rendering with Default and Custom Inputs

// counter.component.cy.ts
import { mount } from 'cypress/angular';
import { CounterComponent } from './counter.component';

describe('CounterComponent', () => {
  it('renders with default title', () => {
    mount(CounterComponent);
    cy.contains('Default Counter');
    cy.contains('Count: 0');
  });

  it('accepts custom title', () => {
    mount(CounterComponent, {
      componentProperties: { title: 'Custom Counter' }
    });
    cy.contains('Custom Counter');
  });
});

⚖️ Testing Signals and Computed Values

it('increments count and updates double', () => {
  mount(CounterComponent);
  cy.get('button').contains('Increment').click().click();
  cy.contains('Count: 2');
  cy.contains('Double: 4');
});

Spying on Output Events

it('emits reset event', () => {
  const resetSpy = cy.spy().as('resetSpy');

  mount(CounterComponent, {
    componentProperties: {
      onReset: { emit: resetSpy } as any
    }
  });

  cy.get('button').contains('Reset').click();
  cy.get('@resetSpy').should('have.been.calledOnce');
});

Testing with Observables

// message.component.ts
@Component({
  selector: 'app-message',
  template: `<p *ngIf="message">{{ message }}</p>`
})
export class MessageComponent {
  private _message = signal('');
  message = this._message.asReadonly();

  @Input()
  set messageInput$(value: Observable<string>) {
    value.subscribe(msg => this._message.set(msg));
  }
}
it('renders observable message', () => {
  const message$ = of('Hello from Observable!');
  mount(MessageComponent, {
    componentProperties: { messageInput$: message$ }
  });
  cy.contains('Hello from Observable!');
});

Advanced Mocking Techniques

⚙️ Injecting Angular Services

class MockLoggerService {
  log = cy.stub().as('logStub');
}

mount(MyComponent, {
  providers: [
    { provide: LoggerService, useClass: MockLoggerService }
  ]
});

Mocking HTTP Calls with HttpClientTestingModule

import { HttpClientTestingModule, HttpTestingController } from '@angular/common/http/testing';

beforeEach(() => {
  cy.intercept('GET', '/api/data', { fixture: 'data.json' });
});

mount(MyHttpComponent, {
  imports: [HttpClientTestingModule]
});

Stubbing Child Components

@Component({
  selector: 'app-child',
  template: '' // stubbed template
})
class StubChildComponent {}

mount(ParentComponent, {
  declarations: [StubChildComponent]
});

Conclusion

Cypress Component Testing is a game-changer for Angular developers. By combining the real browser testing experience with Angular’s new reactivity features like signals and computed, we can create robust, testable, and modern UIs.

Key Takeaways:

Mount Angular components with Cypress easily
Test signals, computed, observables
Use spies and stubs for robust unit isolation
Mock services and HTTP with Angular-friendly tooling

DataVyn Labs × Ollama Agents multi-model AI chat workspace

Fri, 20 Mar 2026 04:31:59 +0000

We built a clean, minimal AI chat interface powered by Ollama Cloud Models, designed as a fast workspace for trying multiple frontier LLMs in one place.

You only need a single Ollama Cloud API key to chat with 19+ top models—no separate OpenAI/Gemini keys, no billing setup, or no credit card needed.

This project is developed by DataVyn Labs (https://github.com/DataVyn-labs)

What it does

Talk to 19+ Ollama cloud models (OpenAI, DeepSeek, Qwen, Gemini, Mistral, Kimi, GLM, MiniMax, and more) from a single UI.
Upload .txt, .pdf, .json, .py, .csv and send the content to the model.
Voice input via mic with automatic transcription.
Secure API key handling (session-only, never saved to disk).
Dark, Claude-style interface built entirely with Streamlit.

deployed app

App: https://datavyn-labs-x-ollama-agents.streamlit.app/
github repo - anshk1234/DataVyn-Labs-X-Ollama-agents

You just need an Ollama Cloud API key (Settings → API Keys on ollama.com) and you’re ready to go.

The True Face of Referential Equality and Optimizations in React

Fri, 06 Mar 2026 20:36:54 +0000

When performance issues arise in React applications, React.memo, useMemo, and useCallback are usually the first things that come to mind. In practice, however, adding these tools often merely complicates the code without delivering the expected performance boost.

The underlying reason isn't that React is inadequate, but rather a fundamental misunderstanding of referential equality within React's render model and how these optimization tools actually work.

React's Decision Mechanism: Value vs. Reference

When deciding whether to re-render a component, React doesn't check the contents of the data (structural equality). Instead, it checks if the data points to the same location in memory (referential equality). It uses a shallow comparison similar to JavaScript's Object.is() method.

const a = { value: 1 };
const b = { value: 1 };

console.log(a === b); // false

In the example above, even though objects a and b have identical content, they point to different memory locations. Therefore, React considers them completely different values. This becomes critical especially when objects, arrays, and functions are passed as props to child components.

The Shallow Comparison Preference

React.memo, PureComponent, and Hook dependency arrays intentionally perform a shallow comparison. If React were to deeply compare every property within objects during every render, the performance cost would be significantly higher.

const Child = React.memo(({ options }) => {
  /* ... */
});

const Parent = () => {
  // A new 'options' object is created in memory during every render.
  const options = { pageSize: 20 };

  return <Child options={options} />;
};

In this example, every time the Parent component renders, a new options object is created in memory. Even though the Child component is wrapped in React.memo, the optimization cannot kick in because the reference of the options prop has changed, causing the Child to re-render unnecessarily.

Impact on the Reconciliation Process

In React, rendering does not mean directly updating the DOM. During the render phase, React generates a new component tree (Fiber tree) and compares it with the previous one (Reconciliation).

If a component's state or prop references have changed, React re-renders that component and its entire subtree. Even if there are no actual changes to the DOM, constantly changing references force React to perform this comparison repeatedly, wasting CPU cycles.

Why useMemo and useCallback Fall Short

These two Hooks are designed to keep references stable (memoization), but when implemented incorrectly, they only add overhead to the application.

The Limits of useMemo: useMemo is used to cache expensive calculations or keep references stable. However, if a value in the dependency array changes its reference on every render, the calculation inside useMemo will re-run every time. In this case, not only does the optimization fail, but React is also burdened with the extra work of tracking these dependencies.
The Role of useCallback: useCallback caches function definitions. But if a function depends on a frequently updated state (e.g., state changing on every keystroke in a text input), this function will be recreated with every keystroke. Passing this function as a prop to child components will cause them to continuously re-render as well.

Every Render Creates Its Own Scope (Closures)

In React, every render creates its own lexical scope. This means that during each render, a "snapshot" of the current state and prop values is taken.

Functions within a component capture the values belonging to that specific render. When the state updates, the component re-renders, a new snapshot is taken, and naturally, brand-new functions working with these new values are created in memory. This is React's expected behavior.

Architectural Solutions Over Forced Optimization

Instead of trying to forcefully stabilize references using useMemo and useCallback, rethinking the component architecture is often a more permanent and cleaner solution.

Moving State Down: If a piece of state only affects a specific child component, move that state directly into the child rather than keeping it in the parent. This prevents the parent from rendering unnecessarily.
Lifting Content Up (Children Prop): By passing expensive components to a parent via the children prop, you can ensure that the child components are unaffected when the parent's state changes.
Using Primitive Values: Instead of passing an entire object to child components as a prop, pass only the necessary primitive values like string, number, or boolean. Primitives are always compared by value, not by reference.

React.memo, useMemo, and useCallback are not magic wands. These tools only provide benefits in applications where the architecture and data flow are properly structured. If you are experiencing performance issues, rather than immediately reaching for these Hooks, it is much better to ask architectural questions like, "Where should this component's state live?" or "Do I really need to pass this prop?"

Innovative Projects for Python Developers

Sat, 21 Feb 2026 10:58:20 +0000

As a Python developer, staying relevant and improving your skills is vital. Here are some innovative project ideas that cater to various experience levels and can help you tackle real-world challenges.

Personal Finance Tracker
Develop an application that allows users to track expenses, income, and savings goals. Integrating data visualization libraries such as Matplotlib or Plotly can make representation of financial data intuitive and engaging. Consider adding features like budgeting alerts or trend analysis to enrich user experience.
Chatbot with NLP
Create a chatbot that utilizes Natural Language Processing (NLP) to provide customer support or assist with common queries. Use libraries like NLTK or SpaCy to parse and understand user input. You can enhance it by integrating it with messaging platforms like Slack or Telegram.
Web Scraping Tool
Build a tool that extracts timely information from websites like news sources or e-commerce platforms. This project can sharpen your skills in data retrieval and manipulation using libraries like BeautifulSoup and Requests. Make sure to respect website scraping policies (robots.txt) while developing.
Machine Learning for Image Classification
Leverage frameworks like TensorFlow or PyTorch to build a model that classifies images. This could range from identifying dog breeds in photos to distinguishing between various plant species. Experiment with different algorithms and datasets to deepen your understanding.
Recipe Recommendation System
Create an application that provides users with meal suggestions based on available ingredients. Use Python's data handling capabilities alongside web APIs like Spoonacular for fetching recipes, allowing your app to be both functional and user-friendly.
Serverless Web Application
Explore serverless architecture by building a web application using AWS Lambda and API Gateway. This project will help you grasp the concepts of cloud computing and scalability without the hassle of managing servers directly.
Blog Platform with Markdown Support
Develop a full-stack blog platform that uses Python Flask or Django for backend and a JavaScript framework for the frontend. Incorporating Markdown for blog posts enables users to format their articles easily, which could enhance the overall publishing experience.

Each project not only strengthens your coding skills but also adds impressive projects to your portfolio. Mix and match these ideas or combine aspects from different ones to create a unique implementation tailored to your interests. Remember to keep testing and iterating as feedback can lead to enhancements that may not have been initially considered.

A Dive Into Programmimg Paradigms(Object-Oriented Programming)

Tue, 27 Jan 2026 14:18:40 +0000

INTRODUCTION

Now Adays, we have different sorts of people some are orderly, others are lackadaisical, a handful are hardworking, and a few are reserved.

What am i trying to say?, because we have so many people with different characters, these people will also have their different approaches to evaluating things. Take for example!.

• Orderly People - always plan their things out
• Lackadaisical People - are laid back
• Hardwojung People - always persevere
• Reserved People - are always withdrawn.

Notice the trend, the same way attitudes vary among people, also applies to the logic behind the variety of programming techniques out there.

What is a programming paradigm? - A programming paradigm is a fundamental style of programming that deals with the creation of software, based on some basic principles.
These principles all have their different ways or styles of operation.

They include
● OOP(Object oriented Programming) - a paradigm where everything operates based on objects (related entities) and their classes(group)

● Event Driven Programming - a paradigm where the users interaction with an applications events are all that matters, e.g first event tapped - first to be called.

● Imperative Programming - a programming paradigm based on a commanding style - this follows an exact way a program is written without any modifications.

There are still many more paradigms including
● Functional Programming
● Aspect Oriented Programming e.t.c.
and so on, but today we'd be majoring on OOP.

OOP(Object oriented Programmimg) -

Just like i said earlier like many other paradigms, OOP also has it's style of software creation. It's is one of the most widely used programming paradigms, being supported by many modern programming languages including - Python, Javascript, Java and Golang(Go).

When we say a program was written with the OOP style - it literally means the entirety of the program was broken down into simpler units of relation called classes and objects, and literally everything is an object e.g can be assigned to a variable.

Classes - these are a collection of related fields of a particular entity that help group relations together.

Objects - these are units or rather blueprints of classes, they help break down the different possible types of a class.

E.g A Car class will have many attributes(fields) including Name, Brand, Production Year, Price, Color and so on. And the objects of the car class, will help break down the different possible car types e.g

Car1 - Name(Sports Car), Brand(Lamborghini), Production Year(2012), Price($400,000), Color(Red).

CODE IMPLEMENTATION

Let's say you are a car dealer, and you need to develop an application that displays the different qualities of your car to buyers, when the buyer clicks on the car - it displays the qualities, OOP will be a great fit for this job.

In the Example below we'd be using the Python programming language to implement this task, as its syntax is subtle.

Car Dealership

These are the parts, the car dealership deals with, Car - (Brand, Color, Publication, Price)

So we have 4 cars currently at the dealership.
To implement, we go as follows.

1 Class Cars:

   def __init__(self, brand, color, publication, price):
       self.brand = brand 
       self.color = Color
       self.publication = publication
       self.price = price 

    def onclick_show_details(self):
       print("The car you clicked is a {}, it is color {}. It was produced in{}, and its price is {}").format(self.brand, self.color, self.publication, self.price)

This instantiates the class to create objects

car1 = Cars("Lamborghini", "red", "2012", 300000)
car2 = Cars("Toyota", "blue", "2008", 250000)
car3 = Cars("Honda", "white", "2017", "150000)
car4 = Cars("Nissan", "green", "2013", "100000)

This performs actions on the objects by invoking object methods

Car1_details = car1.onclick_show_details()
print(Car1_details)

The car you clicked is a Lamborghini, it is color red, it was produced in 2012 and its price is 300000.

CONCLUSION - There are still many more concepts on OOP including characteristics of OOP e.g, Abstraction, Polymorphism, Encapsulation and Inheritance, but we'd talk about that in another article.

OOP is a really used programming paradigm now adays, so it will be great to learn and grasp it's concept.

Why Building Projects Beats Just Watching Tutorials

Sun, 14 Dec 2025 16:37:38 +0000

When I started learning AI and Machine Learning, I thought watching tutorials was enough. Models, algorithms, code examples — everything looked clear while watching. But the moment I tried to build something on my own, reality hit.

❌ The Tutorial Comfort Zone

Tutorials made everything feel easy:

Clean datasets

Pre-written logic

Perfect outputs

But once the video ended, I realized I didn’t truly understand how things worked.

What Changed: Building Real Projects

Things changed when I started building my own AI & ML projects — even small ones.

I faced:

Dataset issues

Model giving wrong predictions

Errors I had never seen before

Performance problems

At first, it was frustrating. But slowly, I learned:

How to debug ML code

Why preprocessing matters

How model choice affects results

How AI systems behave in real-world scenarios

That struggle taught me more than any tutorial ever could.

Learning by Doing (My Approach)

This is the method that worked best for me:

Learn the basic concept

Build a simple AI/ML project

Break it by experimenting

Improve accuracy or features

Repeat with a new idea

Each project improved my confidence and understanding.

Final Thought

AI and ML are not learned by just watching — they are learned by building, failing, and fixing.

If you’re learning AI or ML, don’t wait to be perfect.
Start small, build projects, and let mistakes teach you.

Build → Fail → Learn → Improve

Happy Coding

API UP — an API as a Service

Wed, 03 Dec 2025 20:31:57 +0000

Hey everyone!
API UP has just been launched, a SaaS platform that lets you create fully functional APIs
without setting up servers, databases, Docker, Kubernetes, etc.

It’s not a no-code toy — it generates a real async Python backend (compiled to C), with:
• new Python 3.14+ web framework compiled in C
• automatic CRUD/search
• built-in authorization (endpoint/collection/document/field level)
• embedded background tasks
• multi-tenant and multi-version deployment
• multi-database
• built-in test tools
• an admin UI for operations/product teams
• CLI tools
• mobile/web SDKs
• high-performance defaults (async, optimized queries)
• AI integration: describe the API and a version of it start running in minutes

You can create an API, deploy it, and start calling it from your frontend or mobile app in minutes.

You can test the UI and play with the system here:
https://apiup.ai

Documentation:
https://docs.apiup.ai

Would love feedback — especially from backend and SaaS folks.

Ai Tool Synth Website Project

Tue, 02 Dec 2025 13:46:21 +0000

Discover AI Tool Synth — Your Gateway to the Best AI Tools

Hey everyone!
I’d like to introduce AI Tool Synth, a platform I’ve built to help creators, developers, and businesses easily discover and compare the latest AI tools.

We offer:

✅ Curated AI tool lists across categories like productivity, image generation, audio, coding, marketing, and more
✅ Clear descriptions, pricing info, and direct access links
✅ Daily updates — new tools are added regularly
✅ Affiliate-supported recommendations (no extra cost to users)
✅ A clean, simple, and fast browsing experience

If you're looking for new AI tools to speed up your workflow, generate content, or boost your business, this platform will save you a ton of time.

Check it out here: https://www.aitoolsynth.com

Would love to hear your feedback!

A Scalable and Type-Safe i18n Solution for Modern Web Applications

Mon, 08 Sep 2025 19:46:29 +0000

Building a robust internationalization (i18n) system is challenging. Many developers start with a simple, monolithic translation file, but this quickly leads to performance issues and maintenance nightmares as the project grows. A better approach is to combine the efficiency of lazy-loading with a well-structured custom function to create a solution that is both performant and easy to manage, regardless of the framework you're using.

This article outlines a hybrid i18n strategy that handles dynamic translation loading, ensuring your application remains fast, organized, and type-safe.

Methodologies for Internationalization

The choice of internationalization (i18n) method depends on your project's size and complexity. Here are three common approaches, along with a detailed explanation of their trade-offs.

1. The Monolithic Method (Small Projects)

This is the simplest approach. All translations for all languages are stored in a single, large JSON file.

How it works: You import a single file at the start of your app. The file is structured with language keys at the top level.
Pros: Easy to set up and great for small projects or single-language apps. All translations are immediately available.
Cons: Not scalable. The file becomes too large, increasing initial load time and making it difficult for multiple developers to work on translations simultaneously without frequent merge conflicts.

2. The Language-Based Method (Medium Projects)

This method separates translations by language, so you have one file per language.

How it works: Your application loads a single language file based on the user's locale. This is often done at the router level or in a central store.
Pros: Reduces the initial bundle size compared to the monolithic method, as the user only downloads one language. Better for version control and collaboration.
Cons: Still inefficient for very large applications. Every user downloads the entire language file, even if they only visit a few pages.

3. The Hybrid Method (Large Projects)

This is the pattern we'll focus on. It combines the benefits of the other two methods by using a custom function (known as a composable in Vue.js or a custom hook in React).

Why the Hybrid Method Is Superior

The hybrid method solves the core problems of the monolithic and language-based approaches by addressing performance and maintainability.

Performance: The Problem of Initial Load

In a large application with hundreds of pages and components, a monolithic or language-based translation file can grow to several megabytes. When a user first visits your website, they have to download this entire file before they can see any text. This is a massive waste of bandwidth and time, especially on mobile networks, and it directly impacts your Core Web Vitals scores.

The hybrid method avoids this by only loading the translations required for the current page. The common translations, which are essential everywhere, are a small fraction of the total. The rest are dynamically imported only when needed, significantly reducing the initial bundle size and improving perceived load time.

Maintainability: The Problem of Monoliths

Imagine a team of ten developers working on a large application. If every developer needs to add new translations to a single en.json file, they will constantly run into merge conflicts. These conflicts are a huge drain on productivity and can introduce bugs when translation keys are accidentally overwritten.

By organizing translations by feature (e.g., home.json, products.json), each developer can work on their feature's translation file without affecting others. This dramatically improves collaboration and makes the entire translation process more manageable.

The Advantage of a Global `common.json`

The common.json file serves as a single source of truth for all frequently used strings across your entire application. This offers two key benefits:

Centralization: It ensures consistency for common phrases like "Submit," "Cancel," or "Search." You only have to translate these once, which reduces effort and prevents human error.
Immediate Availability: Since it's preloaded, any part of your application can instantly access these translations without waiting for a dynamic import.

The Core Function: A Custom Composable

The power of this solution lies in a custom function that handles all the heavy lifting. This self-contained function provides a clean API for requesting translations for a specific feature. It performs these key functions:

Dynamic Loading: When called with a namespace (e.g., 'home'), it automatically imports the corresponding translation file for the current language.
Built-in Caching: It uses a Map to cache promises, preventing redundant network requests if the same namespace is requested multiple times.
Reactive State Management: It exposes an isReady flag, a reactive state that indicates when the translations have finished loading. This allows your component to show a loading state before rendering, preventing translation keys from appearing.
Global Integration: After a translation file is loaded, the function merges it into the global i18n instance. This ensures any component can access the new translations using the standard t() function.

This custom function keeps your components clean and focused on their core logic, abstracting away all the complex i18n management.

A significant advantage is how this pattern works with child components. Once a parent component (like a page or a large section) loads a namespace, all of its children will have automatic access to those translations. A child component only needs to use the composable if it is being used in a different context or needs to load a new namespace not provided by its parent. This avoids redundant calls and keeps your application efficient.

Example: Final Code in Vue.js

Here’s how this pattern looks in a real-world Vue.js application.

Initial Setup (`main.ts` and `i18n.ts`)

First, you need to set up the global i18n instance. This is done by creating an i18n file and then registering it as a middleware in your main application file.

src/i18n.ts

import { createI18n } from 'vue-i18n';
import commonTranslations from './locales/common.json';

const i18n = createI18n({
    locale: 'en',
    fallbackLocale: 'en',
    messages: {
        en: {
            common: commonTranslations.en
        },
        fr: {
            common: commonTranslations.fr
        },
    },
    legacy: false,
});

export default i18n;

src/main.ts

import { createApp } from 'vue';
import App from './App.vue';
import i18n from './i18n';

const app = createApp(App);
app.use(i18n); // Register the i18n instance as a middleware
app.mount('#app');

The Self-Contained Composable (`useI18nNamespace.ts`)

This composable handles everything internally, from loading the namespace to managing its ready state.

// src/composables/useI18nNamespace.ts
import { ref, watchEffect } from 'vue';
import { useI18n } from 'vue-i18n';
import i18n from '@/i18n';
import type { I18nNamespace } from '@/types/namespaces';

const loadingPromises = new Map<I18nNamespace, Promise<void>>();

export function useI18nNamespace(namespace: I18nNamespace) {
    const { t, locale } = useI18n({ useScope: 'global' });
    const isReady = ref(false);

    const load = async (ns: I18nNamespace) => {
        isReady.value = false;
        const currentLocale = locale.value;
        
        if (i18n.global.getLocaleMessage(currentLocale)?.[ns]) {
            isReady.value = true;
            return;
        }

        if (loadingPromises.has(ns)) {
            await loadingPromises.get(ns);
            isReady.value = true;
            return;
        }
        
        const promise = (async () => {
            try {
                const importedMessages = await import(`@/locales/${currentLocale}/${ns}.json`);
                i18n.global.mergeLocaleMessage(currentLocale, {
                    [ns]: importedMessages.default,
                });
            } catch (error) {
                console.error(`Failed to load namespace "${ns}":`, error);
            }
        })();
        
        loadingPromises.set(ns, promise);
        await promise;
        isReady.value = true;
    };

    watchEffect(() => {
        load(namespace);
    });

    return { t, isReady };
}

Namespaces

Your translation files are now organized by language and namespace. A crucial part of this setup is defining a type for your namespaces.

src/types/namespaces.ts

// You must manually update this type with new namespaces
export type I18nNamespace = 'common' | 'home' | 'about' | 'products' | 'cart';

src/locales/common.json

{
  "en": {
    "submit": "Submit",
    "cancel": "Cancel"
  },
  "fr": {
    "submit": "Soumettre",
    "cancel": "Annuler"
  }
}

src/locales/en/home.json

{
  "pageTitle": "Welcome to our Home Page"
}

src/locales/fr/home.json

{
  "pageTitle": "Bienvenue sur notre page d'accueil"
}

Component Usage (`HomePage.vue`)

The component is simple and declarative. It just uses the isReady state to manage the UI.

<template>
  <div v-if="!isReady">
    <p>Loading translations...</p>
  </div>
  <div v-else>
    <h1>{{ t('home.pageTitle') }}</h1>
    <button>{{ t('common.submit') }}</button>
  </div>
</template>

<script setup lang="ts">
import { useI18nNamespace } from '@/composables/useI18nNamespace';

const { t, isReady } = useI18nNamespace('home');
</script>

Where to Use This Approach

This solution is ideal for any modern web application that is:

Large and growing: As your application's features and supported languages increase, this architecture will save you from performance bottlenecks and organizational chaos.
Performance-critical: E-commerce sites, content management systems, or any application where a fast initial page load is a priority will benefit immensely from lazy-loading.
Developed by a team: This structure prevents frequent merge conflicts and makes it easier to onboard new developers, as the translation files are logically organized alongside the features they belong to.

Using Firebase and Stripe for Modern Web Applications

Mon, 18 Aug 2025 20:25:55 +0000

Using Firebase and Stripe for Modern Web Applications

Building secure, scalable, and efficient applications often requires integrating authentication, databases, and payment systems. Two popular tools that developers rely on are Firebase and Stripe. Together, they provide a seamless backend + payment infrastructure that accelerates development without heavy server management.

In this tutorial, we’ll walk through how to integrate Firebase and Stripe in your project, with best practices for performance, serverless deployment, and real-world scenarios.

Why Use Firebase + Stripe?

Firebase handles:

Authentication (Google, GitHub, Email, Phone, etc.)
Realtime database & Firestore
Hosting & serverless functions
Notifications and cloud messaging

2.Stripe provides:

Secure and compliant payments
Subscriptions and billing
Global payment methods
Scalable APIs

When combined, Firebase + Stripe lets you build production-ready SaaS, e-commerce, or subscription apps with minimal backend code.

Setting Up Firebase

Go to the Firebase Console and create a new project
Add Firebase Authentication → enable Email/Password or OAuth
providers.
Set up Cloud Firestore for storing user data and transactions.
Deploy backend logic using Firebase Cloud Functions (powered by
serverless framework).

Setting Up Stripe

Create a free account on Stripe.
From the dashboard, copy your API keys.
Install the Stripe SDK:

npm install stripe firebase-admin firebase-functions
Create a test product or subscription plan in your Stripe Dashboard.

Integrating Firebase Cloud Functions with Stripe

Example function for creating a checkout session:

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

exports.createCheckoutSession = functions.https.onCall(async (data, context) => {
  const session = await stripe.checkout.sessions.create({
    payment_method_types: ["card"],
    line_items: [
      {
        price: data.priceId,
        quantity: 1,
      },
    ],
    mode: "subscription",
    success_url: "https://yourapp.com/success",
    cancel_url: "https://yourapp.com/cancel",
  });
  return { id: session.id };
});

This function can be called from your frontend using Firebase SDK.

Best Practices for Performance & Security

Use a bastion server or secure environment for sensitive API
operations.
Deploy in serverless containers for scalability.
Ensure PCI compliance via Stripe’s hosted checkout.
Use Firebase Authentication to link payments with user accounts.
Optimize billing operations with server optimization techniques.

Advanced Use Cases

SaaS Apps → Manage serverless ML workflows, bill users per usage.
Gaming Platforms → Use lambda GPUs or serverless GPU for compute
while charging via Stripe.
Virtual Desktops → Combine with non-persistent VDI and AWS AppStream
vs Workspaces billing.
Hybrid Architectures → Deploy with on premises servers + Firebase
Cloud Functions.
Frontend Hosting → Integrate with Vercel Serverless or similar
providers.

Conclusion

By combining Firebase and Stripe, you eliminate the need for managing on prem servers, payment gateways, or complex authentication stacks. This integration is ideal for startups, SaaS projects, and enterprise systems looking for top-rated serverless hosting for frontend developers.

Ethereum Basics: From Wallets to Smart Contracts

Wed, 09 Jul 2025 13:50:42 +0000

Opening the Door: Wallets & Addresses

A wallet isn’t just where you “keep your crypto”—it’s your digital identity on Ethereum.

Public Address = like your email (where people send you ETH)
Private Key = your super-secret password to approve transactions

With great private keys comes great responsibility.

Keep your private key off screenshots, sticky notes, or the back of your hand. Seriously.

Sending ETH: How Transactions Work

Think of a transaction like mailing a check:

You write the address + amount
You sign it with your private key
You pay a gas fee (like postage)
Ethereum confirms and records it forever

Once it's in, it’s in. Ethereum doesn’t do “undo.”

Diving Into Smart Contracts

A smart contract is like a vending machine that runs on code:

You send ETH → The machine checks the rules → It delivers the snack (or doesn’t)

These contracts automate everything from NFTs to DeFi lending to on-chain games—no humans in between.

⚙️ The Tools You Need

Your Ethereum toolbox :

MetaMask – Your wallet and dApp gateway
Remix IDE – Try writing your first contract in the browser
Truffle / Hardhat – Full toolkits for bigger dApps

These help you write, test, and deploy Solidity code like a pro.

So You Met a Fox… and Accidentally Discovered the World Computer

At first, it looked like just another crypto wallet... until I realized I had downloaded a portal to a decentralized world computer.

♦ Ethereum Is More Than a Coin — It’s a World Computer

Ethereum runs on something called the Ethereum Virtual Machine (EVM) — a fancy way of saying:

Everyone runs the same code, and everyone agrees on the result.

Every Ethereum node is like a tiny brain in a big robot. Together, they make Ethereum a global, unstoppable, tamper-proof machine.

You’ve heard of the cloud? Ethereum is the thunderstorm. ⚡

EOAs vs. Contracts — Who Runs the Show?

You (and MetaMask) are using an Externally Owned Account (EOA):

Has a private key
Can send transactions
Can own and control smart contracts

But the smart contracts themselves? They’re contract accounts:

No private key
Can receive ETH
React only when triggered

You can think of EOAs as players and contracts as automated chessboards that move when touched.

Your First Contract: The Testnet Faucet

Let’s make it rain (test ETH)!

Here’s a super simple (but very insecure) smart contract:

function withdraw(uint amount) public {
  require(amount <= 0.1 ether);
  msg.sender.transfer(amount);
}

This lets anyone request up to 0.1 ether. It’s like asking a magical bank to give you some coins—if the rules allow.

Step-by-step:

Paste this into Remix IDE
Compile it with the Solidity compiler
Deploy it with MetaMask on the Ropsten testnet
Send some ETH to the contract
Call withdraw(100000000000000000) and voilà! ETH sent!

Congratulations—you just made money move with code.

What You Really Did

Created a wallet
Funded it with test ETH
Wrote a contract
Deployed it on the testnet
Interacted with Ethereum like a dev

Final Thoughts

You didn’t just install a wallet. You just shook hands with the future of the internet.

Ethereum lets you go beyond holding coins—it lets you build logic, automation, and applications around value itself.

Welcome to Web3. This is just the beginning.

From Basics to Best Practices: Why Angular Developers Should Adopt GraphQL

Fri, 20 Jun 2025 03:04:20 +0000

As Angular developers, we’re used to structured development, powerful CLI tools, and TypeScript's safety. But when it comes to APIs, most of us still work with REST. While REST has served us well, GraphQL offers a modern, more flexible alternative—especially when building dynamic, scalable Angular applications.

In this blog, we’ll explore why GraphQL fits naturally into Angular projects, how to get started, and what best practices to follow.

Why Should Angular Developers Care About GraphQL?

1. Strong Typing = TypeScript's Best Friend

GraphQL uses a strongly-typed schema, which integrates perfectly with Angular's TypeScript-first ecosystem. With tools like GraphQL Code Generator, you can auto-generate TypeScript types for your queries, reducing errors and boosting DX (developer experience).

2. Single Endpoint, Precise Queries

Instead of juggling multiple REST endpoints, GraphQL uses one endpoint and lets clients ask for exactly what they need. This avoids over-fetching/under-fetching and speeds up UI development in Angular components.

3. Better for Complex UIs

GraphQL’s nested queries let you fetch related data in one go—ideal for component-driven UIs in Angular, where you need parent and child data together.

Setting Up GraphQL in an Angular Project

Step 1: Install Apollo Client

Use Apollo Angular to integrate GraphQL easily.

ng add apollo-angular

If the CLI command doesn’t work, install manually:

npm install @apollo/client graphql apollo-angular

Step 2: Configure Apollo Client

// app.module.ts
import { NgModule } from '@angular/core';
import { HttpClientModule } from '@angular/common/http';
import { ApolloModule, APOLLO_OPTIONS } from 'apollo-angular';
import { HttpLink } from 'apollo-angular/http';
import { InMemoryCache } from '@apollo/client/core';

@NgModule({
  imports: [HttpClientModule, ApolloModule],
  providers: [
    {
      provide: APOLLO_OPTIONS,
      useFactory: (httpLink: HttpLink) => ({
        cache: new InMemoryCache(),
        link: httpLink.create({ uri: 'https://your-graphql-api.com/graphql' }),
      }),
      deps: [HttpLink],
    },
  ],
})
export class AppModule {}

Step 3: Create a Query in Your Component

// app.component.ts
import { Component } from '@angular/core';
import { Apollo, gql } from 'apollo-angular';

const GET_USERS = gql`
  query {
    users {
      id
      name
      email
    }
  }
`;

@Component({
  selector: 'app-root',
  template: `
    <h1>Users</h1>
    <ul *ngIf="users">
      <li *ngFor="let user of users">{{ user.name }} ({{ user.email }})</li>
    </ul>
  `,
})
export class AppComponent {
  users: any[] = [];

  constructor(private apollo: Apollo) {
    this.apollo.watchQuery({ query: GET_USERS }).valueChanges.subscribe((result: any) => {
      this.users = result?.data?.users || [];
    });
  }
}

Bonus: Auto-Generate Types

Install GraphQL Code Generator:

npm install @graphql-codegen/cli
npx graphql-codegen init

This tool reads your schema and queries, and auto-generates TypeScript interfaces, query functions, and hooks for Angular.

Best Practices for Angular + GraphQL

Practice	Why it matters
✅ Use GraphQL Codegen	Ensures strict type safety and DX
✅ Use Apollo Caching	Boosts performance with normalized caching
✅ Separate Queries/Mutations	Keep queries in `.graphql.ts` or `.gql` files
✅ Use Fragments	Reuse common fields between components
✅ Use Interceptors	Add auth tokens dynamically
✅ Paginate Large Lists	Avoid loading unnecessary data

Angular & GraphQL Auth Tip

To attach auth tokens to GraphQL requests, use an ApolloLink:

import { setContext } from '@apollo/client/link/context';

const authLink = setContext((_, { headers }) => {
  const token = localStorage.getItem('token');
  return {
    headers: {
      ...headers,
      Authorization: token ? `Bearer ${token}` : '',
    },
  };
});

Then combine authLink with httpLink using from:

link: from([authLink, httpLink.create({ uri: '...' })])

Summary: Why Angular Devs Should Adopt GraphQL

Benefit	Impact
Typed queries	TypeScript-friendly development
Declarative data loading	Cleaner, more readable components
Schema introspection	Better tooling and autocompletion
Single endpoint	Less REST boilerplate, more flexibility
Ecosystem support	Apollo, Codegen, DevTools, Angular CLI

Useful Resources

Ready to ditch the REST and supercharge your Angular app? GraphQL isn't just a trend—it's a robust tool for building modern, efficient frontends. And in Angular’s TypeScript-powered world, it's a perfect match.

Learnings from using Sitecore ADM

Thu, 27 Mar 2025 10:10:17 +0000

If you worked with a Sitecore XP website that has been live for a long time, I am sure you are familiar with the xDB cleanup requirements. I usually recommend to agree xDB data retention and set up the clean up process from day 1, but it is not always possible. Some websites were developed on an older version of Sitecore that did not have the built-in functionality for data removal, or the volume of xDB data was underestimated, or maybe tracking was enabled later down the line without considering data retention.

This is a common issue and the exact reason why Sitecore Analytics Database Manager (ADM) module exists. It allows viewing xDB records statistics and removing collection data (raw analytical data collected by Sitecore XP) via Sitecore UI while keeping the data integrity.

However, when I tried to use ADM for the first time on Sitecore 9 and Sitecore 10 websites, I faced a few challenges, particularly when dealing with large volumes of old data. In this article, we’ll explore these challenges and look at optimisation strategies for efficient data cleanup.

How Sitecore ADM works

One thing that is critical to understand is that any ADM cleanup process consists of two key phases: task generation and task processing.

Task generation

During this phase, the module retrieves all contacts from the xDB regardless of the date range specified by the user. It begins processing the most recent contacts first and systematically works backward through the database. The module reads additional data associated with each contact, such as interactions and facets, to determine whether a record meets the deletion criteria. If a contact qualifies for deletion, its ID is stored in the [Tasks] table of the [ADM.Tasks] database for later task processing.

Task processing

In the second phase, the module processes the tasks generated in the previous step, deleting all records marked for removal.

While this approach seems robust at first, it comes with a few significant limitations, particularly around the performance and scalability of the task generation phase.

Challenges

1. Inefficient SQL queries

One of the main challenges is the way how the ADM module works with xDB Shard databases. Instead of relying on SQL indexes to efficiently filter contacts by date, the module retrieves all contacts and iterates through them, starting with the most recent. This results in slower data retrieval times, especially when working with large datasets spanning several years.

For instance, even if you specify a short date range in 2022, the module will still need to process and check all contacts, including those from 2023-2024. This significantly increases the load on the shard databases, leading to higher data input/output operations and longer processing times.

2. Threading and timeout issues

By default, the ADM module operates with 4 threads and processes 1,000 contacts per batch. While these settings may be sufficient for smaller databases, you may want to tweak these settings if you have a larger database.

The module’s batching system divides work between threads at the start of the process, meaning that if there is an SQL timeout in one of the threads, the entire thread will be aborted and the cleanup of this batch will not be completed. Therefore, the same process will have to be restarted from scratch to pick up remaining DB records. This can be frustrating, particularly when processing large datasets that take several hours to be processed.

3. Single task limit

Another challenge is that only one cleanup process can run at a time. Attempting to create a new task while another is running will terminate the existing process, which makes it critical to monitor and manage the process carefully.

4. Limited pause functionality

The task generation phase cannot be paused, it is supported only for task processing. There was an idea to run the cleanup in batches outside of business hours for one of the websites with a lot of xDB data to remove, but it was impossible to do run task generation in batches because it cannot be paused and it had to be done in one go.

Optimisation tactics

Here are some tricks that helped me to reduce processing times and achieve the best performance for the cleanup in the past:

1. Read documentation

I know this sounds obvious, but if you plan to use ADM and have not looked at the documentation that comes with it, do it now! It is quite technical and can answer many questions you already have.

2. Upscale to Premium tier

If your server or database resources are under strain, especially Shards and ProcessingPools databases, you can try temporarily upscaling them for the cleanup. Premium Azure SKUs are optimised for high data I/O, which is critical when working with the ADM intensive data processing.

3. Adjust performance settings

There is some flexibility in tweaking the performance of the ADM module. You can increase multiple NumberOfThreads, RetrieveDataBatchSize and NumberOfConnectionRetries settings in the ADM configuration files (see section "6. Performance Tuning" in the ADM module documentation). This helps speed up task generation and processing but should be balanced against server and database available resources.

4. Measure and plan accordingly

Although tempting, splitting the cleanup process into smaller date ranges may not necessarily improve performance. The ADM module will still read all contacts every time, so this strategy may not be the most efficient for some cases. Instead, allow the process to finish at least one time and monitor its completion, note the time taken to better estimate and plan additional runs.

Also, if you plan to perform the cleanup in multiple runs, start with the recent date ranges because they will be accessed first during the task generation phase.

5. Consider direct SQL queries

If you have an older version of Sitecore, or if you struggle to run ADM process on your xDB Shards even after tweaking performance settings, an alternative approach could be used - running direct SQL queries to clean up data (you can find a few useful scripts here). However, this method requires understanding of SQL scripts and xDB tables structure, so do this only if you have backed up your Shard DBs and you are confident in your skills.

Sitecore xDB cleanup is not always simple and the ADM module can be useful tool for managing and cleaning up contact and interaction data. I hope this article helped you to understand how the module works, its limitations and tactics for optimising its performance.

Author: Anna Bastron, Sitecore MVP

Solved: blocked a frame with origin "null" from accessing a cross-origin frame

Fri, 14 Mar 2025 21:09:12 +0000

The 'Blocked a frame with origin "null" from accessing a cross-origin frame' Error and How to Resolve It

The "Blocked a frame with origin 'null' from accessing a cross-origin frame" error occurs due to cross-origin restrictions. This issue typically arises when your browser tries to access content from a different origin (domain) or when you're running a local HTML file directly from your file system. Let's walk through the potential solutions to resolve this error.

What is the "Blocked a frame with origin 'null' from accessing a cross-origin frame" error?
Why does the "Blocked a frame with origin 'null' from accessing a cross-origin frame" error occur?
How to resolve this error:
1. Use a local web server
2. Disable cross-origin security in the browser (Not Recommended for production)
3. Use extensions like XAMPP or Live Server
4. Use the window.postMessage() method for cross-origin communication
Conclusion

What is the "Blocked a frame with origin 'null' from accessing a cross-origin frame" Error?

This error is a security feature in modern browsers like Google Chrome that prevents one document (or frame) from accessing another document that originates from a different domain, protocol, or port. If you see this error, it means the browser is blocking content for security reasons to prevent cross-site scripting (XSS) attacks.

Why Does the "Blocked a frame with origin 'null' from accessing a cross-origin frame" Error Occur?

This issue typically occurs when you're trying to display content from one website within an iframe or frame on another website, but the two domains are not the same. This is referred to as a cross-origin request.

If you open a local HTML file directly in the browser (without a web server), the origin is often considered "null," which causes the error. Browsers impose these restrictions for security purposes to prevent malicious access to data across domains.

The error message usually looks like this:

DOMException: Blocked a frame with origin "null" from accessing a cross-origin frame.

How to Resolve the "Blocked a frame with origin 'null' from accessing a cross-origin frame" Error

Solution 1: Use a Local Web Server

Running your webpage on a local web server solves this issue by setting up a proper origin. You can do this easily by using tools like XAMPP, Python's built-in HTTP server, or any other local server setup.

For example, if you're using Python, you can run:

```bash
python -m http.server 8000
```

This will serve your files at http://localhost:8000.

Alternatively, you can set up a server using XAMPP by moving your files to the htdocs folder and starting the Apache server.

Solution 2: Disable Cross-Origin Security in the Browser (Not Recommended for Production)

Some developers attempt to bypass this error by disabling cross-origin security or the same-origin policy in their browsers.

Warning: Disabling cross-origin security is extremely risky and should never be done in a production environment. This action makes your browser vulnerable to various security issues, such as cross-site scripting (XSS) attacks. It should only be used for local development and testing purposes.

To disable cross-origin security in Chrome, you can launch it with the following command:

```bash
chrome.exe --disable-web-security --user-data-dir="C:\chrome_dev"
```

Again, this method is only for development and should be avoided in production environments.

Solution 3: Use Extensions Like XAMPP or Live Server

You can use local server extensions, such as XAMPP or Live Server, which allow you to serve your files from a local server environment.

XAMPP: Install XAMPP and place your files in the htdocs directory. Then start the Apache server and visit http://localhost/yourfile.html.
Live Server: If you're using Visual Studio Code (VS Code), the Live Server extension can quickly launch a local server with one click. It also provides auto-refresh and debugging features for smoother development.

Solution 4: Use the `window.postMessage()` Method for Cross-Origin Communication

The best and most secure way to enable cross-origin communication between documents (or iframes) is by using the window.postMessage() method. This allows you to send messages between windows or frames even if they come from different origins.

Here’s an example of how to use postMessage:

```javascript
// Sender (parent window)
window.postMessage('Hello from parent!', '*');

// Receiver (iframe)
window.addEventListener('message', function(event) {
    if (event.origin !== 'http://example.com') {
        return; // Ignore messages from unknown origins
    }
    console.log('Message received:', event.data);
});
```

By using postMessage(), you can safely communicate across origins without violating the browser’s same-origin policy.

Conclusion

While disabling cross-origin security might seem like a quick fix, it is highly discouraged for any production-level work due to the significant security risks it introduces. The best practice is to serve your files through a local web server or to use window.postMessage() for secure communication between frames or windows from different origins.

Always be cautious when working with cross-origin content. Only disable security settings for local development, and make sure to follow best practices to ensure the security of your application.

Understanding JWT: From Basics to Advanced Security

Fri, 28 Feb 2025 19:34:07 +0000

Introduction: The Evolution of Web Authentication

Early days of the web, authentication was relatively simple - users would log in, and servers would store their session information. However, as applications grew more complex and moved toward distributed systems and microservices, this traditional approach faced scalability challenges. JSON Web Tokens (JWTs), a revolutionary solution that changed how we handle authentication and authorization in modern web applications.

JWTs represent a paradigm shift in web security. Instead of the server keeping track of who's logged in, it issues a secure, self-contained token that holds all necessary information about the user. Think of it like a digital passport - once issued by a trusted authority, it can be verified anywhere without needing to check back with the issuing country. This approach has become increasingly important in our interconnected world of cloud services, mobile applications, and API-driven architectures.

Part 1: JWT Fundamentals

What is a JWT?

A JSON Web Token is a compact, self-contained way to securely transmit information between parties as a JSON object. Think of it as a digital passport that proves your identity and permissions in the web world. Each JWT contains three essential parts:

Header: The metadata section that describes the token's type and the signing algorithm used
Payload: The actual data (called "claims") about the user and additional metadata
Signature: A verification seal that ensures the token hasn't been tampered with

When these three parts are combined, you get something that looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The Anatomy of a JWT: Understanding the Structure

Before diving into how JWTs work, let's examine their structure in detail. A JWT consists of three distinct parts, each encoded in Base64URL format and separated by dots:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

1. Header (The Metadata)

The header contains information about how the token itself is constructed. It typically includes:

{
  "alg": "HS256",    // The algorithm used for signing
  "typ": "JWT"       // The type of token
}

2. Payload (The Claims)

The payload carries the actual information about the user and token metadata. It contains claims, which are statements about an entity (typically the user) and additional metadata.

There are three types of claims:

Public Claims: Custom claims registered in the IANA JSON Web Token Registry
Private Claims: Custom claims created for sharing information between parties
Registered Claims: Predefined claims like:

{
  "iss": "auth.service.com",  // Issuer
  "sub": "user123",           // Subject
  "exp": 1516239022,         // Expiration Time
  "iat": 1516232822          // Issued At
}

3. Signature (The Verification Seal)

The signature is created by taking the encoded header, encoded payload, and a secret key, then applying the algorithm specified in the header. For example, with HMAC SHA256:

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret
)

This signature ensures that the token hasn't been modified in transit and verifies its authenticity.

How Does JWT Work in Practice?

The journey of a JWT follows a simple flow:

Authentication: When you log in successfully, the server creates a JWT containing information about your identity and permissions
Token Storage: Your application receives and stores this token
Authorization: For subsequent requests, your application includes this token in the header
Verification: The server checks the token's signature and grants access if it's valid

This process eliminates the need for the server to store session information, making JWTs perfect for modern, scalable applications.

Part 2: The Security Challenge

Common JWT Vulnerabilities

While JWTs are powerful, they're not immune to security issues. Here are the key vulnerabilities to watch out for:

Signature Verification Flaws

The signature is like a tamper-evident seal on a package. If the verification process is flawed or the secret key is weak, attackers can modify the token's contents without detection. This is particularly dangerous because it could allow unauthorized access to protected resources.

Algorithm Confusion Attacks

JWTs support multiple signing algorithms, including a dangerous "none" algorithm. If your server isn't configured properly, an attacker might trick it into accepting an unsigned token, effectively bypassing security checks altogether.

Client-Side Storage Risks

Many applications store JWTs in browser storage (localStorage or sessionStorage), making them vulnerable to Cross-Site Scripting (XSS) attacks. Think of this like keeping your house key in an obvious place - if someone gains access to your browser's JavaScript environment, they could steal your token.

The Revocation Challenge

Unlike traditional session tokens, JWTs don't have a built-in way to be invalidated before they expire. This means if a token is compromised, it remains valid until its expiration time, potentially giving attackers a window of opportunity.

Part 3: Building a Secure JWT Implementation

Essential Security Practices

Let's explore how to implement JWTs securely:

1. Secure Communication

Always transmit JWTs over HTTPS. This encrypts the token during transmission, preventing eavesdropping attacks. It's like sending sensitive documents through a secure courier service instead of regular mail.

2. Smart Token Storage

Instead of using browser storage, use HttpOnly cookies with the Secure flag enabled. This approach prevents JavaScript access to the token while ensuring it's only transmitted over secure connections. The cookie settings might look like this:

Set-Cookie: access_token=<token>;
            HttpOnly;
            Secure;
            SameSite=Strict;
            Path=/api

3. Token Lifecycle Management

Implement a robust token lifecycle strategy:

Set short expiration times for access tokens (15-30 minutes)
Use refresh tokens for obtaining new access tokens
Maintain a token blacklist for revoked tokens
Implement token rotation to regularly replace active tokens

4. Payload Security

Be mindful of what you include in your token payload:

Never store sensitive data like passwords or credit card numbers
Minimize the payload size to reduce overhead
Consider encrypting certain claims if they contain sensitive information

Advanced Security Measures

Going beyond the basics:

1. Fingerprinting

Include device or context information in the token to detect potential token theft:

{
  "sub": "1234567890",
  "fingerprint": "device_id|user_agent|ip_hash",
  "exp": 1516239022
}

2. Audience Validation

Specify and validate the intended recipient of the token to prevent token reuse across different services:

{
  "aud": "https://api.myservice.com",
  "sub": "1234567890",
  "exp": 1516239022
}

Part 4: The Future of JWT Security

Emerging Security Enhancements

The security landscape is constantly evolving, and JWT security is no exception. Here are some promising developments:

1. Quantum-Resistant Algorithms

As quantum computing advances, new signing algorithms resistant to quantum attacks are being developed. These will ensure JWTs remain secure even in a post-quantum world.

2. Dynamic Validation

Future implementations might include real-time validation systems that can instantly revoke tokens based on security events or user behavior changes.

3. Enhanced Standards

The JWT standard continues to evolve with new security features and best practices. Stay updated with the latest JWT specifications and security recommendations from the IETF.

Conclusion

JWTs represent a powerful solution for modern web authentication and authorization, but their security requires careful consideration and implementation. By understanding both the fundamentals and security challenges, and by implementing robust security measures, you can harness the benefits of JWTs while maintaining strong security.

Learn on JWT, OAuth, OIDC, and SAML: https://guptadeepak.com/demystifying-jwt-oauth-oidc-and-saml-a-technical-guide/

Quick Reference: JWT Security Checklist

✓ Use strong, unique signing keys
✓ Implement proper algorithm validation
✓ Store tokens securely (HttpOnly cookies)
✓ Set appropriate token expiration
✓ Implement token rotation
✓ Validate token claims thoroughly
✓ Monitor for security updates
✓ Use HTTPS exclusively
✓ Implement proper error handling
✓ Regular security audits