DEV Community: Neeraj Mukta

Top 3 JEV Alternatives in 2026

Neeraj Mukta — Mon, 19 Oct 2026 12:28:33 +0000

Jev made AI decisions cheaper and faster. But with open-weight models and new competitors entering the market, is it still the right choice for your application?

Most AI applications don't need another paragraph of generated text.

They need an answer to a specific question.

Is this support ticket urgent? Should this customer be routed to sales or billing? Does this message violate our moderation policy? Should an AI agent call a tool or ask a human for help?

Traditionally, developers use general-purpose large language models (LLMs) for these decisions. They send a prompt, ask for structured JSON, and parse the response. It works, but it can introduce unnecessary latency, cost, and complexity.

Jev, developed by TypeSafe AI, takes a different approach: instead of generating text, it returns typed decisions with probabilities that your application can act on directly. Source: TypeSafe AI

But Jev isn't the only option anymore. Cloudflare, Perplexity, and open-source developers are building alternatives that offer different combinations of price, accuracy, flexibility, and deployment control.

Let's look at what makes Jev useful, where its pricing can become expensive, and the three alternatives worth evaluating.

Jev pricing: Is it actually expensive?

Jev's published pricing is straightforward: $0.042 per million input tokens, with output tokens free, according to TypeSafe AI's pricing information. Source: TypeSafe AI

There are no per-seat charges in that pricing model. You pay for the input processed by the model.

Here is what the listed rate means in practice:

Monthly input volume	Estimated API cost
1 million tokens	$0.042
100 million tokens	$4.20
1 billion tokens	$42
10 billion tokens	$420

These figures use the published input rate and exclude infrastructure, retries, and other application costs.

At first glance, Jev is remarkably cheap. So why look for alternatives?

The absence of a free tier matters during experimentation

A low per-token price isn't the same as free experimentation. Developers building an MVP often test prompts, replay datasets, and run evaluations repeatedly. Even if the API bill stays small, there is no reason to pay for a hosted service before establishing that it works for your use case.

Input volume is the real cost driver

Decision models charge for the information they process. Passing an entire conversation history or a long document when a short excerpt would suffice wastes tokens.

For example, processing 10,000 tokens per decision instead of 1,000 tokens increases input costs tenfold.

The solution isn't necessarily switching providers. It may be trimming the input, caching unchanged decisions, and batching related questions.

Closed weights limit deployment flexibility

Jev is a hosted, proprietary model. If you want to run inference within your own infrastructure, fine-tune a model on your own labelled dataset, or exercise greater control over deployment, you need to evaluate other approaches.

Cheap inference doesn't guarantee cheap decisions

Accuracy matters. A model that costs less per request but misroutes support tickets or incorrectly blocks legitimate users may be more expensive overall.

The verdict: Jev's published token price is already very low. Its strongest alternatives aren't necessarily about saving a few dollars. They are about open weights, multimodal inputs, deployment flexibility, and finding a model that performs better on your specific workload.

The top 3 Jev alternatives

Cloudflare Clef-flash — Best for Cloudflare developers

Cloudflare introduced Clef and Clef-flash as open-weight decision models in October 2026. Like Jev, they take a state and typed questions and return probabilities for the allowed answers. Source: Cloudflare announcement

Clef-flash is the smaller, faster-oriented option in the family, with support for text, JSON, images, and video.

Pricing: Cloudflare lists Clef-flash at $0.038 per million input tokens on Workers AI. Its hosted context window is 24,576 tokens. Source: Cloudflare model documentation

Pros

Slightly cheaper than Jev at the published hosted rate.

Open weights under the Apache 2.0 licence, allowing self-hosting subject to the licence.

Supports image and video inputs, unlike Jev's text-only interface.

A natural option for applications already using Cloudflare Workers AI.

Decision-oriented outputs avoid the need to parse free-form generated prose.

Cons

The smaller hosted context window may be a limitation for long documents or conversation histories.

The larger Clef model costs more: $0.24 per million input tokens on Workers AI.

Open weights don't mean free production inference; self-hosting requires compute and operational work.

You still need to benchmark accuracy and confidence calibration on your own dataset.

Best use cases: AI applications running on Cloudflare, image-based moderation, multimodal workflows, and teams that want more control over model deployment.

My take: If your backend already runs on Cloudflare, Clef-flash is the first alternative I'd benchmark. The combination of a lower listed price, multimodal support, and open weights makes it a compelling option.

Perplexity pplx-decider — Best candidate for cost-conscious, high-volume decisions

Perplexity's pplx-decider family is another direct competitor in the decision-model category. Its newer 27B model, pplx-decider-v1.1-27b, is designed to return structured decisions rather than conventional chat responses.

Perplexity announced the updated model in October 2026, positioning it as an open-weight, multimodal decision model. Source: Perplexity API announcements

Pricing: Recent October 2026 comparisons report hosted input pricing as low as $0.02 per million tokens. Verify the current model-specific API rate before committing to a budget, as prices and hosting options can change quickly.

Pros

Potentially the lowest hosted input cost among the three alternatives discussed here.

A 27B model offers a different quality-versus-compute trade-off from smaller models.

Open-weight availability provides a route to self-hosting, subject to the model's licence and distribution terms.

Multimodal capabilities make it worth testing for workflows that go beyond plain text.

An attractive candidate for applications processing large numbers of repetitive decisions.

Cons

A larger model may require more resources if you self-host it.

Lower token pricing doesn't guarantee lower total cost if the model uses more tokens or needs more retries.

You should verify current API compatibility, licensing, and deployment requirements rather than assume they match Jev exactly.

Public benchmark results may not predict performance on your particular labels, languages, or business rules.

Best use cases: High-volume classification, ticket routing, moderation, and applications where reducing per-decision inference costs is a priority.

My take: Perplexity is worth evaluating when you're optimizing for unit economics at scale. However, compare the actual billed tokens per decision, not just the advertised price per million tokens. Different APIs can account for shared input and multiple questions differently.

Kev — Best for developers who want self-hosting and control

Kev is an open-weight family of decision models associated with developer Jared Palmer. It is designed for the same general task as Jev: answering predefined questions about an input with structured outputs.

Kev is particularly interesting because it offers multiple model sizes and documents support for fine-tuning on your own labelled examples. Its server can also use a Jev-compatible request format, making it a candidate for testing as a replacement. Background: Jev alternatives comparison

Pricing: The model weights can be used without paying a per-token API fee when you run them yourself, subject to the applicable licence. Compute, hosting, storage, and engineering time are still costs.

Pros

Self-hosting gives you greater control over where inference happens.

Multiple model sizes let you explore the trade-off between speed, resource requirements, and accuracy.

Fine-tuning can help with domain-specific classifications and custom labels.

A Jev-compatible server interface can reduce migration effort.

No mandatory per-token provider charge when you operate your own inference infrastructure.

Cons

You must deploy, monitor, scale, and maintain the model.

Hardware and engineering costs can outweigh API savings at low volumes.

Fine-tuning requires good labelled data, evaluation, and ongoing maintenance.

Performance and calibration must be tested; open weights don't automatically mean equivalent quality to Jev.

Best use cases: Teams with privacy or deployment constraints, products with stable classification tasks, and developers who want to customize a model for their own data.

My take: Kev is the option I'd investigate if control matters more than convenience. For a weekend MVP, a hosted API is generally simpler. For a mature product with substantial inference volume or strict data requirements, self-hosting becomes a more serious contender.

Jev vs. its alternatives: Quick comparison

Criteria	Jev	Clef-flash	pplx-decider	Kev
Main strength	Simple hosted decisions	Cloudflare and multimodal workflows	Cost-conscious decisions	Self-hosting and customization
Listed input price	$0.042/M	$0.038/M hosted	Reported as low as $0.02/M hosted	No mandatory per-token fee when self-hosted
Output token charge	Free	Free	Check current API pricing	Depends on deployment
Open weights	No	Yes	Available; verify licence	Yes
Multimodal	Text-focused	Yes	Yes, for supported inputs	Model-dependent
Operational effort	Low	Low when hosted	Low when hosted	Higher when self-hosted
Best fit	Quick integration	Cloudflare applications	High-volume evaluation	Custom infrastructure

