They aren't necessarily saying your UI is janky. What they might mean is: "I clicked on a button and nothing happened for a while."

Here, the culprit could be slow APIs, worsened by network latency or connectivity issues. And when the UI does not respond immediately, the app feels broken, even if it is not.

This is the realm of perceived performance: how fast our app feels, regardless of how fast it is.

Imagine user taps a button and sees a blank screen with a spinner for 1.5 seconds. That is enough for them to feel something is wrong. But maybe the API was just taking its sweet time. Or maybe... we refetched data unnecessarily. In most cases API is not even the problem. the problem lies in how we used this API in our app.

The Hidden Cost of Slow APIs

Assuming the below user journey.
1. User lands on customer customer page
2. CustomerList API returns the response in 2 sec(it needs to aggregate data from different microservices etc)
3. User sees a spinner on this page for 2 sec or more.
4. User clicks on customer item
5. Customer details are loaded
6. User clicks back and then the spinner shows again

If the app always shows a loading spinner even when the user is revisiting the same screen within seconds, it feels broken, even though it is technically working as intended. This constant refetching of data will make our UI feel sluggish.

So, what can we do in this scenario?

Instead of fetching the customer list from scratch every time, we can cache the data once it is loaded the first time. When the user navigates back, we can immediately display the cached list and silently revalidate it in the background if needed. This approach avoids unnecessary spinners, maintains a smooth experience, and helps the app feel far more responsive, even if the underlying APIs are still slow.

Caching to the Rescue

We can reduce this "waiting time" by using simple in-memory caching

Step 1: Basic Fetch

useEffect(() => {
  fetch('/api/user')
    .then(res => res.json())
    .then(setUser);
}, []);

This works, but fetches fresh data every time the component mounts. Even if the data hasn't changed.

Step 2: Add a Manual Cache

useEffect(() => {
  fetchWithCache('user', '/api/user').then(setUser);
}, []);

This shows cached data immediately if available. Huge win for perceived speed

Step 3: Implement Stale-While-Revalidate(SWR)

useEffect(() => {
  const cached = cache.get('user');
  if (cached) setUser(cached);

  fetch('/api/user')
    .then(res => res.json())
    .then(data => {
      cache.set('user', data);
      setUser(data);
    });
}, []);

This pattern shows old data immediately, while updating it silently in the background. To the user, it feels blazing fast.

Scaling This: Write a Custom Hook

While the manual SWR logic is great for one off cases, maintaining this pattern across multiple APIs can quickly get out of hand. Rewriting cache checks, fetch logic, and background updates in every component is repetitive and error-prone.

A better approach is to extract this into a reusable hook, say useCachedFetch, which encapsulates the caching logic and ensures consistency across the app. It can:

• Accept a cache key and URL

• Return cached data immediately

• Trigger background refetch

• Optionally expose metadata like last updated time or fetch status

This gives us all the perceived performance benefits while keeping components clean and declarative.

const cache = new Map();

const useCachedFetch = (key, url) => {
  const [data, setData] = useState(null);
  const [isLoading, setIsLoading] = useState(false);
  const [lastUpdated, setLastUpdated] = useState(null);

  useEffect(() => {
    const cached = cache.get(key);
    if (cached) {
      setData(cached.data);
      setLastUpdated(cached.timestamp);
    }

    setIsLoading(true);
    fetch(url)
      .then((res) => res.json())
      .then((result) => {
        cache.set(key, { data: result, timestamp: new Date() });
        setData(result);
        setLastUpdated(new Date());
      })
      .finally(() => setIsLoading(false));
  }, [key, url]);

  return { data, isLoading, lastUpdated };
}

Why Do All This Manually?

If we are building a simple app, this approach is great for learning. But caching gets messy fast:

• How long should data stay cached?

• What if the data changes?

• What about pagination?

• How do we handle failed requests?

• What if the user goes offline?

