DEV Community: Illia Pantsyr

When to use Cloudflare Workers for Edge Processing

Illia Pantsyr — Tue, 13 Jan 2026 17:15:35 +0000

Not every request needs to hit your backend. Some operations—metadata extraction, URL validation, lightweight transformations—are better served at the edge, closer to your users. Cloudflare Workers provide a compelling platform for these use cases, but knowing when to reach for them (and when not to) is the real skill.

In this article, I'll share a decision framework for edge computing based on my experience building services at Allscreenshots, where we use Workers for link preview metadata extraction while keeping heavier operations in our main backend.

What Are Cloudflare Workers?

Cloudflare Workers are serverless functions that run on Cloudflare's global edge network—over 300 data centers worldwide. Unlike traditional serverless (AWS Lambda, Google Cloud Functions), Workers execute at the edge, meaning your code runs in the data center closest to each user.

Key characteristics:

No cold starts: V8 isolates spin up in under 5ms
Global by default: Deployed to all edge locations automatically
Lightweight runtime: JavaScript/TypeScript with Web APIs (fetch, crypto, streams)
Request-based pricing: Pay per invocation, not per server

The Decision Framework

Before moving functionality to the edge, ask these questions:

Move to the Edge When:

1. The operation is stateless

Edge functions excel at request-in, response-out operations. If you need to read from or write to a database, you're adding latency that negates edge benefits.

Good fit: Parse HTML and extract meta tags
Poor fit: Look up user preferences from PostgreSQL

2. Latency matters more than compute power

Edge locations have limited CPU time (typically 10-50ms for free tiers, more for paid). If your operation is lightweight but latency-sensitive, edge wins.

Good fit: Validate and normalize a URL
Poor fit: Generate a PDF report

3. You need geographic distribution without managing infrastructure

Deploying to 300+ locations manually is impractical. Edge platforms handle this automatically.

Good fit: Serve different content based on user location
Poor fit: Run a long-lived WebSocket server

4. The workload is read-heavy and cacheable

Edge computing pairs well with CDN caching. Compute once, cache at the edge, serve many.

Good fit: Transform and cache API responses
Poor fit: Process unique, non-cacheable data per request

Keep in Your Backend When:

You need persistent connections (databases, WebSockets)
Operations are CPU-intensive (image processing, ML inference)
You require more than a few seconds of execution time
The operation needs access to your internal services
State management is complex

Common Edge Use Cases

1. Metadata Extraction

Fetching a URL and parsing its HTML for Open Graph tags, Twitter Cards, or structured data. The operation is stateless, involves network I/O to external sites, and benefits from being geographically close to both the user and target server.

2. Request Validation and Transformation

Validating API requests, normalizing URLs, or transforming payloads before they reach your backend. Reject bad requests at the edge before they consume backend resources.

// Example: URL normalization at the edge
function normalizeUrl(input: string): string {
  let url = input.trim().toLowerCase();

  if (!url.startsWith('http://') && !url.startsWith('https://')) {
    url = 'https://' + url;
  }

  // Remove trailing slashes, normalize www, etc.
  const parsed = new URL(url);
  return parsed.origin + parsed.pathname.replace(/\/+$/, '');
}

3. API Response Shaping

Your backend returns verbose JSON, but mobile clients need a slim payload. Transform at the edge:

// Backend returns full user object
// Edge returns only what the client needs
function shapeResponse(fullResponse: FullUser): SlimUser {
  return {
    id: fullResponse.id,
    name: fullResponse.display_name,
    avatar: fullResponse.profile.avatar_url
  };
}

4. A/B Testing and Feature Flags

Route requests to different backends or modify responses based on cookies, headers, or random assignment—all without touching your application code.

5. Authentication Token Validation

Validate JWTs at the edge before requests reach your backend. Invalid tokens never consume backend resources.

// Pseudo-code for JWT validation at edge
async function validateToken(request: Request): Promise<Response> {
  const token = request.headers.get('Authorization')?.replace('Bearer ', '');

  if (!token || !isValidJwt(token)) {
    return new Response('Unauthorized', { status: 401 });
  }

  // Token valid, forward to backend
  return fetch(request);
}