Prices are in USD and are based on published or recently reported October 2026 rates. They are not a like-for-like performance benchmark. Check each provider's current documentation before deployment.

Which alternative should you choose?

There isn't one universal winner. The right decision depends on what you're optimizing for.

Choose Jev if you want a straightforward hosted API for typed decisions and its performance meets your requirements. At its published price, switching solely to save money may not justify the migration.

Choose Clef-flash if you use Cloudflare, need multimodal decision-making, or want open weights without giving up hosted inference.

Choose pplx-decider if low hosted inference cost is a priority and your own evaluations confirm that it performs well on your workload.

Choose Kev if you need self-hosting, greater customization, or control over your inference environment.

How I'd evaluate them before switching

Don't choose based on benchmark rankings alone. Build a small evaluation set from real inputs in your application.

Collect 200–500 representative examples from your actual workload.

Label the correct answers and identify decisions where an error would be costly.

Run Jev and the alternatives on the same examples with equivalent questions.

Measure accuracy, per-class precision and recall, latency, and calibration.

Record the actual billed tokens and cost per accepted decision, including retries.

Test how each model behaves on ambiguous or unfamiliar inputs.

For production systems, define explicit confidence thresholds and route uncertain or high-impact decisions to human review. A probability is useful only if it helps you make better decisions about when to trust the model.

One additional consideration: if your label set is fixed and you have enough labelled data, a conventional trained classifier may outperform all these options on cost and latency. If your task requires open-ended reasoning or explanations, a general-purpose LLM with structured outputs may be the better fit.

Final thoughts

Jev is interesting because it challenges a common assumption in AI development: that every intelligent operation needs to generate text.

Most applications don't need prose at every step. They need reliable decisions that software can act on.

That distinction creates opportunities to build faster, cheaper, and more predictable AI workflows. But the market is evolving quickly, and open-weight models are making it easier to choose where and how those decisions happen.

My recommendation is simple: start with the simplest hosted option, benchmark alternatives against your own data, and switch only when you can demonstrate a meaningful improvement in cost, quality, latency, or control.

The best decision model isn't the one with the most impressive benchmark. It's the one that makes your application work better.

Have you tried Jev, Clef, pplx-decider, or Kev in production? I'd be interested in hearing about your measured latency, accuracy, and cost per decision.

Top 4 Jev Use Cases: Why AI Needs a Decision Engine

Neeraj Mukta — Tue, 13 Oct 2026 16:47:30 +0000

Top 4 Jev Use Cases: Why AI Needs a Decision Engine

The AI boom has focused on generating better text: bigger models, longer reasoning, and larger context windows.

But production AI systems have a different problem. They need to make decisions.

Should a request go to a particular agent? Is an answer grounded in the source material? Is a tool call safe? Which retrieved documents are actually relevant?

Developers often use LLMs for these tasks, even though they don't need a paragraph of text. They need a reliable answer, fast.

That's where Jev comes in.

What Is Jev?

Jev, developed by TypeSafe AI, is designed for structured decisions rather than text generation.

Think of traditional LLMs as System 2 thinkers: capable of reasoning through complex problems, but relatively expensive and slow for simple checks.

Jev takes the System 1 approach: fast, focused decisions with structured outputs.

The idea is simple: use generative models to create, and decision models to evaluate.

If decisions become cheaper and faster, software can make more of them without adding unnecessary latency or cost.

How Does Jev Work?

Instead of asking a model to generate text and then parsing the response, you give Jev a state and a set of questions.

It supports three types of decisions:

Noul: A binary decision, such as whether an answer is supported by the source.
Score: A rating, such as customer sentiment from 1 to 5.
Choice: A classification, such as routing a request to billing, support, or sales.

Jev returns structured values that your application can use directly in its logic.

For example, instead of asking an LLM to explain whether a refund is eligible, your application can ask for a binary decision and use the result to determine the next step.

No unnecessary prose. No parsing generated JSON. Just structured output.

Jev vs. Traditional LLMs

	Traditional LLM	Jev
Best for	Generation and complex reasoning	Classification, scoring and selection
Output	Text or generated JSON	Structured decisions
Latency	Depends on model and output length	Designed for low-latency inference
Cost	Input and output tokens	Designed for low-cost decisions
Best role	Creating answers	Evaluating and routing work

Jev isn't a replacement for GPT or Claude. It fills a different role.

Think of it as a decision layer alongside your LLM stack.

Top 4 Practical Use Cases for Jev

1. Evaluating LLM Outputs

LLMs can generate convincing answers that aren't necessarily correct. One common solution is to use another LLM as a judge.

But running a second generative model for every response adds latency and cost.

Jev could handle simpler evaluation tasks:

Fact-checking: Is the generated answer supported by the retrieved context?
Safety checks: Does the response violate a defined policy?
Quality scoring: Does the answer meet a predefined rubric?

You can set thresholds to decide what happens next. High-confidence results pass, clear failures get blocked, and uncertain cases go to a stronger model or human reviewer.

The key benefit is not eliminating evaluation. It's making routine evaluation cheaper and faster.

2. Routing Requests to the Right Agent

Multi-agent systems need to decide which agent, tool, or workflow should handle an incoming request.

A traditional approach is to prompt an LLM to return a category such as billing, support, or sales.

Jev can handle this as a classification problem.

Route requests using predefined categories.
Avoid generating and parsing unnecessary text.
Ask a clarifying question when confidence is too low.

This is especially useful when routing sits directly in the request path and every extra millisecond matters.

3. Filtering Context in RAG Pipelines

Retrieval-Augmented Generation (RAG) systems often retrieve documents that look relevant to a query but don't actually help answer it.

Passing every retrieved chunk to an LLM wastes tokens and can dilute the useful context.

Jev can score retrieved passages against the user's query before generation.

Rank chunks by relevance.
Remove irrelevant or redundant content.
Send a smaller, more useful context to the generation model.

The result could be lower inference costs and better answers, provided the scoring model is accurate enough for the task.

4. Verifying Agent Tool Calls

AI agents can make risky tool calls, repeat the same actions, or get stuck in loops.

Jev can act as an additional decision layer between an agent and its tools.

For example:

Risk checks: Should a proposed database operation be allowed?
Policy checks: Does a tool call comply with predefined rules?
Loop detection: Is the agent making progress or repeating previous steps?

This can help stop suspicious or unproductive actions before they execute.

However, an important distinction remains: a model's judgment should not replace deterministic permission checks, sandboxing, or other security controls. Use Jev as an additional layer, not your only line of defense.

The Takeaway

Not every AI task needs a generative model.

Sometimes you don't need an explanation. You need a classification, a score, or a decision that your application can act on immediately.

That's the interesting idea behind Jev: separate decision-making from generation.

For AI engineers building agents, RAG pipelines, and production workflows, that separation could make systems cheaper, faster, and easier to control.

The real question isn't whether Jev replaces LLMs. It doesn't.

It's whether a specialized decision model can handle routine checks better than a general-purpose LLM at the same level of accuracy.

That's what developers should benchmark before choosing their next AI architecture.

I Scored 880 on the Claude Certified Architect Exam. Here's How I Prepared in 2 Weeks

Neeraj Mukta — Thu, 24 Sep 2026 07:42:56 +0000

What surprised me, what I actually studied, and why the exam is more about judgment than memorization.

880/1000. Two Weeks of Preparation.

Last week, I submitted the final question on Pearson VUE, completed the candidate survey, and waited for the screen to refresh.

Then my score appeared:

880 out of 1,000.

The passing score is 720, so there was definitely some relief.

I had spent roughly two weeks preparing for the Claude Certified Architect — Foundations (CCAR-F) exam, usually 90 minutes to two hours a night.

Going in, I expected the exam to test how well I knew Anthropic's documentation.

It did—but not in the way I expected.

The hardest questions weren't simply about knowing what Claude can do. They were about deciding which architectural approach makes the most sense given a specific set of constraints.

Here's what the exam was actually like, how I prepared, and what I would do if I had to prepare again.

Why I Took the Exam