That’s a lot of responsibility. And frankly, it has been solved already.

Meet React Query: Smart Caching Without the Pain

Let’s face it, writing caching logic for every API is tiring. It’s doable, but repetitive. And when you want things like retries, background refetching, or pagination? It gets messy real fast.

That’s where React Query steps in. It’s a battle-tested library built to take care of data fetching and caching, the stuff we just spent all that time manually handling.

Here’s what using it looks like:

const { data, isLoading } = useQuery(['user'], () => 
  fetch('/api/user').then(res => res.json())
);

That one line gives you:

• Automatic caching: React Query remembers your data and reuses it across navigations.

• Stale-while-revalidate: It shows stale data immediately and refreshes in the background.

• Background refetching: Triggers updates when the window refocuses or after intervals.

• Retry on failure: It will retry failed requests automatically with smart backoff logic.

• Pagination & infinite queries: Built-in tools to handle lists, pages, and scroll.

• Status indicators: Easily access isLoading, isFetching, isError, isSuccess.

• Query invalidation: Refetch only the data you need after a mutation.

All of this means your app feels fast and reliable and you do not have to reinvent the wheel.

React Query removes the heavy lifting, but does not get in your way. It is flexible, intuitive, and gives you control when you want it.

Conclusion

Improving perceived performance is often about showing something useful faster, not getting data faster.

We can absolutely build caching ourselves. But if the app is growing or and we want to focus on features, we are better off using react-query. users do not care what tech/library we use. all they care is “Can I quickly get my stuff done” And that’s what matters.

When designing the rubric generation system, I faced a key architectural decision:

Should I stream JSON responses as they are generated, or should I poll the backend for updates?

Streaming sounds like the obvious choice for real-time applications, but after careful consideration, I chose polling. Here’s why.

Understanding the Problem: Rubric Generation is an Asynchronous Process

Generating rubrics is not an instant operation. It involves multiple steps, each happening asynchronously:

1. Analyze the uploaded question paper.

2. Extract questions and transform them into JSON.

3. Send each JSON block to OpenAI for evaluation (create tasks for OpenAI to generate rubrics for each question).

4. Store responses in the database for retrieval.

Since each JSON response is generated independently, streaming might seem like a good fit. But does it actually make sense?

Challenges with Streaming JSON

If I were to stream rubric data to the frontend, several key questions arose:

1) What if the user navigates away or kills the app?

• Streaming requires an active connection. If the user leaves mid-process, they could lose all streamed data.

• Polling allows users to resume tracking progress anytime, even after navigating away.

2) When should we insert data into the database?

• Should we stream first and insert later? If so, what happens if the database rejects some updates?

• Should we insert first and then stream? If so, how do we ensure updates are pushed properly?

3) What if one process breaks?

• If data insertion and streaming run separately, one could fail while the other succeeds.

• This could lead to users seeing rubric updates that don’t actually exist in the database.

• To avoid this, I would need to set up queues, event listeners, and retry mechanisms, making the infrastructure much more complex.

At this point, streaming JSON became a rabbit hole of complexity. I realized that I would need to:
1. Maintain a queue to persist data while streaming.
2. Set up event listeners to detect failures and retry processing.
3. Ensure that streaming doesn’t outpace database updates.

This added unnecessary complexity at both the infrastructure and implementation levels.

Polling JSON: A More Predictable & Reliable Approach

While polling is often seen as an "archaic" approach, it actually provides predictability and consistency in this case.

Here’s how the rubric generation flow works with polling:

1. User uploads a question paper.

2. The system extracts questions and converts them into JSON.

3. A background job is started to generate rubrics for the entire question set.

4. As the LLM generates rubrics for each question, we insert them into the database under a common parent ID.

5. Once all questions have been processed, the job is marked as finished.

6. The frontend polls an API that aggregates all rubrics linked to the parent ID and displays them in real time.

Why Polling Wins in This Scenario