Architecture Pattern: Edge + Backend

The pattern that works well: edge for preprocessing, backend for heavy lifting.

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   Client    │────▶│    Edge     │────▶│   Backend   │
│             │     │   Worker    │     │             │
└─────────────┘     └─────────────┘     └─────────────┘
                          │
                    ┌─────┴─────┐
                    │           │
              Stateless    Lightweight
              operations   transforms

At the edge:

Validate requests
Extract metadata from external URLs
Transform/filter responses
Handle CORS
Cache static computations

In the backend:

Database operations
File storage
Job queues and async processing
Browser automation
Business logic requiring state

Trade-offs to Consider

Bundle size matters: Workers have size limits. Heavy libraries may not fit or may blow your CPU budget. Prefer lightweight, purpose-built code.

No traditional debugging: You can't attach a debugger. Rely on logging, Cloudflare's dashboard, and local development with Wrangler.

Limited execution time: Workers have CPU time limits (10-50ms on free tier, higher on paid). Long-running operations don't fit.

Statelessness is strict: No filesystem, no persistent memory between requests. Need state? Use Cloudflare KV, Durable Objects, or call your backend.

Vendor lock-in: Workers use Web APIs but have Cloudflare-specific features. Porting to another platform requires some rewriting.

When NOT to Use Workers

I've seen teams move everything to the edge and regret it. Avoid Workers for:

Database-heavy operations: Every DB call adds latency. If you're making 5+ queries, keep it in your backend near the database.
CPU-intensive processing: Image resizing, video transcoding, ML inference—these need more compute than edge provides.
Complex orchestration: Multi-step workflows with error handling and retries belong in your backend.
Operations requiring secrets rotation: While Workers support secrets, complex credential management is easier in traditional backends.

Performance Expectations

Typical characteristics for well-designed Workers:

Metric	Typical Value
Worker execution time	1-10ms (excluding external fetches)
Cold start	<5ms
Total latency	Dominated by external API calls
Bundle size target	<1MB (smaller is better)

The worker itself is rarely the bottleneck. External network calls dominate response time.

Getting Started

Cloudflare's Wrangler CLI makes deployment straightforward:

# Install
npm install -g wrangler

# Create project
wrangler init my-worker

# Develop locally
wrangler dev

# Deploy globally
wrangler deploy

Your code deploys to 300+ locations in seconds. No regions to configure, no scaling to manage.

Conclusion

Cloudflare Workers shine for stateless, latency-sensitive operations that benefit from geographic distribution:

Metadata extraction
Request validation and transformation
API response shaping
A/B testing and feature flags
Token validation

Before moving functionality to the edge, verify it's truly stateless and lightweight. The edge isn't a replacement for your backend—it's a complement that handles the quick stuff so your backend can focus on what it does best.

Start with one simple use case, measure the impact, and expand from there.

How to Convert JSON to TOON: 4 Methods Compared

Illia Pantsyr — Mon, 08 Dec 2025 22:48:38 +0000

JSON works fine for APIs, but it's inefficient for LLM inputs. Every repeated key, every bracket, every quote consumes tokens. TOON (Token-Oriented Object Notation) reduces token usage by 30-60% while preserving the exact same data structure.

This guide covers four ways to convert JSON to TOON, from code libraries to desktop apps, so you can pick the right tool for your workflow.

What Is TOON?

TOON is a data serialization format designed specifically for LLM inputs. It uses YAML-like indentation for nested structures and CSV-style rows for uniform arrays, eliminating redundant syntax while remaining human-readable.

JSON (51 tokens):

{
  "users": [
    { "id": 1, "name": "Alice", "role": "admin" },
    { "id": 2, "name": "Bob", "role": "user" }
  ]
}

TOON (24 tokens):

users[2]{id,name,role}:
  1,Alice,admin
  2,Bob,user

Same data. Half the tokens. The schema is declared once in the header, then each row contains only values—no repeated keys, no brackets, no quotes around simple strings.

Method 1: Code Libraries

Use this when you're building software that sends data to LLMs.