AI certifications have exploded over the past year.

And, honestly, not all of them are particularly useful.

Many certifications can feel like a collection of multiple-choice questions testing whether you remember definitions, terminology, or product specifications.

I was interested in the CCAR-F for a different reason.

Anthropic positioned it as a scenario-based assessment focused on building and reasoning about Claude-powered systems.

That was relevant to the work I was already doing.

My team uses Claude Code, Model Context Protocol (MCP), and the Claude Agent SDK for customer-facing workflows and developer tooling. I wanted a structured way to test whether the architectural patterns I was using were actually sound—or whether I was just building prototypes that happened to work.

So the certification became less about collecting another badge and more about getting an external gut-check on my understanding.

The Biggest Surprise: This Isn't Just a Memory Test

The biggest misconception I had going into the exam was that I needed to memorize a lot of documentation.

Of course, there are things you need to know.

But memorization alone isn't enough.

A typical scenario might describe an agent that is consuming too much context, repeatedly calling tools, or producing unreliable outputs.

Then you're given several possible approaches.

And here's the interesting part:

More than one answer can look technically reasonable.

The challenge is figuring out which answer best addresses the actual constraint in the scenario.

Is the problem primarily:

Cost?
Latency?
Context usage?
Reliability?
Safety?
Output structure?
Tool orchestration?

That changes the answer.

For example, two architectures might both solve a problem. One might introduce additional agents and parallel processing, while another uses a simpler coordinator with structured outputs.

Neither is inherently wrong.

But if the scenario emphasizes cost efficiency and predictable execution, adding more agents may introduce unnecessary complexity.

The question isn't always:

"What works?"

It's closer to:

"What is the simplest approach that satisfies the stated constraints?"

That distinction became one of the most important lessons from the exam.

I Prepared in Two Weeks

I spent roughly 90 minutes to two hours per night for two weeks.

That worked for me largely because I wasn't starting from zero. I already had practical experience with Claude Code, MCP, and agentic workflows.

My goal wasn't to read everything Anthropic had ever published.

It was to identify the major domains, understand the architectural patterns behind them, find my weak spots, and then practice applying them.

My preparation essentially had four stages:

Understand the core architecture.
Get hands-on with Claude Code and MCP.
Review context management and structured outputs.
Practice scenario-based questions under time pressure.

The hands-on part ended up being more valuable than I expected.

The Resources I Actually Used

I deliberately kept the study stack small.

You don't need 15 courses and six different cheat sheets. You need a few reliable sources and enough practice to recognize architectural patterns.

Official Documentation & Learning Portal

Anthropic's official documentation and their Skilljar training portal were my baseline.

I focused less on memorizing individual API details and more on understanding how the pieces fit together.

Some areas I paid particular attention to included:

Agentic loops
stop_reason
Tool use
Context management
MCP
Structured outputs
Claude Code workflows
Permissions and project configuration

For example, understanding the difference between a "tool_use" and an "end_turn" stop_reason is much more useful than simply memorizing that those values exist.

The important question is what your application should do when each one occurs.

Domain Summaries

I also used the Anthropic Claude Architect Study Guide.

It was useful for turning a large amount of documentation into smaller domain-level summaries.

Instead of repeatedly jumping between documentation pages, I could quickly review the major concepts and then go back to the official documentation when something needed deeper understanding.

That combination worked well:

Summary → identify gap → official documentation → hands-on experiment.

Mock Tests

This was probably the most important part of my preparation.

I used:

The biggest benefit wasn't memorizing the answers.

It was learning how to read the scenarios.

The questions can be wordy. Instead of trying to hold the entire scenario in my head, I started looking for the core constraint first.

For example:

Is this primarily a latency problem?

Is this a context-management problem?

Is this a reliability problem?

Is this a safety problem?

Once I started doing that consistently, the answer choices became much easier to evaluate.

I Actually Used Claude Code

This was the part of my preparation I found most useful.

I didn't just read about Claude Code.

I used it.

I experimented with:

CLAUDE.md
Project-level permissions
Custom slash commands
Plan Mode
Headless workflows
Local MCP servers
Tool integrations

The goal wasn't to build anything impressive.

It was to understand how these things behave when you actually use them.

There's a big difference between reading:

"Claude Code can use project instructions through CLAUDE.md."

and actually creating a CLAUDE.md, changing the instructions, running Claude Code, and seeing how the behavior changes.

The latter sticks.

And when I encountered Claude Code questions during practice, the concepts were much easier to reason about because I'd actually used them.

What the Exam Felt Like

The exam consists of 60 scenario-based questions over 120 minutes.

That works out to roughly two minutes per question.

The time itself wasn't particularly scary.

The mental load was.

You're repeatedly given a situation, several constraints, and multiple possible solutions. Then you have to determine which approach best fits the scenario.

The Hardest Part: Choosing Between Two Good Answers

This was the part that surprised me most.

Some questions don't feel like:

Right answer vs. obviously wrong answer.

They feel more like:

Reasonable architecture A vs. reasonable architecture B.

The difference comes down to the constraints.

Imagine you're designing an agent workflow.

You could:

Add another specialized agent.
Parallelize the work.
Give the existing agent another tool.
Introduce structured outputs.
Change how context is passed between steps.

Several of these approaches could work.

But the scenario might specifically require minimizing latency, controlling costs, maintaining strict execution order, or preventing unreliable outputs.

That constraint should drive the decision.

This is where I felt the exam was testing architectural judgment rather than API recall.

The Other Surprise: Some Answers Looked Contradictory

I also came across questions where two answers initially seemed almost contradictory.

For example, one option might suggest using a coordinator agent with structured outputs, while another might use multiple specialized agents working in parallel.

If you look at the architecture in isolation, both can sound perfectly reasonable.

But the scenario changes everything.

The exam forces you to ask:

What problem are we actually solving?

That's an important distinction in real engineering too.

Good architecture isn't about finding the most sophisticated solution.

It's about finding the solution that fits the requirements without introducing unnecessary complexity.

My 14-Day Preparation Plan

Here's roughly how I divided my preparation.

Days 1–4: Agent SDK & Core Loops

I focused on:

Agentic control flow
stop_reason
Tool execution
Passing tool results back into conversation state
Structured outputs
Common agent-loop failure modes

The goal was to understand the mechanics rather than memorize API documentation.

Days 5–8: Claude Code & MCP

I spent these days actually using Claude Code.

I experimented with:

CLAUDE.md
Permissions
Plan Mode
Headless usage
Custom commands
MCP servers
Tool configuration

This was deliberately hands-on.

Days 9–11: Context Management & Structured Outputs

I reviewed:

Long-context strategies
Chunking
Summarization
Context degradation
JSON Schema
Output validation
Failure handling

The important part here was understanding when to use each strategy rather than simply knowing that it exists.

Days 12–14: Timed Practice

The final few days were mostly mock tests and scenario drills.

I started paying less attention to whether I remembered a specific fact and more attention to whether I could identify the primary constraint quickly.

That became my main exam strategy.

6 Things I'd Do If I Prepared Again

1. Build a One-Page Summary for Each Domain

Don't try to memorize the entire documentation.

For each domain, write down:

Core concepts
Important architectural patterns
Common failure modes
Key trade-offs
When to use each approach

If you can't explain a domain in your own words, you probably don't understand it deeply enough yet.

2. Practice Reading the Constraint First

This was probably the most useful change I made.

When I saw a scenario, I started asking:

What's the constraint?

Cost?

Latency?

Reliability?

Context?

Safety?

Output format?

Once you identify that, the architecture becomes easier to reason about.

3. Don't Treat Every Question Like a Documentation Lookup

You won't necessarily recognize every question from something you've read.

Instead, understand the underlying principle.

If you understand why an architecture works, you can reason through a new scenario.

If you've only memorized a documentation page, you're in trouble as soon as the question is phrased differently.

4. Get Hands-On With Claude Code

Don't just read about:

CLAUDE.md
Permissions
MCP
Plan Mode
Tools
Headless workflows

Use them.

Break things.

Change configurations.

See what happens.

Practical experience makes abstract concepts much easier to recall.

5. Practice With a Timer