More Reliable: Polling always retrieves data from the database, ensuring consistency.
Handles User Navigation: Users can leave and return at any time without losing progress.
Simpler Infrastructure: No need for persistent connections, queues, or event-driven architecture.
Predictable Execution: Each poll fetches exactly what’s in the database—nothing more, nothing less.

Final Thoughts: Occam’s Razor in Action

Occam’s Razor states:
"The simplest solution that meets all requirements is usually the best."

Polling ensures real-time updates while avoiding the complexities of streaming, queue management, and event handling.

For use cases like chat apps or stock tickers, streaming makes sense. But for a job-based system like rubric generation, polling is the better choice.

A short video of rubrics polling in action.

Building the MVP

With Traceblade, I set out to bridge the gap between user events and logs. The first version focuses mainly on the fundamentals: capturing user events and logs independently. While the unified view is still in progress, the foundation is a critical step.

Things I needed for a solid foundation.

1. An ingestion pipeline

   The main focus is not just to ingest data into the system but to do it seamlessly. As my project uses React Native and Go, it was only natural that I created a React Native SDK and Go-Gin middleware, which need to be initialized with an API key configured in the Traceblade project settings.

2. The Interface

   For the MVP, I opted for separate views (events and logs), as this allows me to build a solid foundation before tackling the complexities of a unified experience.

   Natural Language Querying

   One of my favorite features is natural language querying, which will make it easy to search and filter data using simple, human-readable queries. This feature, demonstrated briefly at the 14-second mark of the video, this can go beyond raw data visualization and provide actionable insights.

The Next Steps

So far, I have captured the basics, but there is still so much more to do. My focus for the next milestones includes:

• Unified Timeline View: Combining user events and logs into a single interface to understand the ripple effects of user interactions across services.

• Advanced Filtering: Allowing users to fine-tune searches across events and logs.

• User Paths/Journeys: Analyzing and presenting user journeys within an app.

• Scalability: Ensuring Traceblade can handle larger datasets efficiently.

When we talk about 'configuration over code', we're essentially looking at a different way of controlling how things work in our applications. Instead of hard-coding every detail, we use external configurations. This shift can make our code more modular, easier to read, and, let's not forget, scalable.

In this piece, we are going to dive into how this concept of 'configuration over code' can be applied to the basic elements we use every day in building applications. Although this idea can fit into any framework, we will be using React as our go-to for examples – it's just easier to explain things this way. So, let's get started and see how this approach can change the way we write code.

The Good: Unlocking Flexibility

We all strive to write code that's not just neat and efficient, but also easy to modify. To achieve this, we often organize related logic in one place and extract overly generic logic into handy helper functions. This is a great start, but let's take it a step further. Imagine if we could compose our components in such a way that their behavior is dictated by the configurations we provide. With this setup, any new behavior or modification could be managed through the config, rather than tinkering with the component itself.

Wouldn't this make our lives easier? Instead of delving into the nitty-gritty of the component code every time we need a change, we simply adjust the configurations. This method not only streamlines the development process but also opens up a world of flexibility and scalability. Let’s delve into how this approach can revolutionize the way we build and maintain our applications.

To illustrate this idea let's assume we are building a user profile form with the below personas and each user has different types of fields.

• Student

• Professional

• Artists

In a traditional approach, we would make forms for all these individual users separately and display the ones needed by using conditionals. it sounds cumbersome, if a new persona gets added one would have to repeat the cycle of creating form and adding additional logic. There is a better way.

Configuration over code approach

Instead of creating individual forms, we create one dynamic form that consumes a config and renders the labels and fields based on the config. this way when a new persona is added, or a field needs to be updated one needs to just update the config and it will be done.