TOON has official implementations for JavaScript, Python, Java, Julia, and Rust, plus community libraries for 15+ other languages including Go, PHP, Ruby, Swift, Kotlin, C++, Elixir, and R. Check the official TOON repository for the full list.

Here are examples for the two most common languages:

JavaScript/TypeScript

Install the official package:

npm install @toon-format/toon

Convert JSON to TOON:

import { encode, decode } from '@toon-format/toon';

const data = {
  users: [
    { id: 1, name: 'Alice', role: 'admin' },
    { id: 2, name: 'Bob', role: 'user' }
  ]
};

const toon = encode(data);
// users[2]{id,name,role}:
//   1,Alice,admin
//   2,Bob,user

const restored = decode(toon); // Back to JSON

Python

pip install toon-llm

from toon_llm import ToonSerializer

data = {
    "users": [
        {"id": 1, "name": "Alice", "role": "admin"},
        {"id": 2, "name": "Bob", "role": "user"}
    ]
}

toon_string = ToonSerializer.serialize(data)

When to use: You're building an application that sends data to LLMs and want to convert programmatically before each API call.

Method 2: Command Line

Best for quick one-off conversions, shell scripts, or piping data between tools.

The official CLI auto-detects format from file extensions:

# JSON to TOON
npx @toon-format/cli data.json -o data.toon

# TOON to JSON
npx @toon-format/cli data.toon -o output.json

# Pipe from stdin
cat api-response.json | npx @toon-format/cli > optimized.toon

# Show token savings
npx @toon-format/cli data.json --stats

When to use: You have JSON files on disk and want to convert them without writing code. Good for scripting and automation.

Method 3: Online Converters

Best for quick tests with non-sensitive data.

Several browser-based tools exist:

toonformat.dev/playground — Official TOON playground with token comparison
toontools.vercel.app — Simple converter interface

All process data in-browser (client-side JavaScript), so data technically doesn't hit their servers. But you're still loading external scripts, and there's no way to verify what happens with your input.

When to use: Testing TOON syntax with sample data. Avoid for anything containing API keys, user data, or proprietary information.

Method 4: Desktop Apps (Offline)

Best for sensitive data, air-gapped environments, or developers who want a permanent tool.

PrimeUtils is a macOS toolkit with 100+ developer utilities, including a TOON converter that works entirely offline. No network calls, no external dependencies—your data never leaves your machine.

What sets it apart:

True offline operation — Works without internet. Verify with Little Snitch or a packet sniffer if you're skeptical.
Multi-format support — Convert JSON, YAML, XML, or CSV to TOON directly. No need to convert to JSON first.
Bidirectional — TOON back to any supported format with one click.
Part of a larger toolkit — JWT debugger, Base64 encoder, hash generators, regex tester, and 100+ other utilities in one app.

The workflow is straightforward: select your input format, paste or load your data, click Convert. Output appears instantly with a copy button.

When to use: You're working with production data, client information, or anything you can't paste into a web form. Also useful if you regularly switch between JSON, YAML, and other formats.

PrimeUtils is a paid app (one-time purchase), with a demo version available to test core features.

When TOON Doesn't Help

TOON isn't universally better than JSON. Skip it when:

Data is deeply nested with non-uniform structures — TOON's efficiency comes from tabular arrays. Complex nested configs may actually use more tokens.
Arrays have inconsistent schemas — If objects in an array have different fields, TOON can't use its compact row format.
You need pure tabular data — For flat tables with no nesting, CSV is 5-10% smaller than TOON.
Latency matters more than tokens — Serialization adds overhead. For real-time applications, benchmark both formats.

TOON's sweet spot: uniform arrays of objects with consistent fields across hundreds or thousands of rows.

Quick Comparison

Method	Best For	Offline	Multi-Format
Code Libraries	Automated pipelines	Yes	No (JSON only)
CLI	Scripts, one-off files	Yes	No (JSON only)
Online Tools	Quick tests	No	No
PrimeUtils	Sensitive data, daily use	Yes	Yes (JSON, YAML, XML, CSV)

Conclusion

Converting JSON to TOON is straightforward regardless of which method you choose. The right tool depends on your workflow:

Building an app? Use the code libraries.
Scripting? Use the CLI.
Quick test? Online converters work.
Sensitive data or multi-format needs? A desktop tool like PrimeUtils keeps everything local.