The exam gives you enough time, but you don't want to spend five minutes debating one question.

I found timed practice useful because it forced me to make architectural decisions without endlessly second-guessing myself.

I'd also recommend doing multiple practice runs rather than stopping after your first passing score.

6. Don't Overcomplicate the Architecture

This is probably the lesson that extends beyond the certification.

When two approaches seem viable, don't automatically choose the more sophisticated one.

Ask:

What is the simplest architecture that satisfies the requirements?

More agents aren't automatically better.

More tools aren't automatically better.

More context isn't automatically better.

More abstraction isn't automatically better.

Sometimes the best architectural decision is simply not adding another moving part.

Who Should Consider Taking It?

I wouldn't recommend this certification to everyone who uses Claude.

It makes more sense if your work involves actually designing or implementing AI-powered systems.

For example:

Software engineers building Claude-powered applications
Technical leads
Solution architects
Engineers implementing agentic workflows
Developers working with MCP
Teams adopting Claude Code across engineering workflows

If you're primarily using Claude for writing, brainstorming, research, or everyday productivity, the certification may not provide the same practical value.

In that case, simply becoming better at using the product may be more useful than preparing for an architecture exam.

What I Actually Got Out of It

The digital badge is nice.

The 880 looks nice on paper too.

But neither was the most valuable part.

The useful part was spending two weeks deliberately thinking about architecture.

The preparation forced me to revisit concepts I had used casually and ask why I was using them.

It made me think more carefully about context, tool orchestration, agent boundaries, structured outputs, and failure modes.

More importantly, it reinforced a principle that applies well beyond Claude:

Good architecture isn't about using the most advanced technology. It's about making the right trade-offs for the problem you're actually solving.

I went into the exam expecting to validate how much Claude I knew.

I came out thinking more about how I make engineering decisions.

And for me, that's probably the most valuable thing I got from the certification.

What is AEO? A Beginner’s Guide to Answer Engine Optimization

Neeraj Mukta — Wed, 23 Sep 2026 05:23:21 +0000

keyTakeaways:

'AEO (Answer Engine Optimization) is the process of structuring content so AI answer engines (ChatGPT, Perplexity, Google AI Overviews) can easily understand and cite it.'
'Traditional SEO targets search engine ranking pages, whereas AEO targets being synthesized directly into AI generated answers.'
'Modern users search in complete conversational queries rather than fragmented keywords, demanding direct, factual, and high-density answers.'
'AEO does not replace SEO it builds on technical SEO, semantic clarity, and authoritative structured data to make content machine-understandable.'

You probably have heard of SEO (Search Engine Optimization). For decades, it has been the standard playbook for getting your website discovered on search engines.

But now there is another term rapidly taking center stage: AEO, or Answer Engine Optimization.

So what is AEO, exactly—and why are businesses and creators' attention is increasing towards it?

AEO Briefly: What Is It?

AEO (Answer Engine Optimization) is the process of creating and structuring your content in a way that AI tools and answer engines can easily understand, extract, and utilize when answering people's questions.

Here is the fundamental difference:

Traditional SEO is about getting your website to show up on Google when someone searches for a query.
AEO is about making your content the direct answer when someone asks ChatGPT, Gemini, Perplexity, Google AI Overviews, or another AI powered search tool.

A Concrete Example

Consider how someone searches for business software:

In traditional search, someone might type a short keyword into Google:

"The best CRM for a small business"

Traditional SEO tries to get your website onto the first page of Google search results.

AEO asks a fundamentally different question:

“Will an AI have enough structured, reliable knowledge of my website to answer this question and cite our brand?”

Why Do AEO?

The simple answer is that people search differently today.

Instead of typing a few keywords into a search bar, people are increasingly asking AI tools complete, nuanced questions:

"What's the best CRM for a startup of 10 people?"
"How do I make a SaaS landing page that converts?"
"What project management software should I use for a remote design team?"

AI Understands Intent, Not Just Keywords

Artificial intelligence systems do not simply look for web pages that contain an exact keyword match. They comprehend the question, retrieve relevant information across sources, and synthesize an answer.

That means businesses need to think beyond ranking for keywords.

They also need to make their content easy for machines to understand, trust, and reference.

AEO vs. SEO: How They Compare

The easiest way to think about the distinction is:

SEO: Helps search engines find and rank your content.
AEO: Helps answer engines understand and use your content.

They are not replacements for each other. In fact, good AEO usually starts with good SEO: useful content, clear structure, strong technical foundations, and trustworthy information.

Dimension	Traditional SEO	Answer Engine Optimization (AEO)
Primary Platform	Google, Bing, Yahoo	ChatGPT, Perplexity, Google AI Overviews, Claude
User Experience	Scrolling lists of blue links and clicking websites	Reading a synthesized answer with source citation tags
Query Style	Keyword-centric ("best CRM small business")	Conversational questions ("What's the best CRM for a 10-person startup?")
Core Metric	SERP rankings, organic impressions, CTR	AI citation frequency, generative share of voice, direct conversions
Content Structure	Long-form articles optimized for keyword density	High-density declarative answers, bulleted facts, and structured schema

How Do You Optimize for AEO?

There isn't a magic "AEO button" you can toggle on. But you can start by mastering the fundamentals:

Answer real questions your customers ask: Pay attention to the exact language and questions your customers use in sales calls, support tickets, and community discussions.
Write clear, direct answers: Put the direct answer right at the top of your section before expanding into supporting context. If an AI engine cannot find the core answer immediately, it moves to another source.
Use descriptive headings and structured content: Organize your articles with clear H2 and H3 questions, bulleted lists, and clean comparison tables.
Explain concepts in simple language: Avoid dense marketing buzzwords or corporate jargon. Clear, factual statements are much easier for LLM chunkers to extract accurately.
Keep important information easy to find: Put key data points, pricing details, specifications, and steps front and center.
Build credibility with original data and expertise: AI engines prioritize reliable sources. Back your insights with original research, case study findings, and experienced perspectives.
Keep your website technically accessible: Ensure search engines and AI crawlers (like GPTBot and PerplexityBot) can index your pages, and provide clean Schema.org structured data (such as Article, FAQPage, and Product).

The Big Picture

The goal of AEO isn't to write robotic copy for AI bots.

The goal is to make your content so clear and useful that both humans and machines can understand it.

And that's ultimately what AEO is all about:

SEO helps people find your content. AEO helps answer engines understand and recommend it.

Code Is Cheap. Software Isn’t.

Neeraj Mukta — Sun, 20 Sep 2026 10:31:05 +0000

AI has made writing code incredibly cheap. But building software that can survive change, scale, and someone else’s bad decisions is still engineering.

A founder told me this while negotiating a contract.

His argument was simple:

“If we have AI to generate code, why should we pay for a developer’s hours?”

He said code had become cheap to write. He only wanted a working MVP. He didn’t care about code quality.

I hesitated.

And he didn’t sign the SOW.

At first, I thought it was a fair question.

Then the product engineer in me remembered the last project where we had to rebuild a broken app because the previous agency couldn’t maintain it.

Most of the code was AI-generated.

Random directory structures. Files and functions that didn’t quite match. Long, meaningless comments. Weird test cases. Logic scattered across the codebase with no obvious reason why.

While rebuilding it, we realized just how expensive bad code actually is.

And nobody understands this better than a burnt-out founder or a CTO who has inherited a codebase where every seemingly simple change turns into a mini archaeological expedition.

But from a founder’s perspective, all of this sounds like technical jargon.

Clean Code. System Design. Architecture. Domain language. TDD.

How do you explain the value of all that to someone who just wants the product shipped?

I tried to explain it like this:

AI has made generating code cheap. It hasn’t made building software cheap.

Writing a few thousand lines of code is easy.

Building a system where those thousands of lines continue to make sense six months later is a different problem.

It’s like building a house.

Having AI generate bricks faster doesn’t eliminate the need for a blueprint, structural design, foundations, plumbing, or someone who understands how the whole thing fits together.

The fundamentals of software engineering haven’t disappeared.

If anything, they matter more now.

Because the bottleneck has moved.