const formConfig = {
    student: [
        { name: 'name', type: 'text', label: 'Full Name', required: true },
        { name: 'age', type: 'number', label: 'Age' },
        { name: 'school', type: 'text', label: 'School Name', required: true },
    ],
    professional: [
        { name: 'name', type: 'text', label: 'Full Name', required: true },
        { name: 'company', type: 'text', label: 'Company Name', required: true },
        { name: 'position', type: 'text', label: 'Position' },
    ],
    artist: [
        { name: 'name', type: 'text', label: 'Full Name', required: true },
        { name: 'medium', type: 'text', label: 'Medium' },
        { name: 'portfolio', type: 'url', label: 'Portfolio URL' },
    ]
};

A DynamicForm component looks like this

const DynamicForm = ({ userType, onSubmit }) => {
    const fields = formConfig[userType] || [];

    const handleSubmit = (event) => {
        event.preventDefault();
    };

    return (
        <form onSubmit={handleSubmit}>
            {fields.map(field => (
                <FormField key={field.name} {...field} />
            ))}
            <button type="submit">Submit</button>
        </form>
    );
};

const FormField = ({ name, type, label, required }) => {
    return (
        <div>
            <label htmlFor={name}>{label}</label>
            <input type={type} id={name} name={name} required={required} />
        </div>
    );
};

and the usage would look like this

<DynamicForm 
    userType="student" 
    onSubmit={handleStudentSubmit} 
/>
<DynamicForm 
    userType="professional" 
    onSubmit={handleProfessionalSubmit} 
/>

in this approach updating the form fields or labels or even adding a new persona becomes a matter of just providing config, one doesn't have to touch DynamicForm's logic. When the components are so modularized, testing these components becomes much easier. if you notice this structure encourages us to write our presentation layer and logic separately encouraging separation of concerns idealogy.

There are numerous cases where we might need to show different renderers which are unrelated to each other. let us suppose we have a build a dashboard that shows different widgets: charts, news feeds, weather information etc and each widget has a different way of presenting data. an innocent way of this is to create a separate component for each widget type and use conditional logic in a parent component to decide which widget to render based on the data type.

Instead, we create a single Dashboard component that dynamically renders widgets based on a configuration object. This configuration defines which renderer (component) to use for each widget type

const widgetConfig = {
    chart: {
        component: ChartWidget,
        props: { },
    },
    news: {
        component: NewsWidget,
        props: { },
    },
    weather: {
        component: WeatherWidget,
        props: { },
    },
};

Dynamic Dashboard component

const Dashboard = ({ widgets }) => {
    return (
        <div>
            {widgets.map(widget => {
                const WidgetComponent = widgetConfig[widget.type].component;
                const widgetProps = widgetConfig[widget.type].props;
                return <WidgetComponent key={widget.id} {...widgetProps} {...widget.data} />;
            })}
        </div>
    );
};

Usage:

const dashboardWidgets = [
    { id: 1, type: 'chart', data: {  }},
    { id: 2, type: 'news', data: {  }},
    { id: 3, type: 'weather', data: { }},
];

<Dashboard widgets={dashboardWidgets} />

This approach allows for high flexibility and scalability. When we need to add a new widget type or modify an existing one, we can simply update the widgetConfig object. There's no need to rewrite or modify the Dashboard component's logic. Each widget component is responsible for rendering its content based on the props it receives, making the system modular and maintainable.

By using configuration objects to map data types to specific renderers, we separate the concern of what content is displayed from how it is displayed. This leads to a cleaner, more organized codebase that is easier to extend and manage

The Bad: The Config Conundrum

while configuration over code offers significant benefits in terms of flexibility and maintainability, it does come with some drawbacks. knowing these drawbacks will be crucial in making an informed choice of when to do it and when not to.

• Like with any system or thought there is a learning curve involved. For new devs joining the team, understanding a system driven by configs can be daunting. It would require them to have a grasp on both the codebase and the configuration setup

• maintainers and developers need to actively keep in mind and have a track if some configuration is being duplicated as after as configurations increase in an application