Start with whatever matches your current task. The 30-60% token savings compound quickly when you're making thousands of LLM API calls.

Class loaders in JVM: An Overview

Illia Pantsyr — Sun, 05 Nov 2023 12:05:17 +0000

Class loaders are an essential part of the Java Virtual Machine (JVM), but many developers consider them to be mysterious. This article aims to demystify the subject by providing a basic understanding of how class loading works in the JVM.

What are classloaders

In the Java Virtual Machine (JVM), classes are loaded dynamically and found through a process called class loading. Class loading is the process of loading a class from its binary representation (usually a .class file) into memory so that it can be executed by the JVM. This is where we need classloaders. Class loaders are used to load .class file into the memory.

How classes are loaded in JVM

Classes are loaded in 3 steps:

Creation and Loading step. First thing that happens is loading a class file using a class loader. There are two kinds of class loaders: the bootstrap class loader supplied by the JVM, and user-defined class loaders. (More details about class loaders are in the next chapter) Then, instance of java.lang.Class class is created. What makes the class available to the JVM for further execution A detailed step-by-step algorithm can be found in the Java Virtual Machine specification.
Linking step
Before the class is ready for execution, the JVM needs to perform a number of preparatory operations, which include verification and preparation of the class for execution.
Linking steps are following:
1. Bytecode verification.
Verification ensures that the binary representation of a class or interface is structurally correct and is not corrupted, otherwise the class file will not be linked and a VerifyError error will be thrown. Verification can be turned off by the -noverify option. Turning off the verification can speed up the startup of the JVM, but disabling bytecode verification undermines Java's safety and security guarantees. Why not to disable bytecode verification.
1. Preparation.
Allocate RAM for static fields and initialize them with default values.
1. Resolution of symbolic links.
Since all references to fields, methods, and other classes are symbolic. JVM, in order to execute the class, you need to translate the references into internal representations.
Initialization step.

After a class is successfully loaded and linked, it can be initialized. At this stage, the static class initializers or static variable initializers are called, which ensures that static initialization block is executed only once and static variables are initialized correctly.

Also, it is worth remembering that Java implements delayed (or lazy) loading of classes. This means that class loading of reference fields of the loaded class will not be performed until the application explicitly refers to them. In other words, character reference resolution is optional and does not happen by default.

Class loader features

Class loaders has three important features that is worth to remember.

Delegation model

When requested to find a class or resource, a class loader will delegate the search for the class or resource to its parent class loader before attempting to find the class or resource itself.

Visibility

Classes loaded by a parent class loader are visible to its child class loaders, but classes loaded by a child class loader are not visible to its parent class loaders or children.

Uniqueness

In Java a class is uniquely identified using ClassLoader + Class as the same class may be loaded by two different class loaders.
Class A loaded by ClassLoader A != Class A loaded by ClassLoader B
It is helpful for defining different protection and access policies for different classloaders.

Class loaders relationship

We should remember that classes in Java are loaded on demand. That is, class is loaded only when is requested to.

As you know, the entry point of every program written in Java is public static void main(String[] args) method. Main method is the place where the very first class is loaded. All the subsequently loaded classes are loaded by the classes, which are already loaded and running.

When a class is requested by the running program, the System class loader searches for it in the application classpath. If the class is not found, the Platform class loader is searched, and if still not found, the Bootstrap class loader is searched.

If the requested class is found in a parent class loader, it is loaded by that class loader. If not, the System class loader loads the class. If the class has not been loaded before, the class loader loads it into memory and creates a new instance of the Class object that represents the loaded class.

It is important to note that the class loading hierarchy is hierarchical in nature, with each class loader having a parent class loader. This parent-child relationship ensures that each class loader is responsible for loading only its own classes and delegates the loading of parent classes to its parent class loader.

Different types of classloaders

The class loading mechanist in JVM doesn't use only one class loader. Every Java program has at least three class loaders:

Bootstrap (Primordial) class loader