The most draining part of building with AI agents isn’t writing code anymore.

It’s keeping the agents in sync.

You need a shared system design.

A shared language for the product and its domain.

Clear boundaries around what each part of the system is supposed to do.

And increasingly, you need a leash.

That’s where practices like test-driven development become interesting in the age of AI agents.

Tests aren’t just there to catch bugs.

They become guardrails for agents that can otherwise happily run in ten different directions.

The irony is that AI can make a bad engineer dramatically faster at producing bad code.

It can also make a good engineer dramatically faster at building great software.

The difference isn’t the cost of generating the code.

The difference is who is responsible for the system.

Copilot DEVTO Strict Live Test 2026-09-03

Neeraj Mukta — Thu, 03 Sep 2026 03:28:29 +0000

DEVTO Strict Live Test

Testing strict live mode without fallback.

Bharat general elections 2024 and the paradox of success

Neeraj Mukta — Sun, 05 May 2024 13:00:04 +0000

I will be 28 years old by the end of this year i.e. 2024. And by no measure, do I consider myself a successful person. Success as we all know is a relative metric. For a poor beggar it is to beg a day enough to survive the day, for a rickshaw driver success is to make enough money to provide for the family, for an aspiring youth it is to get a job, for a corporate employee it is to become the boss, for the boss success is well to become a super boss and so on.

Do you see a pattern? Success gets redefined every time we achieve it and it’s like a never-ending path that we embark on from the moment we are born.

But, what is common between Bharat elections this year and the paradox of success?

Before, getting to the elections I would like to talk about the “Paradox of success”. Most of us believe that becoming successful will make us happy, and feel respected and loved by the people around us. To be honest it often does but success also entails ‘ENVY’. The very feeling that makes childhood friends writing an exam bitter when results are declared, despises the person doing well or working hard in life. Sometimes, you don’t even have to be successful to feel the bitterness and jealousy from such people around you just a little spark, a small step towards that path is enough. I know it exists because I’ve felt it throughout my school days, college days, and corporate journey and you must have too!

Too much or even too little success can break life-long friendships, and families, jeopardize your career, and make you a lonely person wondering what went wrong.

Trust me if you value or crave certain people in life, it’s better to avoid success or to hide it from them.

As we all hear that Bharat is a developing country, she is working hard to match global standards of living, healthcare, infrastructure, military & defense, manufacturing & services, etc.

Bharat is a nation aspiring to share the table with developed nations. A patriot (or a naive) person like me would think that nations sitting at the top will lend a hand and help us reach there. But is that the case? Who will benefit from having another developed nation on the earth? What does Bharat has to offer to the world? These are questions raised when someone talks about a developed and prosperous Bharat. Now, who might ask such questions? You can take a guess, someone who is envious and afraid of our progress. These people are present both inside and outside the Bharat.

It saddens me and at the same time makes me chuckle when I see rising hate for my nation. A nation that just wants to elevate its citizens. This hate only gets worse with time. When a 3rd world country filled with poor and snake charmers suddenly comes out and helps other nations during a pandemic. When it decides to take a stand for itself and push back the terrorism.

The propaganda and false narratives are at their peak against my nation. The attempts to tarnish Bharat’s achievement in the last 10 years are rampant. These attacks against our sovereignty are launched by both internal and external actors. What does it signify? Why a democratic country is constantly targeted by a dictator-run country or a deep state-run country?

I think the answer is simple, “Paradox of success” i.e. envy. Envy that Bharat might become better than them. Everyone loved Bharat when we were weak and poor. The moment we started walking the path of progress, that love started to fade, we were still too far so the hatred was hidden but it always existed. As we are getting closer and closer to our goals the fear and the jealousy among the peer nations are also peaking. Ladies and gentlemen, Bharat General Election 2024 is that crucial step that will catapult us to a new trajectory, and of course, some developed nations will not like it.

I don’t know the answer to this paradox or rather human nature of enviousness but my guess is it is all because of evolution and conditioning that life is a zero-sum game. I’m most certainly sure that it is not.

The lesson is simple:

"Every time someone sneers at you, tries to belittle you, just smile and tell yourself, “I’m most certainly on the right path to success & start running on that path.”

[React Native Guide 2024] Part 1: Builds and flavors.

Neeraj Mukta — Tue, 23 Apr 2024 04:10:06 +0000

“Before building an actual rocket, one should build a prototype. Before experimenting on the actual rocket, one should experiment on the prototype.” - not elon musk.

Update: react-native-config breaks with latesst react-native 0.74

Source code for the impatients.

Almost all of the web apps I have ever worked on had some sort of dev/prod parity setup. The larger teams and codebases even had more build types like local, QA, preprod etc. And it does make sense to separate out your main build from the one being actively developed. It is also in conjecture with 12 factor app philosophy.

In the mobile apps world, we follow something similar called build variants. If you’re not aware of it please read this blog first. It explains buildtypes and productflavors in detail. To put it in simple words. We have something called Build types, Product flavors cross product of the two gives us Build variants.

💡 BuildTypes * ProductFlavors = BuildVariants

The way it works in react native is also similar, we define buildTypes and productFlavor in app/build.gradle file. BuildTypes usually represent debug and release mode bundle whereas ProductFlavor is further divided into two more axis.
One axis is our environments like local, dev, qa, test, prod, etc. and the other one flavorDimensions, which is optional but useful in apps that have for ex. free and pro versions with almost similar code, or uber like separate apps for the riders and the drivers. You can enable flavors and write conditional code which gets built and compiled based on productflavors and flavorDimensions.

Now that we’re clear about build types and product flavors let’s set it up in a new RN project.

Step 1: Create a new RN project using React-native cli.

 npx react-native@0.73.6 init MyApp --version 0.73.6

Step 2: Install react-native-config package

cd MyApp **&&**  npm i react-native-config

Step 3: Define config for the build types, product Flavors in app/build.gradle.

Add the following lines in the same file in the defaultConfig block. This will be applied to all the

buildVarirants and we can also override these values.


 defaultConfig {
        resValue "string", "build_config_package", "com.myapp"
        resValue "string", "build_config_package", "com.myapp"
        applicationId "com.mmadmin"
        minSdkVersion rootProject.ext.minSdkVersion
        targetSdkVersion rootProject.ext.targetSdkVersion
        versionCode project.env.get("VERSION_CODE").toInteger()
        versionName project.env.get("VERSION_NAME")
 }

b. You’ll notice buildTypes already exists. You can add/edit the configuration related to the specific bundle for ex. enableHermes option or enable source map. We’ll leave it as it is for now.

buildTypes {
        debug {
            signingConfig signingConfigs.debug
        }
        release {
            // Caution! In production, you need to generate your own keystore file.
            // see https://reactnative.dev/docs/signed-apk-android.
            signingConfig signingConfigs.debug
            minifyEnabled enableProguardInReleaseBuilds
            proguardFiles getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro"
        }
    }

c. Let’s now define flavorDimensions and productFlavors. Since, we need only one app we will use default as flavorDismension. But we need 4 productFlavors local, dev, qa, and prod hence we add four blocks with some values. We’re overriding app_name and adding applicationIdSuffix and versionNameSuffix for each flavor. This will help us differentiate between apps and generate different buildVariants. Helps with testing on the same device or simulator.

flavorDimensions "default"
    productFlavors {
        local {
            resValue "string", "app_name", "MyApp Debug"
            applicationIdSuffix '.debug'
            versionNameSuffix "-DEBUG"
            minSdkVersion rootProject.ext.minSdkVersion
            targetSdkVersion rootProject.ext.targetSdkVersion

        }
        dev {
            resValue "string", "app_name", "MyApp Dev"
            applicationIdSuffix '.dev'
            versionNameSuffix "-DEV"+versionBuild
            minSdkVersion rootProject.ext.minSdkVersion
            applicationId "com.reactnativeproject.stage"
            targetSdkVersion rootProject.ext.targetSdkVersion

        }
        qa {
            resValue "string", "app_name", "MyApp Qa"
            applicationIdSuffix '.qa'
            versionNameSuffix "-QA"+versionBuild
            minSdkVersion rootProject.ext.minSdkVersion
            applicationId "com.reactnativeproject.stage"
            targetSdkVersion rootProject.ext.targetSdkVersion

        }
        prod {
           resValue "string", "app_name", "MyApp"
            minSdkVersion rootProject.ext.minSdkVersion
            applicationId "com.reactnativeproject.prod"
            targetSdkVersion rootProject.ext.targetSdkVersion

        }
    }