• Interconnected or nested configs can become challenging to handle, main and debug.

• With great power comes great responsibility. The flexibility to change the components or even applications behaviour through configuration can open the doors to misconfigurations which could lead to errors that might not be too easy to catch.

• Depending on how configurations are structured the performance of the application might take a hit. if heavy configs are provided at the start of the applications it might impact response time.

• As we aim to dynamically render components based on configuration might also lead to a less optimized rendering path compared to static component structure.

The Ugly: The Hidden Costs of Configs

• Over-Engineering and Configuration Bloat: Overuse of configurations can lead to complex and unwieldy configuration objects floating in all scopes of the application, making the code hard to manage and understand. This excessive complexity compromises maintainability and clarity.

• Performance Overheads: Heavy reliance on configurations can introduce performance bottlenecks, especially if configurations are loaded or parsed at runtime, potentially slowing down the application's response time and efficiency

Key Takeaways

• Enhanced Flexibility and Scalability: The configuration-over-code approach allows for easy modifications and scalability through external configurations, reducing the need for direct code changes.

• Maintenance and Reusability: Simplifies updates and maintenance, promoting modularity and reusability, while ensuring separation of concerns in the codebase.

• Complexity and Learning Curve: As it introduces complexities few developers might not be at ease at first, hence incrementally introducing it in smaller chunks is the best way to get people used to complex ideas.

• Performance: this can lead to performance bottlenecks if not managed efficiently, bloating of configuration would be an overhead on the performance.

• Balance is Key: Strike a balance between flexibility and maintainability, plan carefully on when we might need configurable code or components

Conclusion: Your Insights Matter

As we conclude our discussion on 'Configurable code', I invite you to share your experiences and thoughts. Have you encountered challenges or discovered effective strategies? Let’s continue this conversation in the comments. Your perspectives are invaluable in enriching this dialogue.

Looking forward to your contributions!

Asynchronous JavaScript is a cornerstone of modern web development, enabling efficient and responsive applications. This approach allows web pages to process lengthy operations, such as API calls or data fetching, without stalling the user interface. Traditionally, JavaScript executed code line by line, leading to potential delays in user experience. Asynchronous JavaScript, however, permits operations to run in the background, improving performance and user engagement. This post will delve into the mechanisms that make this possible, from callbacks, a foundational concept, to Promises and Async/Await, which offer more streamlined and readable code structures. Understanding these concepts is crucial for any developer looking to create dynamic, responsive web applications.

Synchronous vs. Asynchronous JavaScript

In synchronous execution, code runs line by line, each line waiting for the previous one to finish. If a line of code requires a time-consuming task, the entire application waits.

console.log('Start');
alert('Wait for user to close this alert box');
console.log('End');

Asynchronous execution allows JavaScript to perform long network requests or timers without blocking the main thread

console.log('Start');
setTimeout(() => {
  console.log('Timeout finished');
}, 2000);
console.log('End');
//output
-> Start
-> End
-> Timeout Finished

In this case, 'End' is logged before the timeout finishes, illustrating JavaScript's non-blocking nature. This is crucial for tasks like fetching data from an API or reading files, where waiting for the operation to complete would otherwise freeze the UI, leading to a poor user experience. This asynchronous behavior is enabled by the event loop in the JavaScript runtime, which manages the execution of callbacks and integration with Web APIs.

Callbacks

Callbacks are functions passed as arguments into another function, to be executed later. They enable asynchronous operations in JavaScript, like handling the completion of an event or a response from an API call.

function fetchData(number, callback) {
  setTimeout(() => {
    callback('Data received', number);
  }, 2000);
}
const myCallback = (data, args) => {
    console.log(data, args)
}
fetchData(10, myCallback);

here fetchData accepts a number and functions as an argument. the second argument, which is function is invoked after 2 seconds. this way we defer a task to be done in the future once data is received or a condition is met. In this example, the condition is that we wait for 2 seconds.