This is the root class loader and is responsible for loading core Java classes such as java.lang.Object and other classes in the Java standard library (also known as the Java Runtime Environment or JRE). It is implemented in native code and is part of the JVM itself. Althrough each class loader has its own ClassLoader object, there is not such object corresponding to the Bootstrap Class Loader. For example, if you would run this line of code
String.class.getClassLoader(), you would get null.

Extension class loader

This class loader is responsible for loading classes from the extension directories (such as the jre/lib/ext directory in the JRE installation) and is child of Bootstrap Class Loader. You can also specify the locations of the extension directories via the java.ext.dirs system property.

System (Application) class loader

This is the class loader that loads application-specific classes, usually from the classpath specified when running the Java application. The classpath can include directories, JAR files, and other resources. The classpath can be set using the CLASSPATH environment variable, the -classpath or -cp command-line option. The System/Application Class Loader is also implemented in Java and is a child of the Extension Class Loader.

Class loaders and related to them changes over time

In the previous section, we've seen class loaders hierarchy that was in Java until Java 9 revised that.

New class loaders hierarchy since Java 9 looks like this:

Bootstrap (Primordial) class loader

This is the root class loader and is responsible for loading core Java classes such as java.lang.Object and other classes in the Java standard library (also known as the Java Runtime Environment or JRE). It is implemented in native code and is part of the JVM itself. Althrough each class loader has its own ClassLoader object, there is not such object corresponding to the Bootstrap class loader and, typically represented as null, and doesn't have a parent. For example, if you would run this line of code
String.class.getClassLoader(), you would get null.

Platform class loader (former Extension class loader)

All classes in the Java SE Platform are guaranteed to be visible though the Platform class loader. Just because a class is visible through the platform class loader does not mean the class is actually defined by the platform class loader. Some classes in the Java SE Platform are defined by the platform class loader while others are defined by the Bootstrap class loader. Applications should not depend on which class loader defines which platform class.

System (Application) class loader

This is the class loader that loads application-specific classes, usually from the classpath specified when running the Java application. The classpath can include directories, JAR files, and other resources. The classpath can be set using the CLASSPATH environment variable, the -classpath or -cp command-line option. The System/Application class loader is also implemented in Java and is a child of the Extension class loader.

There are even more changes that were introduced in Java 9 which are related to class loaders, namely:

The Application class loader is no longer an instance of URLClassLoader but, rather, of an internal class. Now, there are ClassLoaders class that contains in itself implementation of 3 built-in class loaders. Such as:
1. BootClassLoader
2. PlatformClassLoader
3. AppClassLoader
  - However, bootstrap class loader should be used via BootLoader class and not via ClassLoaders class.
The Extension class loader has been renamed to Platform class loader. Substantial difference between Java 8 Extension class loader and Java 9 Platform class loader is that Platform class loader is no longer instance of URLClassLoader. But for the most part, the platform class loader is the equivalent of what used to known as the Extension class loader. One motivation for renaming it, is that extension mechanism has been removed, which we will discuss in the next paragraph.
Removed Extension Mechanism In releases before Java 9, the extension mechanism allowed the runtime environment to find and load extension classes without explicitly mentioning them on the classpath. However, in JDK 9, this mechanism has been removed. To use extension classes, ensure that their JAR files are included in the classpath.
Removed rt.jar and tools.jar
- rt.jar contains all of the compiled class files for the base Java Runtime environment.
- tools.jar contains all tools that are needed by a JDK but not a JRE (javac, javadoc, javap).

Resources

https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-5.html
https://www.artima.com/insidejvm/ed2/securityP.html
https://blogs.oracle.com/javamagazine/post/how-the-jvm-locates-loads-and-runs-libraries
https://docs.oracle.com/javase/9/docs/api/java/lang/ClassLoader.html

Datafaker 2.0

Illia Pantsyr — Sun, 05 Nov 2023 12:01:34 +0000

One of the major changes in Datafaker 2.0 is the requirement for Java version 17 as a minimum, similar to popular frameworks such as Spring Boot 3.0. This release of Datafaker brings significant improvements to the library's performance, support of Java Records, capability to generate larger amounts of test data, and much more.

Schemas and transformers

The most common use case for Datafaker is to generate random readable values in Java, such as firstnames, quotes or other values.