Step 4: Setup environments

Create your environment files like .env.local, .env.dev, .env.prod files and add the keys.
Update app/build.gradle file with the following code at the beginning of the file.


project.ext.envConfigFiles = [
        localdebug:".env.local",
        localrelease :".env.local",
        devdebug: ".env.dev",
        devrelease: ".env.dev",
        qadebug:'.env.qa',
        qarelease:'.env.qa',
        proddebug:'.env.prod',
        prodrelease:'.env.prod',
]

apply from: project(':react-native-config').projectDir.getPath() + "/dotenv.gradle"
def versionBuild = project.hasProperty('BUILD_NUMBER') ? "+" + project.findProperty('BUILD_NUMBER').toString() : "";

Notice how we have different combinations for buildTypes and productFlavors like productFlavorbuildTypes. So, every productFlavor has two buildTypes debug and release.

Important, thing here is to match the buildVaraint name with the correct .env file.

Now, we can access our variables inside the react components

import Config from 'react-native-config';

function HomeScreen({navigation}) {
  return (
    <View style={{flex: 1, justifyContent: 'center', alignItems: 'center'}}>
      <Text>Home screen</Text>
      <Text>
        _**ENVIROMENT:{Config.ENVIROMENT} ::: APP_ID:{Config.APP_ID}**_
      </Text>
      <Button
        title="Go to Details"
        onPress={() => navigation.navigate('Stack_Details')}
      />
    </View>
  );

We can also access them inside the build.gradle file ex.

versionCode project.env.get("VERSION_CODE").toInteger()

To access env variables inside android .java/.kt files

 URL url = new URL(BuildConfig.API_URL);

and inside iOS files

 //import header
#import "ReactNativeConfig.h"
// then read individual key like:
NSString *apiUrl = [ReactNativeConfig envFor:@"API_URL"];

Final Step: Update Package.json with build commands.

Now, we just need to update scripts to build and run different build variants of our app.

"scripts": {
    "android:local": "react-native run-android  --mode=localDebug",
    "android:dev":"react-native run-android  --mode=devDebug",
    "release": "cd android && .\\gradlew assembleProdRelease",
    "release-aab": "cd android && .\\gradlew bundleProdRelease",
    "release-dev": "cd android && .\\gradlew assembleDevRelease",
    "release-qa": "cd android && .\\gradlew assembleQaRelease",
    "cleanDeps": "rm -rf node_modules && npm i",
    "lint": "eslint .",
    "start": "react-native start",
    "test": "jest"
  },

scripts are modified to run on windows terminal.*

We can run the app locally with npm run android:local, we can generate .apk for prod, dev, qa with npm run release, npm run release-dev , npm run release-qa respectively.

And, we can generate .aab file for playstore submission with npm run release-aab.

Hey, I’m Neeraj Mukta I expertise in crafting resilient apps tailored for startups. I’ve been crafting web and mobile apps for 8+ years now. If you would like to chat or need assistance with technical problems, feel free to reach out on X, Linkedin.

Serving React app from S3 bucket using Cloudflare CDN

Neeraj Mukta — Wed, 20 Sep 2023 15:00:17 +0000

The most common way to deploy any static website today is, through AWS. Specifically, S3 bucket in combination with Certificate Manager and Cloudfront services. The combination of these AWS services works well and it's straightforward to set up. However, this may not be the best and easiest solution to host and serve a static website built with frameworks like React, Svelte, or Angular. The major issues in using this combination are:

Setup is not easy, configuring the bucket, then the certificate for SSL, and then creating Cloudfront distribution.
It becomes expensive as you have to pay for a bucket and CDN service and if you activate WAF that costs you extra. If you have a high-traffic website the costs can rise exponentially.
There are at least 3 network hops before it reaches the user. It may not add a significant delay but it's absolutely unnecessary.
There’s no DDoS mitigation system available by default unless we set it up by using another AWS service like AWS Shield or WAF.

In this article, we will look into an alternate way to serve your website securely with an inbuilt DDoS protection and Bot mitigation system. We will use S3 bucket as our primary storage for static files. We will then leverage Cloudflare infrastructure to proxy all the requests to the S3 bucket. By using Cloudflare we get the following advantages:

Easy to set up HTTPS with automatic SSL certificate generation and renewal for our website.
Low latency CDN network with caching enabled across the globe
Cost-effective when compared to the AWS system.

Implementation

The implementation process can be broken down into three steps.

Step 1: Deploy the static files to a S3 bucket

Assuming you already have a bucket endpoint ready, I will not explain this step in much detail. If you don’t have a bucket ready, follow this article to deploy your app to the bucket and enable static hosting.

Once, you have static hosting enabled in the bucket you’ll get an HTTP endpoint which you use to access your web app. Something like this [http://app.nrj.agency.s3-website.ap-south-1.amazonaws.com](http://app.nrj.agency.s3-website.ap-south-1.amazonaws.com/admin/default).

Step 2: Use CloudFlare name servers

Now, we need to delegate the authority to manage DNS records to Cloudflare. This step is fairly simple. You just need to replace the name server in your registrar dashboard with Cloudflare’s provided nameservers.

Create a CloudFlare account.
Click on Add site.
Copy name servers and paste them into your GoDaddy or whichever DNS provider you use.

Now, you can see all your DNS records in the CloudFlare dashboard. If any of the records are missing please, add them manually.

Step 3: Enable the proxy mode

If you already have a record pointing to your web app, you’ll notice it is also present in the DNS record list. I’m assuming the CNAME record value points to the CloudFront URL. You need to replace this with your bucket's endpoint from step 1. There’s a toggle to switch between a normal DNS record and a proxy. Turn it on, the cloud should become orange. This indicates that all the traffic to this subdomain is routed through the CloudFlare network. Remember to remove the HTTP prefix from the static site URL.

Note: You have to manage all your records through cloudflare now. Not all records need to be proxied through CloudFlare. You can add normal records just like you would in any other DNS provider.

Try visiting app.yourdomin.com, (app.nrj.agency in my case) you should see your React app deployed. Check the URL bar it should have an HTTPS protocol now. This is possible because Cloudflare encrypts the request between the browser and Cloudflare with its own SSL certificate.

Demo:

Conclusion

We were able to set up CDN for our S3 bucket in minimum steps. This method of serving content saves time, effort, and money. It also adds an extra layer of safety against common web attacks with zero configuration.

This method can be used with any similar hosted website be it on Azure or Google Cloud.

If you found this article helpful. Drop a like and stay tuned for more neat articles.

This article was published on Medium, Hashnode, Devto using Buzpen.

Deploy React App to AWS S3 bucket in under 5 mins

Neeraj Mukta — Tue, 19 Sep 2023 15:50:19 +0000

AWS is the leading Cloud service provider in the world. They offer a variety of services for deploying web applications at scale. These services offload a lot of work that was once required to take any application to production. Traditionally, companies used to have their own servers in their premises to serve their applications to their users. However, with the introduction of cloud-based services, this model has rapidly changed, and more and more companies have moved their infrastructure to the cloud.

Today, we will look into one such service from AWS called S3 buckets. S3 is shorthand for Simple storage service. It is a service that lets you store files and objects on the cloud.

From AWS website,

Amazon Simple Storage Service (Amazon S3) is an object storage service that offers industry-leading scalability, data availability, security, and performance. Customers of all sizes and industries can use Amazon S3 to store and protect any amount of data for a range of use cases, such as data lakes, websites, mobile applications, backup and restore, archive, enterprise applications, IoT devices, and big data analytics. Amazon S3 provides management features so that you can optimize, organize, and configure access to your data to meet your specific business, organizational, and compliance requirements.

Why should we use S3 bucket for static site hosting?

S3 is quite a popular service which is widely used all over the world. It is cheap, reliable, and straightforward to set up. It also has the option to enable static hosting on the bucket items.

Hence, S3 is quite popular when it comes to deploying SPAs.

Prerequisites

Before diving into the actual process let’s make sure we have the following things ready:

An AWS accoun
Static files or the build version or your app. (In most of the react apps it is the build directory)

Steps to deploy your app

Step 1: Search for the S3 bucket in the AWS console. Click on the Create Bucket button.

Step 2: Configure your bucket. Give a name to your bucket.

💡 It is important to note that the bucket name should match the sub domain/ domain name on which you would like this app to be served on. In my case, I’ve got a domain nrj.agency but I want to serve it on the app subdomain. So, I have named my bucket app.nrj.agency .

We have to make our bucket public so that users across the globe can access the files inside it. Acknowledge the warning. Now, the rest of the settings can be left to default.

Save the changes.

Now, you should be able to see the newly created bucket in the Buckets list.

Step 3: Upload Files. We can upload files manually by drag and drop or we can use AWS CLI to sync files to our bucket. We will manually put our build folder or the static files in the bucket.

Step 4: Set up a bucket policy. This step is crucial and required because it tells AWS that this service will be used only to read the objects from it.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::app.nrj.agency/*"
        }
    ]
}

Step 5: Enable static site hosting. In the permissions tab scroll to the bottom of the page. Click on the edit button to enable the static site hosting. Put index.html in both boxes as our SPA or react app will handle the errors.

That’s it you can see a URL generated by the AWS which you can use to access your app.

Demo:

💡 Notice it has HTTP, not HTTPS protocol. This is because S3 doesn’t support it. We need to set up other services to get an SSL certificate and serve it through CDN via HTTPS protocol.

Check out my other blog which tells you how to do this with CloudFlare CDN.

Conclusion

In this blog, we learned how to host static files using an S3 bucket in under 5 mins. All the steps described here can be followed easily.

If you found this article, give it a thumbs up and share with your friends.

This article was published on Medium, Devto, and Hashnode using Buzpen.

Setting up a reverse proxy with CloudFlare workers

Neeraj Mukta — Fri, 08 Sep 2023 23:21:09 +0000

What is a reverse proxy in the first place?

In layman's terms, it is a middleman sitting between two parties to make transactions between them smoother, faster, and more secure. Think of a waiter in a busy restaurant. The job of a waiter is to take orders from you and pass them to the kitchen staff and when your order is ready, serve the food from the kitchen to your table. As you can tell, you really don’t have to do much at a restaurant. All the hard work of communication and serving the food is handled by the waiter, here the waiter is acting as a middleman or reverse proxy between you and the chef.

If we apply this analogy to the digital world, a reverse proxy is a server between your clients (browser, mobile app etc.) and web servers. It can intercept the requests from the client before it reaches the server. This in turn opens a lot of opportunities for improving web server’s characteristics. Just as the waiter in a restaurant takes orders and serves food. It also takes care of billing and payments, managing multiple customers at the same time, managing crow during rush hours etc. A reverse proxy server can also do similar tasks in the internet world like balancing traffic between multiple servers, mitigating risky behaviors, and caching the responses for the same queries.

But, our goal for using a reverse proxy is different. We want to perform redirects between our websites. In this case, I’ve three websites

a. Main landing page which I want to point to kanvasai.com

b. Medium integration page which I want to point to kanvasai.com/medium followed by my app’s query parameters like _?utm_source=&page=_

C. Dev. to integration page again kanvasai.com/devtofollowed by my app’s query parameters like _?utm_source=&page=`_

For the sake of brevity all there websites are hosted on webflow.io and these are records on my GoDaddy DNS.

Notice, that I created three records (main, medium, devto) with CNAME pointing to a non-ssl server of webflow (Usually, we use `proxy-ssl.webflow.com). I'll explain later why.

This gives me three websites with three different subdomains under one domain.

💡 However, an interesting thing to note here is all the web crawlers and robots treat all these three websites as a different entity hence, this hurts the SEO significantly and results in a ranking drop.

So, how do we fix it such that when any crawler/user tries to access the

main.kanvasai.com gets redirected to kanvasai.com/
medium.kanvasai.com gets redirected to kanvasai.com/medium, and
devto.kanvasai.com gets redirected to kanvasai.com/devto

Let’s find out how CloudFlare workers can help

Workers are just javascript code running in Chrome browser environment. The good thing is that it runs closer to your user's browsers. The bad thing is that you cannot use node packages like in Serverless functions but all modern browsers APIs are supported. Read more about them here.

Disclaimer : This article assumes you know little bit about cloudflare workers and have tried building with it. So, basic stuff will be excluded and maybe hyperlinked to other blogs.

Note : If you’re going to apply this technique on production apps, please note that every CNAME record will be intercepted by worker, hence needs to be handled with correct worker logic for every route.

Prerequisite :

working CloudFlare account (free tier also works for this tutorial),
access to your domain registrar (in this case I’m using Godaddy but the process is the same for every other DNS providers),
Any code editor that supports JS/TS language features(I will use VS code),

Step 1 : Create a worker project with Cloudflare cli

Create a new worker project by running the following command in the terminal. website-stitcher is the project name

npm create cloudflare@2 -- website-stitcher

After running this command, CLI will create a directory named web-stitcher and you’ll be prompted through a series of questions,

choose hello world worker

b. Always say yes to typescript

c. git version control (you can do this later also)

d. Yes, deploy our sample worker.

After selecting ‘yes’, Cloudflare cli will try to log in to your Cloudflare account via browser. Authorize the authentication of cli with the account.

and Voila! we have our Cloudflare worker ready and deployed. (A browser window should open up automatically with the message ‘hello world’)

Now, we have a Cloudflare worker boilerplate code ready. Open it in your editor of choice. We don’t need to worry about all the files now. We’ll write all our logic in src/worker.ts file

Step 2: Write the logic to handle incoming requests and redirect its response

The fetch function has access to the request object which we will use to identify domains, subdomains, pathname, search params, etc. using the below snippet.

Let’s define our constants ROOT_DOMAIN, SUBDOMAINS, MAIN_SUBDOMAIN and main WEBSITE_URL.

Now, we need to write js/ts code to check the incoming hostname for subdomains and redirect it to sub- route. Something like this,

By looking at the test cases we can break down the logic into three main blocks

if the hostname is not the same as the ROOT_DOMAIN
- here, we need to check SUBDOMAINS if they match the hostname’s subdomain. If it matches one of the SUBDOMAINS we need to redirect the user to the right url.
- we should also check if it matches our MAIN_SUBDOMAIN and redirect the user to the main website
- If does not meet the above two conditions then just return data from the original request URL.

if the pathname matches one of the SUBDOMAINS and the hostname is the same as ROOT_DOMAIN
- here, we just need to fetch the data from the matching subdomain and redirect the user to the correct URL.

- or if there’s no subdomain or subroute, fetch data from **MAIN_DOMAIN** and return a response or redirect the user.

If the pathname has a trailing slash (important case)
- SEO crawlers treat kanvasai.com/medium and [kanvasi.com/medium/](http://kanvasi.com/medium/) as separate routes. Hence, we need to take care of thetrailing slash`. It’s easy with a bunch of js string methods.

It took some time and hit and trail to come up with logic and could be a little overwhelming to understand at once. Hence, I’m attaching a flow diagram to visualize the conditions.

If you prefer you can just copy and paste the same code change values of constants ROOT_DOMAIN, SUBDOMAINS, MAIN_SUBDOMAIN, and main MAIN_URL to your records.

The complete code looks like this

embed

Run the following command to deploy the code/worker

bash npx wrangler deploy

Head over to the Cloudflare dashboard > workers & pages. You should see list of all the workers here. I have multiple workers but if it’s a new account you should see just one worker.

Navigate inside your worker by clicking on it. You can see all relevant information related to your worker. There are tabs like triggers, logs, deployments, etc.

Next, we need to define the trigger for this worker. Right now, it is deployed to some random URL by Cloudflare.

Step 3: Register your site with Cloudflare zone

Before adding a trigger for our worker we need to delegate our DNS nameserver to the Cloudflare. (If your DNS registrar is Cloudflare you don’t need to do this step).

On the main dashboard, click Add Site button on the top right corner, and enter your domain name ex. kanvasai.com.

Now, follow the steps shown by Cloudflare for moving nameservers. This will allow Cloudflare to fetch all the existing DNS records. But, please make sure you have all the records present.

Adding albert.ns.clouflare.com and annabel.ns.cloudflare.com to my goDaddy domain DNS setting page.

Finish the site setup by clicking continue and check the DNS nameserver status. This may take some time to verify new nameservers. Important, thing to note here is now you have to manage all your DNS records from your Cloudflare account. Your DNS registrar will not have control over your records.’

Note : Make sure you have all the records available in the cloudflare DNS records too. In my case, my two records were not transferred so I had to add them again manually. This can cause downtime to your app so be careful while doing this transfer.

Step 4: Add your root domain as the worker’s trigger

Now, we are ready to add triggers to our workers. Navigate to your worker by clicking workers & pages on the left panel and then clicking on your worker from the list.

On this page, click on the Triggers tab next to Metrics. Here, click on the Add Custom Domain button and add your domain.

Note: you might see this error if you did not follow the last step correctly. In order to add your custom domain as a trigger for workers, your custom domain must be delegated to Cloudflare nameservers.(Don’t worry, your registrar will stay the same, GoDaddy in this case).

Cloudflare adds a new DNS record to type worker, you can check this to verify if your custom domain is set up correctly.

Step 5: Attach a wildcard route to your worker

Now, for our worker logic to run correctly we need to forward all the requests from all the sub domains to our worker. So, we’ll add a route for this we are going to use a wildcard () to define a pattern of URLs that are allowed or that trigger our worker. So, just below the custom domain, there is a section for routes (also called worker routes). I’ll add *.kanvasai.com/* as the route and choose kanvasi.com as the zone. This represents all the subdomains and subroutes that have kanvasi.com as the root domain.

we should see this message once the route is properly configured.

Now, we can already see the worker in action. Try visiting your root domain and subdomains.

If it's not working for you wait for some time to let DNS propagate changes. Try on a different device because Chrome caches the websites on disk.

Step 6: Handling www CNAME record :

There are a couple of ways to handle this,

We can add another CNAME record pointing to the same Cloudflare worker,
handle it in the worker code with JS or,
iii. Define a page rule such that anyone accessing www.kanvasai.com/* gets automatically redirected to https://kanvasai.com/*

Step 7: Handling relative URL (hrefs) in your applications

If your app uses an anchor tag and has subroutes, you should probably prefix those with subdomain names (/medium/about or /devto/about). You’ll understand why after trying it.

Step 8: SSL/TLS certificates between Cloudflare and your application server

For Vercel and similar applications, SSL is generated by the platform itself. Hence, we need full security

For Webflow, we keep it flexible and let Cloudflare manage SSL certificates.

Cons of this approach

Now, we’ll have to manage all our DNS records through Cloudflare.
Adding a new record becomes a little tricky.

In the follow-up article, we’ll see how to do this with SPAs. Please comment if you want a tutorial on that topic.

If you are trying to setup this reverse proxy and facing any issues, feel free to reach out or book a free consultation here. I’ll be more than happy to help.

This article was published using Buzpen. If you want to publish the same article to three major platforms at once, then do try out Buzpen.

Building an Android and iOS app in 2023

Neeraj Mukta — Wed, 06 Sep 2023 15:10:05 +0000

“Ideas are cheap, execution is expensive!”

I’m sure you must have heard this quote in some or the other form. A billion dollar ideas requires millions in investments before it turns profitable. The road to profitability is a tough one as we have seen in the recent few years with companies adapting all the means to save every buck.

So, the question is should you also spend millions and then start saving thousands to become profitable? I leave this question to be answered by you.

In the past few months I have met at least 10 founders (or wanna be founders) who have this startup or business idea that they think is amazing, has potential to disrupt the market and in turn make them rich. Of course, this was all in their heads and they were trying hard to pitch the idea and find a co founder who can help them build the product or service. And one common question they had was how expensive is it to build a product or service? Mind you all these people didn’t have a technical background and the only thing according to them that was stopping them was tech. The wild wild world of app development.

My goal through this article is to help you make right technological decisions to test your ideas. That’s right! Testing an idea is the first stage of any billion dollar company in making. You need to bet enough resources and time to validate your product idea, find early adopters and then do some serious analytics. Most of the founders make a mistake here, they go all in on the product development and marketing without even proper development and business plan. There are many steps involved before committing to full on development. (Maybe I’ll cover those in some other blog.)

💡 TIP 1: Save money by building something trivial but functional first that can help you validate the idea. It does not have to be an app or a website. It could be a simple spreadsheet also.

Most of the time they end up losing money and sometimes reputation too. You certainly don’t have to sell your house to validate your product idea.

Returning to the original question how much does it cost to build an MVP (minimal viable product)?

Well, the answer varies on the requirements of your MVP. Let’s assume you need an android or iOS app or both for your MVP or initial version. The effort in building any native mobile app from scratch is significantly high when compared to web apps. It takes around 100 hrs just to write basic building blocks of an native app and time increases based on complexity of business rules.

You can easily save time and effort by choosing a cross-platform technology like React Native. This helps you in jumpstarting the native app development with little knowledge on native languages like Java/Kotlin (used to build native android apps), Objective C/Swift (used to build native iOS apps).

💡 TIP 2: If you need an app for your idea, choose a cross platform technology to build it. This will help you build it faster, iterate over features quickly and roll out to users in shortest amount of time without burning a hole in your pocket.

Honestly, React native has become pretty good in 2023 and expo team has made it even easier for any javascript developer to build cross platform mobile apps. No matter what stage you are at as a company you should almost always bet on react native because it’s very stable and rapid to develop. If you’re just starting out or you are already at startup level you should save costs on technology by leveraging expo and react native ecosystem. If you google how to build a mobile app for android and iOS you will find tons of frameworks and technology to do it. But, broadly speaking there are two type of app development native and cross-platform, cross-platform being the quickest of the two.

💡 TIP 3: In 2023, you can use React native/Expo to build prototype apps as well as high traffic professional quality apps.

Let’s discuss a development plan where you want an app (android/ios) that users can use to find their morning ride to office. A social carpooling app. Now, before making this into a flow blown app something like the Uber and then launching it to your customers, what you should do first is to figure out if the users actually want to carpool with strangers in their area? Just ask around, interview people. Once, you are sure then you should test it by giving them an app.

For, this you can start with simple website that lists all the available cars from region A to region B in that city. Mobile devices are more common for such services so let’s focus on building the iOS and android app. Breaking down the requirements looks something like :

people signup into your app,
they share some identity like driver’s license and other relevant information,
they can view available car pools for today,
they can send a request to join a certain car pool,
and they have the an option to host a car themselves and approve new requests.

What I just did is to write down a high level overview of what app should do and this should be enough to validate our idea. As you can already see we need at least 5 screens already for our app. Imagine building these same screens separately on iOS and android & this will also need a backend. 😱 Thus, by using a cross platform framework like React Native or flutter we can save time and cost on app and maybe spend that time on building a robust server. Because at the end data is what matters in this century. So I’m picking expo for few simple reasons,

it’s open source & it’s based on Typescript and React,
it complies down to actual native code for both android and iOS unlike flutter,
it has relatively less steep learning curve, it’s easy to find devs or train React devs,
it has good support/libraries for camera, location, bluetooth etc, all the common native functionalities,
it is extensible meaning you can write custom native plugins if existing components or libraries are not suitable enough.

💡 Also, why not Flutter? will be answered in an separate post.

My next post will be on setting up a React Native app with expo. Stay tuned and follow me on whichever platform you are reading this.

PS: I provide free consultation on MVP Planning. I do a 1 on 1 session where we figure out the viability of your idea and how to bring it to life in most appropriate and quickest manner possible. If you are struggling with making right technological choice for your Product feel free to reach out. You can book free consultation here.

This article was publish on medium, devto and hasnode using buzpen.