let's take the below three API calls and see how we can fetch data that are dependent on each other.

1. First API Call: Fetch user data based on a user ID.

2. Second API Call: Use the user's data to fetch their preferences.

3. Third API Call: Use the user's preferences to fetch personalized content.

getUser(userId, user => {
  getUserPreferences(user, preferences => {
    getPersonalizedContent(preferences, content => {
      // do something
    });
  });
});

In a callback structure, each subsequent API call would be nested within the callback of the previous one. This leads to deeply nested, hard-to-read code, often referred to as "callback hell." This structure makes error handling and code maintenance challenging, as the complexity increases with each additional dependent operation.

Promises

Promises in JavaScript are objects representing the eventual completion or failure of an asynchronous operation. They have three states:

1. Pending: Initial state, neither fulfilled nor rejected.

2. Fulfilled: The operation was completed successfully.

3. Rejected: The operation failed.

Error handling with Promises is done using the .catch() method, which catches any errors that occur during the promise chain. Refactoring the earlier example with Promises:

getUser(userId)
  .then(user => getUserPreferences(user))
  .then(preferences => getPersonalizedContent(preferences))
  .then(content => {
    // Process content
  })
  .catch(error => {
    // Handle any error from the entire chain
  });

In this structure, each API call returns a Promise. The .then() method handles the successful response, and .catch() manages errors, making the code more readable and easier to maintain.

Async/Await

Async/Await, introduced in ES2017, revolutionizes how we write and read asynchronous JavaScript. By prefixing a function with async, we can use the await keyword within it, allowing us to write asynchronous code as if it were synchronous. This approach simplifies handling asynchronous operations, like API calls, by eliminating the complexity of promise chains. Instead of using .then() and .catch(), Async/Await enables error handling through familiar try-catch blocks, enhancing readability and error management. This syntactic sugar not only makes the code cleaner but also easier to understand and maintain.

the above asynchronous tasks which were chained together earlier looks like they are happening one after the other, this makes it makes our code more readable and maintainable. this code above shows how we can make dependent calls look synchronous with await in try block and catch any error in error block.

async function fetchUserContent(userId) {
  try {
    const user = await getUser(userId);
    const preferences = await getUserPreferences(user);
    const content = await getPersonalizedContent(preferences);
    // Process content
  } catch (error) {
    // Handle errors
  }
}

Practical Applications

1. API Requests: Asynchronous techniques are pivotal in web development for fetching data from servers without freezing the UI. For instance, using the Fetch API, developers can retrieve data from a REST API and display it on the webpage without needing a page to reload.

2. User Interface (UI) Interactions: Async operations enhance user experience, like dynamically loading images or content as the user scrolls, keeping the interface responsive and engaging.

3. Real-Time Applications: Asynchronous JavaScript is crucial in applications requiring real-time data, like chat applications or live updates. WebSockets, combined with Async/Await, allow for smooth real-time communication.

4. File Operations (Node.js): In server-side JavaScript (Node.js), asynchronous file operations are essential to prevent blocking the main process. Reading or writing files asynchronously ensures server responsiveness.

5. Animations and Timed Actions: Async patterns are used in setting up animations or actions that need to be executed after a delay, like using setTimeout for delaying a function execution or creating timed animations.

Conclusion

we've explored various methods of writing asynchronous JavaScript, from callbacks to Promises, and the more recent Async/Await syntax. These tools are essential in modern web development for creating responsive, non-blocking user interfaces and handling complex operations like API requests, real-time updates, and more. However, it's important to note that the real hero behind all these functionalities is the JavaScript event loop. This fundamental part of the JavaScript runtime environment enables asynchronous behavior, orchestrating the execution of all these operations. While this post focused on the 'how' of writing asynchronous JavaScript, the event loop is the underlying mechanism that makes it all possible.

Resources and Readings

• https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Asynchronous

• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function