But what if you need to generate data in some other format, such as JSON or CSV?
For this purpose, Datafaker has a Schema and Transformer concept which work hand in hand and should therefore be used together.

Let's take a look at what this Schema and Transformer are and what role they play.

A Schema is a set of rules that describe what needs to be done to convert data from a Datafaker format to one of the supported formats. One of the main advantages of a schema is that the same schema can be used to convert to different formats.

In Datafaker, each format has its own Transformer implementation. At the time of writing, Datafaker supports 6 formats, which means there are also 6 Transformer implementations, namely:
⁃ CSV (CsvTransformer)
⁃ JSON (JsonTrasformer)
⁃ SQL (SqlTransformer)
⁃ YAML (YamlTransformer)
⁃ XML (XmlTransformer)
⁃ Java Object (JavaObjectTransformer)

Let's take a closer look at one of the formats, in this case, the CSV format.

Generating CSV files

When working with CSV files, there may be times when you need to create CSV files with data, for example for testing purposes. Manually entering data into a CSV file can be a tedious and time-consuming process. Instead of wasting time and effort on manual data entry, you can use a tool like Datafaker to quickly generate as much fake data as you need in a CSV format. Datafaker allows you to specify the number of rows and columns you need, and generate randomized data that can be easily exported to a CSV file. This can be especially useful when working with large datasets or when testing and prototyping your applications.

Let's look at an example:

Faker faker = new Faker(Locale.GERMANY); // Datafaker supports any locale from the Locale package
Schema<Object, ?> schema = Schema.of( // Define a schema, which we can use in any Transformer
    field("firstName", () -> faker.name().firstName()),
    field("lastName", () -> faker.name().lastName()),
    field("phoneNumber", () -> faker.phoneNumber().phoneNumberInternational()));

CsvTransformer<Object> csvTransformer = CsvTransformer.builder().build(); // Instantiate CsvTransformer using the appropriate builder.
System.out.println(csvTransformer.generate(schema, 5)); // This is where the magic happens. Call the `generate` method on the transformer with your schema plus the number of records to get the result as a string.

A possible result that can be obtained by executing the code above can be found below:

"firstName";"lastName";"phoneNumber"
"Jannik";"Ripken";"+49 9924 780126"
"Frederike";"Birkemeyer";"+49 2933 945975"
"Michelle";"Steuk";"+49 7033 814683"
"Ellen";"Semisch";"+49 9537 991422"
"Oskar";"Habel";"+49 3626 169891"

The CsvTransformer builder also gives you several parameters to use, such as:

quote(), in case you want to change the default(") quote.
separator(), the character which delimits columns in rows.
header() boolean parameter which toggles the generation of the header in the resulted CSV.

All other 5 formats work on the same principle, except for the Java Object format.

Let's see what is so special about this Java Object transformation.

JavaObjectTransformer

JavaObjectTransformer is available since version 1.8.0 of Datafaker. This was further enhanced in Datafaker 2.0 by providing support for Java Records in the JavaObjectTransformer.

In total, we have two ways to work with the JavaObjectTransformer:

1) Use JavaObjectTransformer and Schema.
2) Use a predefined Schema.

JavaObjectTransformer with Transformer and Schema pair

Let's take a closer look at each option. The first way to use it is through the familiar Transformer and Schema pair. Let's look at a practical example:

Note that we use Java 17 and Datafaker 2.0. Therefore, we will create a Client Java Record with 3 properties:

public record Client(String firstName, String lastName, String phoneNumber) { }

Next, we need to provide the Schema for our class.

Faker faker = new Faker();
JavaObjectTransformer jTransformer = new JavaObjectTransformer();

Schema<Object, ?> schema = Schema.of(
    field("firstName", () -> faker.name().firstName()),
    field("lastName", () -> faker.name().lastName()),
    field("phoneNumber", () -> faker.phoneNumber().phoneNumberInternational())
);
System.out.println(jTransformer.apply(Client.class, schema));

The result of our program will be as follows:
Client{firstName='Elton', lastName='Conroy', phoneNumber='+1 808-239-0480'}

JavaObjectTransformer with Transformer and predefined Schema

Let's take a look at the second use case, namely, populating Java objects with a predefined schema.
The essence of this approach is to override the schema and use it without explicitly specifying it every time.

Let's move on to a practical example:

First of all, we need to define our schema for our model. It is defined as follows and, on my machine, located in the com.datafaker package in the DatafakerSchema class:

public static Schema<Object, ?> defaultSchema() {
    var faker = new Faker(Locale.UK, new RandomService(new Random(1)));
    return Schema.of(
        field("firstName", () -> faker.name().firstName()),
        field("lastName", () -> faker.name().lastName()),
        field("phoneNumber", () -> faker.phoneNumber().phoneNumberInternational())
    );
}

Then you should provide a class to be used as a template for generated objects. This class should be annotated with the @FakeForSchema annotation with the path to the schema method as a value.

Note: If the default schema and the class template are in the same class, you can omit the full path to the method and use only the method name.

@FakeForSchema("com.datafaker.DatafakerSchema#defaultSchema")
public record Client(String firstName, String lastName, String phoneNumber) { }

Then you can use net.datafaker.providers.base.BaseFaker.populate(java.lang.Class<T>) to populate the object with the default predefined schema.

Client client = BaseFaker.populate(Client.class);

Alternatively, you can use net.datafaker.providers.base.BaseFaker.populate(java.lang.Class<T>, net.datafaker.schema.Schema<java.lang.Object, ?>) to populate the object with a custom schema:

Client client = BaseFaker.populate(Client.class, Schema.of(
    field("firstName", () -> faker.name().firstName()),
    field("lastName", () -> faker.name().lastName()),
    field("phoneNumber", () -> faker.phoneNumber().phoneNumberInternational())
));

The result of both populate methods will be the same:
Client{firstName='Darrel', lastName='Bogisich', phoneNumber='+44 161-444-6889'}

If you want to know more, you can find more information about Schema and Transformers in the official documentation of Datafaker.

Sequences

Sequences are a very powerful but undervalued feature of Datafaker. Imagine a situation where you need just a java.util.List of random values or you need to have an infinite stream of random data. In such situations, Datafaker sequences are a great fit. But before you start using it, it's good to know the details of sequences and their types, and that's what we're going to do.

Datafaker supports two types of fake sequences:

FakeCollection
FakeStream

FakeCollection is used to generate an in-memory list of fake values. Let's take a look at a practical example:

Faker faker = new Faker();
List<String> names =
    faker.collection(
        () -> faker.name().fullName(),
        () -> faker.address().city())
    .len(2, 6)
    .generate();

System.out.println(names);

This code example will generate a List of fake values, where each element will either be a full name or a city, with a length between 2 and 6 elements. This is a possible result of the code above:

[Pete Nienow, Erik Kub, New Jerrie, Tempie Erdman]

FakeStream is used to generate a java.util.stream.Stream of fake values. FakeStream is similar to FakeCollection, however, there are some important differences. For example, FakeStream can be infinite and the result of the FakeStream is a Stream object with generated values instead of a collection.

Imagine you need to model a constant stream of data. For example, the temperature from an IoT temperature sensor. In this case, FakeStream will be the right choice. Let's see how to write this in code:

Faker faker = new Faker();
Stream<Object> objects =
    faker.<Object>stream(() -> faker.random().nextDouble(20, 22))
        .generate();
objects.forEach(System.out::println);

This code will generate a constant stream of doubles between 20 and 22. However, it's also possible to specify the length of the stream via the len(int minLength, int maxLength) or len(int length) parameter.

Faker faker = new Faker();
Stream<Object> objects =
    faker.<Object>stream(() -> faker.random().nextDouble(20, 22))
        .len(3, 5)
        .generate();
objects.forEach(System.out::println);

The possible result may be: 21.663129306577716 20.228104917791825 20.559417738876828

Conclusion

In conclusion, Datafaker 2.0 is a significant upgrade to an already impressive data generation library. With its diverse data generation options and improved scalability, Datafaker 2.0 is an essential tool for developers looking to generate realistic and diverse data for testing and development purposes. For more information, head over to Datafaker documentation. and don't forget to star Datafaker on the GitHub!