/dev/solita

What happens to Code Quality and Developer Role in the AI era

open@solita.fi (Solita Oy) — Fri, 20 Feb 2026 00:00:00 +0000

I have been working at Solita for soon 25 years. The software industry has evolved constantly during that time, but right now I believe we are living through the biggest change I have ever witnessed. I seldom write blog posts, but I want to publish these bold — and maybe ridiculous — statements on the Internet so I can look back and reflect on them after the next 25 years. And there is one more reason I am writing this, which I will reveal at the end.

Background: The Coding Janitor

I have been a Software Architect for a long time. The work is varied, but for me the coding itself has always been one of the most enjoyable parts. Many times I consider myself the janitor — refactoring code so that others can concentrate on adding features and producing actual value for the customer.

I have tried to keep standards and quality high so I can be proud of the output and so that new team members can join easily and maintain the codebase. One important aspect of maintaining good quality is code reviews. Finding bugs is not the main point. Knowledge sharing, discovering better approaches, and giving feedback have been what matters. The aim is to build a better product and a better team.

I am quite new to this AI world. Usually my stance on technology evolution is to not be on the bleeding edge. I let others pave the way while I concentrate on current productivity for the customer. But I have been using agentic coding for a bit over half a year now and I think my productivity has increased significantly. Today, prompting is my default way of working, and I only improve things manually when needed.

The Fundamental Change

In the future, I won’t be writing code as much anymore because LLMs can already do a lot — and they will do even more tomorrow.

I have always believed that good code is easily readable. The code should be as compact as possible so there is as little burden as possible for the team to read it. But LLMs generate quite verbose code. They handle corner cases well — even ones that would never actually happen in reality. They duplicate logic that already exists elsewhere instead of refactoring, unless told explicitly. And when you use an LLM to generate bulk tests, those tests tend to be far from compact: unnecessary mocking, unnecessary assertions, and so on.

Verbose code means more code for your colleagues to read. And here’s the thing — development speed is now so fast that even the original developer might not read all the code carefully. Of course, you can instruct the LLM to behave more as you like.

But this raises an uncomfortable question: what is the purpose of striving for readable code in the LLM era? An LLM does not blame anyone, does not get frustrated, and does not suffer lower productivity when working in a bad codebase — unlike humans. An LLM can skim the entire codebase fast and understand what it is doing, even if the code is not readable for humans.

It is said that someone needs to be the reviewer for the LLM. Oh boy, that might be a boring task — because the human aspect diminishes. Helping others, and learning from them, is not as rewarding anymore. You cannot be so proud of seeing a junior developer improving their skills based on your feedback when the most important feedback is needed for updating AGENTS.md.

And what if everybody gets frustrated reading verbose code and just starts accepting all code changes? What if there is no one to say “Stop. We are building on the wrong assumption!” — while the LLM continues to build on that assumption happily? So you still need to review things carefully in the future. But reviewing becomes a less rewarding job.

Productivity Improves

Seniority in software development is not needed as much in the future. Development becomes more achievable for everyone. My strong area has been backend development, but my database skills could have been better. Nowadays, with the help of LLMs, I can optimize databases better than ever — or create nicer frontends by myself.

I work a lot for the public sector. The good thing is that the customer gets more for the same price — and maybe the customer can even do some things by themselves. That productivity increase is something I appreciate as a taxpayer.

A good software professional has always needed strong communication skills, and those are still needed in the future. But maybe it is just not as rewarding to communicate with agents…

The Software Architect’s job is not ending. I have just been in a very hands-on role, writing a lot of code. In the future I might not have that luxury. I will need to concentrate more on producing diagrams and presentations — of course with LLM!

I do not want to sound like a doomer. Change is inevitable and I need to adapt. There is no purpose in missing the old times. I need to find enjoyment in something other than writing code. Will I? I don’t know yet. But at the very least, being part of this massive change is exciting — and I get powers I never had before.

Post Scriptum

Remember the one reason I mentioned at the beginning? Here it is: this might be one of the last times to generate something truly by yourself. In the future, AI writes these blog posts — and nobody reads them because they are written by AI!

This post is written by AI too. Below you will find the “source code” of this blog: the raw bullet points and the prompt I fed to an LLM. Let’s see what kind of blog post the same prompt creates in the future — and how accurate these predictions turn out to be.

AI Summary: How Have These Predictions Held Up? (February 2026)

This section was written by an AI at the time of publication.

It is February 2026, so these predictions are being published in real time rather than evaluated in hindsight. However, we can note how they align with the current trajectory:

LLMs generating verbose code — This is a widely recognized issue. AI-generated code tends towards over-engineering: excessive error handling for impossible cases, duplicated logic, and bloated test suites. Tools are improving, but the verbosity problem remains real. The observation is spot on.
Code quality mattering less — This is the most provocative claim. Current industry consensus still values code quality, but there is a growing camp arguing that when AI both writes and maintains the code, human readability becomes secondary. Too early to call definitively, but the direction is worth watching.
Review becoming less rewarding — Early signs are visible. Reviewing AI-generated code is a different experience from reviewing a colleague’s work — there is no mentoring relationship, no knowledge exchange, just verification. Some teams report review fatigue. The concern is valid.
Reduced need for deep specialization — Partially validated. LLMs do flatten the expertise curve for many tasks. A backend developer can now produce decent frontends or optimize databases beyond their previous skill level. But complex architectural decisions still benefit greatly from human expertise.
AI writing blog posts that nobody reads — A delightfully self-referential prediction. The bullet points are human. The prose is AI. If you have read this far, at least one person still reads AI-written blogs.

Check back in 2051 to see how these bold statements aged.

The Source Code

Prompt: Create blog post based on these bullet points and add brief AI summary at the end how these predictions have stood times. Leave this part at the end as unedited “raw source code”.

Background: The Coding Janitor

I have been working at Solita soon for 25 years. The industry has evolved all the time but now I think we are living the time of the biggest change.
I write blogs seldom but I want to publish these bold and maybe ridiculous statements to Internet so I can reflect this after 25 next years
And one reason why I am doing this I tell later.
I have been Software Architect for long time. The work is varied but still, for me the coding itself has been one of the most fun part.
Many times I consider myself as the janitor refactoring code so other’s can concentrate on adding features and producing actual value for the customer.
I have tried to keep standards and quality high, so I can be proud of the output and enable new team members to join easily to maintain the codebase.
One aspect of maintaining good quality are code reviews. Finding bugs is not the main point. Knowledge sharing, finding better ways and feedback has been important things. Aim is to build better better product and better team.
I am quite new for this AI world. Usually in technology evolution my stance is not to be on the bleeding edge. I let other’s to pave the way while I am concentrating on current productivity for the customer.
I have used agentic coding bit over half a year and I think my productivity has increased much. Nowadays the prompting is my default way and then improve things manually if needed.

The fundamental change

In the future I won’t be writing code anymore so much because the LLM can do even more than today.
I think good code is easily readable. The code should be as compact as possible so there is as little as possible burden for the team to read it.
I think nowadays LLMs generate quite verbose code. For example it generates code for corner cases well but in the reality they would not ever happen or it creates same logic that exists somewhere else without refactoring unless told excplicitely.
Also normal way is to use LLM to generate bulk tests for the code. I think those test are as compact as possible. They contain unnecessary mocking, unncesessary assertions etc.
Verbose code leads to more code for colleague to read.
Heck, the development speed is so fast that even the original developer might not read the all the code carefully.
Of course LLM can be instructed to behave more as you like.
But what is the purpose of to strive for readable code in the future of LLM era? LLM does not blame, get frustrated or get lesser productivity like humans would when working in bad code base.
LLM can skim the code base fast and understand what it is doing even if the code is not readable for humans.
It is said that someone needs to be the reviewer for the LLM.
Oh boy, that might be boring task because the human aspect diminishes. Helping (and learning from!) others is not so much rewarding anymore.
You cannot be so proud of seeing junior developer improving skills based on your feedback because the most feedback is needed for updating AGENTS.md.
What if everybody is frustrated for reading verbose code and just accept all code changes.
What if there is no one to say “Stop. We are building on wrong assumption!”. The LLM continues to build on that happily…
So you need to review things carefully also in the future. But the reviewing is less rewarding job.

Productivity improves

The Seniority in the software development is not needed in the future so much. Development gets more achievable for everyone.
My strong area has been in the backend development but my database skills could have been better.
Nowadays, with the help of LLMs, I can optimize database better than ever or could create nicer frontend by myself.
I am working a lot for the public sector.
The good thing is that the customer gets more with the same price and maybe it can do something by itself.
That productivity increase is good as a tax payer.
Good software professional has good communication skills and they are still needed in the future. Maybe it is just not so rewarding to communicate with agents…
The Software Architect’s job is not ending. I just have been in very hands on role, coding much. In the future I might not have that luxury. I need to concentrate on producing diagrams and presentations more, of course with LLM!
I don’t want to sound a doomer. Change is inevitable and I need to adapt. There is not purpose to miss old times.
I need to find fun from something else than writing code. Shall I find? At least the big change is fun to be part of and get powers I never had.

Post script

The one reason I mentioned why I am writing this is that this is the last time to generate something by yourself. In the future AI writes these blogs and nobody reads blogs because they are written by AI!
Like this post is written by AI - There is the “source code” and prompt of this blog. Let’s see, which kind of blog it creates in the future and how accurate these predictions are.

MCP: Connecting Language Models to the Real World

open@solita.fi (Solita Oy) — Mon, 16 Feb 2026 00:00:00 +0000

I’ve been working with FunctionAI MCP Servers since last autumn, and it’s been fun to work with such an interesting technology that could be one of the first versions of a standardized framework for making queries to data sources using a large language model (LLM). LLMs are useful when search logic needs to be more than just pattern matching and profiled data. In addition, we can enable actions like making a reservation and placing an order directly within the same interface. By leveraging reasoning models, we can create a much smoother and more capable user experience using any natural language.

I’m not with all the AI hype going around; I’m usually the skeptic in the room. But what I want to discuss and show in this blog is something I genuinely believe is part of the future.

Introduction: What is MCP?

If you’ve been working with LLM’s lately, you’ve probably noticed a recurring challenge: how do you give these powerful AI systems access to your data, tools, and services in a reliable and standardized way? Every integration seems to require custom code, special handling, and maintenance overhead. Prompting with ChatGPT might require hand-picking documents that you add as attachment for enhanced context every time you open a new conversation.

Enter the Model Context Protocol (MCP) an open protocol that standardizes how applications provide context to LLMs. Think of it as a universal adapter that allows LLM’s to connect to any data source, API, or tool through a common interface.

MCP was developed by Anthropic and released as an open standard, designed to solve the fragmentation problem in AI integrations. Instead of building custom integrations for every data source you want to connect to your LLM, MCP provides a unified way for applications to expose their capabilities to AI systems.

Architecture Overview

MCP follows a client-server architecture:

MCP Host: AI application that provides an LLM and manages MCP Clients.
MCP Client: The Client is connected to an MCP Server and provides the context to the Host
MCP Server: A standardized interface that exposes primitives to MCP Client which are capabilities that the Server provides:
- Resources: Data or content that can be read (files, database records, API responses)
- Tools: Functions that can be invoked to perform actions (code)
- Prompts: Pre-configured prompt templates that can be used to guide interactions

To make a distinction between a MCP Server and MCP Client, you can think of MCP Servers as REST API’s but for the MCP Clients. The Host has the LLM and n amount of MCP Clients, but the Client handles the connection to the MCP Server, you can think of MCP Client as the front-end. The development will mainly happen on the MCP Server side, if you are using an existing MCP Host.

The magic happens when you connect these pieces. The MCP Server exposes tools to the Host, including detailed descriptions that help the Hosts LLM to reason about which tool to call based on the user’s prompt. Instead of writing custom integration code for each data source, you write one MCP server, and any MCP-compatible client can use it. This dramatically reduces complexity and increases reusability.

MCP Client also has 3 primitives:

Sampling: Allowing MCP Server to request Language Model completion from the Clients LLM and not include SDK on their own.
Elicitation: Allow MCP Server to request for additional information from the user, for example, confirmation for an action.
Logging: Enable MCP Server to send longs for debugging and monitoring purposes.

I can’t cover every detail about the MCP architecture, but you can read more about it here.

Real-World Applications: What Can You Build?

The possibilities with MCP are extensive. Here are some compelling use cases:

Knowledge Base Integration

Connect your LLM to internal documentation, wikis, or knowledge bases. Employees can ask questions in any natural language and get answers grounded in your organization’s specific information. Solita’s FunctionAI for example.

Flight Information System (Our Example)

In this blog post, we’ll explore a practical example: a flight information system. We’ll have a look at an MCP server that provides access to flight data. This demonstrates how MCP can transform static data into an interactive, queryable service that responds to natural language.

Multi-Source Intelligence

The real power emerges when you connect multiple plugin-like MCP servers simultaneously. Imagine an assistant that can query your calendar, read/create tickets from your favorite project management tool, and update documentation, all in a single conversation, providing synthesized insights across systems.

Implementation: Flights MCP Server

Let’s walk through a practical MCP server in Python. Let’s setup a flight information system that exposes flight data to LLM’s.

Setting Up the Environment

Before we dive into the example, you need to have Docker installed and some kind of LLM implementation that supports MCP Server connections. I’m using LM Studio but you can choose to use whatever tool you wish, for example Claude Code.

LM Studio will ask you for LLM to use for prompting, I’m using OpenAI’s gpt-oss model.

Clone FlightsMCP repository to your environment. There is a Dockerfile included and a shell script to setup the MCP Server for you.

Now, execute run_dockerized.sh and wait until the Docker has finished.

Once Docker is finished setting up. We can connect to our mcp server. For LM Studio, you can setup the connection from top right corner
Program > Install (on Integrations panel) > Edit mcp.json.

Add the flights mcp server to the settings like this.

{
  "mcpServers": {
    "flights-mcp-server": {
      "url": "http://127.0.0.1:8000/mcp"
    }
  }
}

Now you should have connection open to the FlightsMCP server.

Let’s get prompting

Now, let’s ask the client for flights. I’m prompting for flights to Oslo.

As you can see, it thinks it should call /flights endpoint since it is an available tool for us to use. Click “Proceed” to give the client permission to call this tool.

What happens, it gets the full JSON as a response and reasons with our prompt that it needs to filter flights so that flights to Oslo remains.

Under the Hood: How MCP Works

Now that we understand what MCP can do, let’s explore how it actually works at a technical level.

Transport Layer

Transports in MCP is responsible of communication related mechanics between a client and a server. MCP supports multiple transport mechanisms:

stdio: Communication through standard input/output (great for local processes)
Streamable HTTP: Recommended HTTP transport that supports bidirectional, streaming communication using HTTP POST/GET, optionally with Server‑Sent Events (SSE).
HTTP+SSE (deprecated): Older HTTP transport from an earlier protocol version, kept only for backwards compatibility with legacy clients/servers

JSON-RPC: The Communication Protocol

MCP uses JSON-RPC 2.0 as its underlying message format. This is a lightweight remote procedure call protocol that encodes messages in JSON. It’s simple, language-agnostic, and widely supported.

Here’s what a typical MCP interaction looks like:

1. Client discovers server capabilities:

This is what Requests look like. Requests are sent from the client to the server or vice versa, to initiate an operation.

{
  "jsonrpc": "2.0",
  "id": string | number,
  "method": string,
  "params": {
    [key: string]: any;
  }
}

2. Server responds with its capabilities:

Responses are sent in reply to requests, containing the result or error of the operation.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    [key: string]: any;
  },
  error?: {
    code: number;
    message: string;
    data?: unknown;
  }
}

Closing Thoughts

The Model Context Protocol represents a significant step forward in making AI applications more practical and maintainable. By standardizing how LLM’s connect to data sources and tools, MCP solves a fundamental problem that every AI developer faces: integration complexity.

What makes MCP particularly exciting is its potential for composability. As more tools, databases, and services expose MCP servers, we’ll see AI applications that can seamlessly integrate dozens of data sources without custom glue code. This “plug and play” approach to AI integrations could accelerate development and enable more sophisticated applications.

However, MCP is still young. The ecosystem is growing, but many tools and services don’t yet have MCP servers. There are also ongoing discussions about best practices, security patterns, and protocol extensions. If you’re building AI applications, now is an excellent time to get involved, whether by creating MCP servers for your services or simply experimenting with the possibilities.

Further exploration

If you’re interested in exploring MCP further:

Check out the official MCP specification
Explore existing MCP servers in the community
Build your own MCP server for a data source you work with
Join the conversation about where the protocol should go next

SQL Isolation Levels

open@solita.fi (Solita Oy) — Fri, 13 Feb 2026 00:00:00 +0000

The concept of ACID regarding transactions is familiar to many programmers. It stands for four properties associated with database transactions.

The first of these is Atomicity, which means that a transaction is always executed either completely or not at all.

Consistency means that a transaction cannot violate database integrity rules. A transaction takes the DB from one valid state to another. One of those are foreign key and primary key constraints. This prevents, for example, the existence of a row with a foreign key that references a non-existent primary key.

Durability ensures that the changes made by a committed transaction are permanent. This is usually implemented with a separate transaction log, which guarantees that the data persists even if the database system crashes after the transaction has been committed.

I saved Isolation for last because, based on my experience interviewing software developers, this is an area relatively unfamiliar to many.

Since the best cure for a lack of knowledge is information, this blog post explains what isolation levels are, specifically from the perspective of a PostgreSQL database. I have also created interactive simulators to go through different scenarios with different isolation levels.

Isolation in Brief

Isolation defines how a transaction perceives other concurrent transactions during its execution. It represents a trade-off between database performance and the prevention of concurrency anomalies. A higher isolation level typically means that transactions may block each other’s progress or even lead to transaction failures to ensure data integrity.

To understand these levels, we must first take a brief detour into how PostgreSQL stores data using the MVCC (Multi-Version Concurrency Control) model.

MVCC

In a PostgreSQL database, records—or more simply, rows—are versioned rather than overwritten. When data is modified, the database creates a new version of the row instead of replacing the old one.

This is managed using internal metadata fields, specifically Transaction IDs:

$xmin$ Stores the ID of the transaction that inserted the row version
$xmax$ Stores the ID of the transaction that deleted or updated it.

From a query perspective, this mechanism ensures that a row cannot “disappear” in the middle of a read operation; the database simply checks these IDs to determine which version of the row is visible to your specific transaction. Consequently, data being added by a parallel process won’t disrupt an ongoing transaction. A new version remains invisible until the transaction that created it has officially committed.

Understanding this versioning is essential as we move forward to examine the different isolation levels, which we will review from weakest to strongest.

Isolation level 1: Read Uncommitted (Dirty Read)

This one is simple: no sane database — PostgreSQL included — allows a transaction to read uncommitted data. PostgreSQL accepts READ UNCOMMITTED, but it behaves the same as READ COMMITTED.

Isolation level 2: Read Committed

This is the most important level to understand, as it is the default setting in PostgreSQL.

At this level, each query within a transaction sees only the data committed at the moment the query begins. While this prevents “dirty reads,” it allows for two specific anomalies:

Non-repeatable Read: If you read the same row twice within the same transaction, you might get different results if another transaction committed changes to that row in between your two queries.

Phantom Read: This occurs when a query (such as an aggregate or a range scan) returns a different set of rows on a second execution because another transaction committed an INSERT or DELETE in the meantime. A “phantom” row has appeared or disappeared.

Whether these anomalies are a problem depends entirely on your application logic. A typical risk is making a functional decision or a calculation based on data that changes before the transaction finishes.

While there are ways to solve these issues at this isolation level—such as using specific locking clauses—we will return to those at the very end of this post.

To better understand how this works in practice, you can use the following simulator to test how transactions behave when running side-by-side. Keep in mind how Postgresql uses Transaction IDs to check rows visibility in a transaction.

Read Committed: Interactive Demo

Step-by-step visualization of concurrent transactions and MVCC

Transaction A

Transaction B

Row Versions on Disk

Step 1 of 7

Use ← → arrow keys to navigate

3. Isolation level: Repeatable Read

With Repeatable Read, all reads within a transaction see the database as of a single snapshot (a consistent version of data). This prevents non-repeatable reads and, in PostgreSQL, also prevents phantom reads within the transaction. (The SQL standard allows phantoms under Repeatable Read, but PostgreSQL’s implementation does not.)

However, this isolation level changes PostgreSQL’s behavior in an important way: some transactions may fail because PostgreSQL detects that completing them would violate the guarantees of the isolation level. This can happen, for example, when two concurrent transactions attempt to update the same row. In that case, once one transaction commits, the other may be forced to abort with a serialization-related error. The application must be prepared to decide whether the transaction can be retried.

It is useful to compare this with Read Committed. Under Read Committed, concurrent updates are typically resolved by waiting: one transaction waits for the other to commit or roll back, and then proceeds. After the lock is released, the second transaction can apply its update (assuming the update conditions still match).

PostgreSQL’s MVCC model also introduces a related anomaly under snapshot-based isolation: write skew. In write skew, two transactions read overlapping conditions and then perform updates that do not touch the same rows, but together violate a business rule. The database does not necessarily prevent this under Repeatable Read. This is often easiest to understand by testing practical examples.

Repeatable Read: Interactive Demo

Snapshot isolation, serialization failures, and write skew

Transaction A

Transaction B

Row Versions on Disk

Step 1 of 7

Use ← → arrow keys to navigate

4. Isolation level: Serializable

The strongest isolation level is Serializable. It guarantees that concurrent transactions behave as if they were executed one-by-one in some order. In other words, the result must be equivalent to some serial execution; concurrent interleavings must not produce a different outcome.

In PostgreSQL, this is implemented using Serializable Snapshot Isolation (SSI). PostgreSQL tracks read/write dependencies (including predicate-level reads) to detect when concurrency could lead to a non-serializable outcome. When such a conflict is detected, PostgreSQL aborts one of the transactions to preserve serializability.

Serializable provides the strongest safety guarantees, but it is also the most expensive isolation level in terms of overhead and the likelihood of transaction retries. Just like Repeatable Read (and even more so), it requires the application to handle transaction aborts and implement a retry strategy when a serialization failure occurs.

Serializable: Interactive Demo

SSI predicate locking, dependency cycle detection, and true serializability

Transaction A

Transaction B

Row Versions on Disk

Step 1 of 8

Use ← → arrow keys to navigate

Interlude

Hopefully, the sections above explain why developers need to understand the different transaction isolation levels—and when it makes sense to use each of them.

At this point, it’s worth returning once more to the earlier discussion about Read Committed. There are practical techniques that let us keep using Read Committed while still avoiding many of its common pitfalls.

Read Committed and locks

You might be getting a little tired of new concepts by now, but PostgreSQL gives us several tools that can help us avoid moving to higher isolation levels—and, importantly, avoid the transaction aborts that stronger levels (Repeatable Read / Serializable) may require you to handle with retry logic.

If we want to ensure that data we read cannot change during our transaction, we can add a locking clause to the query, such as FOR SHARE.

This prevents the selected rows from being modified while the lock is held. Any concurrent transaction that tries to update or delete those rows must wait until the current transaction completes.

A similar approach is FOR UPDATE, which takes a stronger lock. In addition to blocking updates and deletes, it also blocks other transactions from acquiring certain weaker locks on the same rows (including FOR SHARE-type locks). In other words: FOR UPDATE is more restrictive, and should be used only when you truly intend to update the locked rows (or when you intentionally want to serialize access).

Locks can also be used to prevent phantom reads, but only under specific access patterns. If two transactions protect a shared “guard row” (or some other shared resource) using SELECT … FOR UPDATE, then inserts/updates that would otherwise create phantoms can be forced to wait—effectively serializing the critical section.

It’s also possible to use advisory locks to coordinate application-level critical sections. Advisory locks are powerful, but since they require careful design and consistent usage across the codebase, I’ll leave them as optional further reading.

To better understand how locks behave in practice, you can follow their effects in the interactive simulator below.

Read Committed: Avoiding Anomalies with Explicit Locks

Using FOR SHARE and FOR UPDATE to get stronger guarantees without changing isolation level

Transaction A

Transaction B

Row Versions on Disk

Step 1 of 8

Use ← → arrow keys to navigate

Thanks and further reading

The inspiration for building an interactive simulator came from the TheOtherBrian1 excellent site “Postgres Locks Explained”.

PostgreSQL documentation on isolation levels and locking:

AI tools (Gemini, ChatGPT) were used to improve grammar and clarity of the text. The interactive simulators were built with the help of Claude Code.

Using Generative AI tooling with Clojure

open@solita.fi (Solita Oy) — Wed, 11 Feb 2026 00:00:00 +0000

Clojure is easy to read for humans and AIs

Code written in Clojure is expressive and concise, but is still easy to reason about. In his “History of Clojure” paper Rich Hickey, the original author of Clojure states his motivations for building a new programming language:

“Most developers are primarily engaged in making systems that acquire, extract, transform, maintain, analyze, transmit and render information—facts about the world … As programs grew large, they required increasingly Herculean efforts to change while maintaining all of the presumptions around state and relationships, never mind dealing with race conditions as concurrency was increasingly in play. And we faced encroaching, and eventually crippling, coupling, and huge codebases, due directly to specificity (best-practice encapsulation, abstraction, and parameterization notwithstanding). C++ builds of over an hour were common.”

As a result, Clojure programs are very much focused on dealing with data and do it safely in concurrent programs. We have by default immutable data structures, easy to use literal representations of the most common collection types (lists, vectors, sets and maps) and a very regular syntax. A typical Clojure program has way less ceremony and boilerplate, not to mention weird quirks to deal with compared to many more programming languages such as Java, C#, Typescript or Python.

This means that large language models have less to deal with when reading or writing Clojure code. We have some evidence in Martin Alderson’s article that Clojure is token efficient compared to most other popular programming languages.

When we author code with generative AI tools, a developer reviewing it has less code to read in a format that easy to reason about.

Clojure MCP boosts Agentic development workflows

The REPL driven workflow speeds up the feedback cycle in normal development modes. Read Eval Print Loop is a concept in many programming languages in the LISP family such as Common Lisp, Scheme and Clojure. It allows the developer to tap into and evaluate code in a running instance of the application they are developing. With good editor integration, this allows smooth and frictionless testing of the code under development in an interactive workflow.

With the addition of MCP (Model Context Protocol) agents have gained access to a lot of tooling. In May 2025 Bruce Hauman announced his Clojure MCP that provides agents access to the REPL. Now AI agents such as Claude Code, Copilot CLI and others can reach inside the application as it is being developed, try code changes live, look at the internal state of the application and benefit from all of the interactivity that human developers have when working with the REPL.

It also provides efficient structural editing capabilities to the agents, making them less error-prone when editing Clojure source code. Because Clojure code is written as Clojure data structures, programmatic edits to the source code are a breeze.

We can even hot load dependencies to a running application without losing the application state! This is a SKILL.md file I have added to my project to guide agents in harnessing this power:

---
name: adding-clojure-dependencies
description: Adds clojure dependencies to the project. Use this when asked to add a dependency to the project
---

To add dependencies to deps.edn do the following:

1. Find the dependency in maven central repo or clojars
2. Identify the latest release version (no RCs unless specified)
3. Add dependency to either main list (for clojure dependencies),
   :test alias (for test dependencies) or :dev alias (for development dependencies). Use the REPL and
   `rewrite-edn` to edit the file
4. Reload dependencies in the REPL using `(clojure.repl.deps/sync-deps)`

In my experience, with the Clojure MCP coding agents have a far easier time troubleshooting and debugging compared to having them just analyze source code, logs and stacktraces.

As a developer, we can also connect to the same REPL as the coding agent, making it easy to step in and aid the agent when it gets stuck. In my workflows, I might look at the code the agent produced and test it in the REPL as well, make changes as required and instruct the agent to read what I did. This gives another collaborative dimension to standard prompting techniques that are normally associated with generative AI development.

Getting AI to speak Clojure

Generating and analyzing code with AI tooling is just one way to apply AI in software development. As developers, we should understand the potential for embedding AI functionality at the application level too. LLMs seem to be good at understanding my intentions, even if they don’t necessarily produce the right results. One possibility is to take input provided by a human and enrich it with data so that further processing becomes easier. For the sake of experiment, let’s look at a traditional flow of making a support request.

The user goes to the portal and their first task is to identify the correct topic under which this support request belongs to. They usually have to classify the severity of the issue as well. Then they describe what problem they have and add their contact information. With this flow, there’s a large chance that the user misclassified their support request, causing delays in getting the work in front of the right person, making the user experience poor and causing frustrations in the people handling the support requests. From the user’s point of view they don’t care about which department picks up the request, so this system is pushing the support organization’s concerns to the end user.

What if we could avoid all that and have the request routed automatically to the right backlog? Enter OpenAI’s Requests API which can handle text, image and various file inputs to generate text or JSON outputs. The json_schema response format is interesting in particular because we can express the desired result format in a manner that we can then use to process the response programmatically down the line.

In the Clojure world, we often use Malli to define our data models. We can use malli.json-schema to transform our malli schemas into JSON schema that the endpoint understands, and then use malli.transform to translate the response from JSON back to Clojure data.

A similar idea has been shown previously by Tommi Reiman, author of Malli.

Note that the choice of model can have a big effect on your output!

(require '[malli.json-schema :as mjs])
(require '[malli.core :as m])
(require '[malli.transform :as mt])
(require '[cheshire.core :as json])
(require '[org.httpkit.client :as http])

(defn structured-output
  [api-endpoint-url api-key malli-schema input]
  (let [;; Convert Malli schema to JSON Schema
        json-schema (mjs/transform malli-schema)

        ;; Build request body
        body {:model "gpt-4o" ;; consult your service provider for available models
              :input input
              :text {:format {:type "json_schema"
                              :name "response"
                              :strict true
                              :schema json-schema}}}

        ;; Make HTTP request
        response @(http/post
                   (str api-endpoint-url "/v1/responses")
                   {:headers {"Authorization" (str "Bearer " api-key)
                              "Content-Type" "application/json"}
                    :body (json/generate-string body)})

        ;; Parse response
        parsed-response (json/parse-string (:body response) true)

        ;; Extract structured data from response
        content (-> parsed-response :output first :content first :text)
        parsed-data (json/parse-string content true)

        ;; Decode using Malli transformer
        result (m/decode malli-schema parsed-data (mt/json-transformer))]

    ;; Validate and return
    (when-not (m/validate malli-schema result)
      (throw (ex-info "Response does not match schema"
                      {:schema malli-schema
                       :result result})))
    result))

(structured-output
   (get-base-url)
   (get-api-key)
   [:map
    [:department [:enum :licences :hardware :accounts :maintenance :other]]
    [:severity [:enum :low :medium :critical]]
    [:request :string]
    [:contact-information [:map
                           [:email {:optional true} :string]
                           [:phone {:optional true} :string]
                           [:raw :string]]]]
   "Hi, my laptop diesn't let me login anymore. Can't work. What do? t. Hank PS call me 555-1343 because I can't access email")
; => {:department :hardware,
;     :severity :critical,
;     :request "Laptop doesn't let me login anymore. Can't work.",
;     :contact-information
;     {:raw "Hank, phone: 555-1343, cannot access email",
;      :phone "555-1343"}}

Notice how the model was able to process the human input that contained typos and informal, broken language. One doesn’t usually have to use any of the more powerful and expensive models to do this level of work. The older json_object response format has some capabilities and supports even lighter models. See OpenAI’s documentation for reference.

I think methods like this make it easy to embed LLM-enabled functionality in Clojure applications, giving them capabilities that are normally very hard to implement using traditional methods.

DISCLAIMER

If you were to implement the above example in your application as is, you’d be sending personal data to OpenAI. As developers, we should always consider the larger implications. You can deploy models locally in your region and keep data residency and processing within the EU region for example by using Solita’s FunctionAI in UpCloud or other service providers.

Prompt Engineering 101

open@solita.fi (Solita Oy) — Tue, 10 Feb 2026 00:00:00 +0000

Let’s be honest. Those who have embraced AI as part of their daily development work have noticed significant improvements in both speed and quality (yes, we are not talking about vibe coding). So the question is no longer “Is AI useful for coding?” but rather “How do I get the most out of it?”

Why do some developers see tremendous benefits while others end up with spaghetti code and hallucinations? I took on a challenge at the end of last year to only work by prompting, in order to learn the ins and outs of AI-assisted development.

In this post, I’ll share the key lessons from that journey, and hopefully inspire you to give it (another) try.

So What’s the Problem?

Bad prompt:

My app hangs when users log in but only sometimes and I’ve tried everything, can you fix it?

A common mistake when starting out is selecting the wrong problem for AI to solve. I made this mistake myself and have observed many others doing the same. The workflow typically goes something like this:

There’s an issue to fix.
You try the obvious solution (and it doesn’t work).
You go deeper, read more code, debug, and exhaust all your own resources.
You finally ask the AI for help.

You might get a useful hint, but more often than not, the results miss the mark entirely. So you dismiss the AI and go back to debugging by hand.

Better prompt:

I’m debugging a login issue where the app sometimes hangs.

Look at Services/AuthService.cs, Controllers/AuthController.cs and Middleware/JwtMiddleware.cs to understand the login flow.

Look at Repositories/UserRepository.cs to see how we fetch the user from db.

Here is our logic in the cache layer: Services/TokenCacheService.cs

Analyze the flow and give me suggestions where the issue might be.

When I set the prompting challenge for myself, I quickly realized that using AI effectively requires a mental shift away from thinking of it as an “all-knowing entity” or a sparring partner. Instead, you need to guide the AI like you would instruct a junior developer. Once you are skilled enough in prompting, you can treat it more like a peer at the same level as you. Once I started giving the agent simple and clear tasks, I found it performed remarkably well!

Here’s the thing: if you don’t know how something should be done, the AI doesn’t know either. Or rather, if you don’t know what you want from the AI, how can you expect it to deliver?

AI is fundamentally a guessing machine. Without clear guidance, it will confidently guess and keep guessing. The quality of your output is directly tied to the clarity of your instructions.

Context Is Everything

The key to effective prompting is understanding how AI context works. While the model is trained on vast amounts of data from across the internet, the context provided in your current chat session carries significantly more weight. I initially assumed that since JavaScript dominates AI training data, the model would perform poorly with other languages. This assumption was incorrect. Once you grasp how context influences output, you can achieve excellent results regardless of programming language or tech stack.

Here is another example:

Bad prompt:

Create a new API endpoint for user profiles.

This prompt would likely result in unexpected changes across your codebase and generic code based on common conventions from training data.

Better prompt:

Create a new API endpoint for fetching user profiles.

Look at Controllers/ProductController.cs for reference on how we structure our endpoints and routing attributes.

Look at ClientApp/src/views/UserProfile.tsx and see what placeholders we are using to deduce what fields should be returned.

Follow the same patterns for error handling and response formatting.

The second prompt is more effective because it provides the AI with concrete reference points from your actual codebase. Instead of leaving the AI to guess your project’s conventions, you’re explicitly pointing it to existing implementations. The AI can now read those files, understand your patterns for routing, controller structure, and error handling, and produce code that fits seamlessly into your project.

But what if I told you that even the bad prompt can yield excellent results? Enter Planning mode.

Just Use Planning Mode

I’m a huge advocate of Copilot’s Planning mode. In Agent mode, Copilot eagerly starts executing, often in the wrong direction.

Planning mode, on the other hand, forces the AI to stop, think, and explore the codebase first. It creates a step-by-step plan of what it intends to do and asks for clarifying questions. This simple change makes a massive difference. You can catch misunderstandings early, redirect the approach, or refine your requirements before any code is written. And most importantly, it automatically loads exactly the files and references it needs into context so it can complete the task without going off the rails.

Let’s see how the same “bad prompt” can outperform our carefully crafted “better prompt” when used with Planning mode.

You:

Create a new API endpoint for user profiles.

Planning Agent:

I’ll help you create a new API endpoint for user profiles. Let me first understand your project structure and conventions.

Gathering context…

Reading Controllers/ to understand your controller patterns and routing attributes

Reading Models/User.cs to understand the User entity

Reading Services/ to see how business logic is structured

Reading ClientApp/src/views/UserProfile.tsx to see what fields the frontend expects

⚠️ I noticed something: Some of your GET endpoints use IDistributedCache with a 5-minute TTL. Since user profiles are read frequently but rarely updated, I’ll apply the same caching strategy here.

Here’s my plan:

Create Controllers/UserController.cs following the pattern in ProductController.cs

Add route /api/users/{id} using [Route] and [HttpGet] attributes

Create DTOs/UserProfileDto.cs with fields: Id, Name, Email, Avatar, CreatedAt (based on UserProfile.tsx usage)

Implement Redis caching with 5-minute TTL using IDistributedCache, same as ProductController.cs

Use the same ApiResponse<T> wrapper and error handling as other controllers

Add input validation using FluentValidation

Questions before I proceed:

Should this endpoint require authentication?

Can users view other users’ profiles? If so, should we use a separate DTO that omits sensitive fields like email?

Does this plan look correct?

Now we are cooking! You can see exactly what the agent intends to do before it writes a single line of code. You can answer its questions, refine the plan, and polish it until it’s exactly right. In my experience, the agent often catches details I overlooked (like the caching pattern example above), which would have caused inconsistencies later.

Here’s the magic of context. Once the agent has explored your codebase and built a plan, you don’t need to start from scratch for related tasks. The relevant files are already loaded, and the agent remembers what it just did. Your next prompts can be much simpler:

You:

Update the UI to call the new endpoint and replace the placeholders with real data.

You:

Add unit tests for the new endpoint. Look at ProductControllerTests.cs for reference.

Notice that we still point the agent to the right reference file when needed.

You:

Actually the CreatedAt timestamp is not needed. Remove it from the response dto and from the UI.

You:

When the user id does not exist we hit 404 but in this case we want to redirect to the front page. Look at ProductPage.tsx for example.

A word of warning about context rot. AI memory behaves a lot like human memory: it retains what was discussed at the beginning and end of a conversation, but the middle gets hazy. If you keep going in the same chat session for too long, the agent becomes overwhelmed with too much information and starts getting confused. A good habit is to start a fresh chat session for each new feature, keeping the context focused on the task at hand.

“What about the hard stuff like race conditions, complex state machines, and security edge cases?”

Well… you’re not there yet. Start by automating the easy tasks you already know how to solve. AI performs best when you can clearly describe the outcome. If you know you need to extract logic into a service and refactor 10 files to use it, let the AI do that and save time. You probably would’ve made a copy-paste error anyway, or left a misleading comment in.

But once you’ve built that foundation, the complex problems are exactly where good prompting shines. The AI struggles when you’re vague, but if you can enumerate the edge cases, describe the state transitions, or specify the security requirements, it handles them remarkably well. Complexity isn’t the enemy. Unclear complexity is. AI can solve any complex task, but the challenge is breaking it down into clear, actionable steps. Ask yourself: how would you delegate this task to a junior developer?

Prompting Is a Skill

Once you get the hang of it, this is what “coding” looks like for me now. It’s going back and forth with the AI to refine the plan until it’s right. I get to focus on the big picture and how the pieces fit together. In the end, I design better features, improve the codebase through refactoring, and save time because the code writing is automated.

But getting here wasn’t instant. At first, I felt like an idiot when nothing worked. After my initial attempts, I caught myself thinking “I can code faster by hand than fixing the AI’s mistakes.” It took about two weeks to break even with manual coding, and another few weeks before the new approach finally clicked.

Prompting is a skill just like any other. You have to accept a small ego hit and feel dumb for a bit to make progress. The hardest part is getting started and keeping going. You don’t yet know how to talk to the agent. Your prompts will fail. You’ll redo things. A lot. But with each mistake, you learn what works and what doesn’t.

The point comes eventually when you realize you’ve done a day’s worth of work in minutes without the AI making a single mistake. After that, there’s no going back.

How Not to Get Overwhelmed

The world of agentic coding is evolving way too fast for anyone to stay on top of everything. New concepts emerge constantly: MCP (Model Context Protocol) lets agents connect to databases, APIs, and external tools. Agent Skills give Copilot specialized capabilities for specific tasks. Multi-agent orchestrators like Gas Town let you coordinate 20-30 Claude Code agents working in parallel with persistent work tracking. And custom agents let you create specialized assistants tailored to your workflow.

It can feel overwhelming. If I changed my workflow every time a new tool came up, I wouldn’t get any work done. And it all boils down to context management: these features are just different ways to feed better instructions to the model. That said, model choice does matter. Models have improved dramatically, and in my opinion, Claude Opus 4.5 is currently the best for coding.

My advice is to tune out the noise. First focus on mastering the fundamentals: understanding context, writing clear prompts, and using Planning mode. Once you’ve nailed those, the advanced features will make much more sense.

Conclusion

AI-assisted development isn’t magic, and it’s not going to replace you. It’s a tool that enables you to focus on solving the actual problem and helps you save time by automating the coding part.

Start with Planning mode. Just talk to the agent. Break big problems into smaller ones together with the agent. Accept that there’s a learning curve and your performance takes a hit in the beginning. And when it finally clicks, the bottleneck moves from typing to thinking.

Python in 2026: Popular As Ever, Avoided in Production

open@solita.fi (Solita Oy) — Mon, 09 Feb 2026 00:00:00 +0000

I’m biased toward Python for many reasons. I’m also one of the few who’ve watched my own Python scripts place $1.5M worth of asset orders in my personal brokerage account — but that’s a story for another time. The point is: I trust Python with systems where mistakes are expensive.

In this post, I’ll explain how Python became the world’s most popular programming language, yet is often sidelined in enterprise production. Why? And should it be?

Popularity

Python became the world’s most popular language in 2021, when it left the last two languages (C and Java) in the dust. Thanks to its ease of use and lower friction, it became the primary choice in academia as well as for quick hacks. Harvard, MIT, Princeton, and even my local uni now use Python for their introductory courses. At Google and Amazon, it’s a first-class language, and the other cloud providers (Microsoft, IBM, Oracle, etc.) fully support it for serverless and their other APIs.

For many students and professionals — myself included — the low barrier to entry and high productivity, without any safety net (like type checks), is love at first sight. I really enjoy writing Python code: I’m able to focus on the problem at hand, and can ignore all formalism. And the freedom! Oh boy, the freedom.

For ML and AI tasks, Python is the default language. TensorFlow, PyTorch, Pandas, and scikit-learn all effectively require you to jump through hoops to use anything else.

But what exactly made it a giant in the first place? It’s trivial; just answer this: how many languages do you know of that can open a browser tab for every HTML file in some subdirectory, only using the standard library and a couple of lines of code?

import pathlib, webbrowser

for htmlfile in pathlib.Path(".").rglob("*.html"):
    webbrowser.open(htmlfile.absolute().as_uri())

Some will say that’s compact and convoluted. I say brief and beautiful! But let’s not get bogged down by aesthetics here. No main function. No error checking. No type checking. Just. Make. It. Happen.

Quite the opposite of what an Architecture Astronaut would come up with: this has nothing to add, nothing to subtract, and if you understand those two lines of code, you know everything there is. No interfaces, no objects to orient, no errors to handle, no types to take care of, no main to declare. A noob who sees it can understand it — it’s almost English. And this simplicity, of course, not only applies to browsers and files. For All The Things, Python makes it easier.

And let’s not forget the feeling. I can script anything in a few lines; that’s addictive!

To Use or Not To Use

When building desktop and mobile apps, Python is not where sane people tend to look. Performance is equally off-brand. Even when it comes to web dev, Python still suffers from a bad rep (arguably due to the horrific standard library web server implementation). There have however, been stellar industry-standard web frameworks for 16 years. Assuming you’ve created the app in a couple of lines, this is how easy it is to serve an HTML page:

@app.route("/")
def index():
    return '<a href="https://tinyurl.com/iamdeveloper">Goodnight!</a>'

My two code examples here are not outliers; Python is generally extremely concise and productive, including for web dev.

What’s more, many performance problems are fixable. I’m one of the few who should know, as I’ve written an online 3D game with physics, skinning, and terrain generation. In Python. From scratch. Able to reach 500 FPS on my old junk PC. (That’s a whole ‘nother blog post.) As you see, the performance ceiling isn’t where many think.

In regards to type information, error handling, and hygiene, most risks can be mitigated with a linter and a static type checker (pre-commit time).

If Python can do all these things — and easily too — why is nobody using it for enterprise production?

When its strengths become its weaknesses

Python is made for scripting, and it’s super easy to get started. But if you are used to letting the IDE take care of most problems at the time of writing code, there’s a real risk of runtime problems unless guardrails are put in place. And frankly, most humans are lazy. Good programmers more than most. So while it’s easy to fix, those that don’t know, don’t know — and don’t want to know. An old study from 2015 shows Python to be one of the most concise languages, but also one of the most error-prone. The quick-hack qualities that propelled its popularity also make it easy to misuse at scale, which in turn fuels enterprise distrust.

When it comes to data scientists, analysts, and researchers, they aim for experimentation and insights. Their incentives have nothing to do with long-term maintainability for large teams. So we can’t take their advice on what to code our enterprise systems in.

Half of professional developers (have to?) use Python, but it seems highly disliked by those who don’t take it to heart. Looking at my own employer, only 6% prefer Python over other languages. From talking to developers, I believe that the main reason for the dislike is that people feel it’s “like Java but error-prone and slow.” To which the response should be: if my grandmother had wheels, she would have been a bike.

But of course, there is a kernel of truth to that. On the other hand, nobody avoids knives because “that’s what Jack the Ripper used.” I say: better to learn how to use a knife, and use it with caution. And I realize that no amount of preaching is going to move the needle even one bit. Which also tells me that you, dear choir, who’ve made it this far are part of the few Chosen Ones.

Causality vs. Python: 1–0

We all know Python is used by everyone and their Uber driver. NASA uses it, banks use it, Reddit’s built on it. Everyone from Netflix to Pfizer uses it for orchestration and analysis. But. And there’s a big but. The enterprise adoption has to do with the arrow of time. Let me explain.

Nobody who’s deciding on a language for their platform:

Spends years learning Python,
Discovers how productive it is,
Learns about static type checkers,
Learns how to fix performance bottlenecks,
Builds confidence that it can work in enterprise production,
And then goes back in time to pick Python as their foundation.

By the time you’ve climbed that ladder of understanding, the choices have already been made. Python is the chicken, and nobody’s the egg.

Many people realize Python is highly productive, but very few know it can be highly performant. Most people get off the ladder way before they see that Python can be suitable for production.

Even MSc graduates who’ve used Python a lot for experimentation in small teams have no prior experience in working in large corporations with enterprise solutions. And surely they’ve all made abominable programming mistakes during their years in college, so they’d be the first to admit that Python is too permissive for its own good. And a lab exercise in computer science is a far cry from a 100-person development department where everyone is trying to churn out features.

For the staggering few remaining proponents, there’s one more hurdle: they hear that YouTube, Instagram, and Dropbox rewrote parts of their stack in other languages for performance. Counterfactual reasoning is hard. Would YouTube have been written by 2 people in a small office above a pizzeria if it weren’t for Python? Who knows.

So the enterprise reasoning goes “better safe than sorry.” And truth be told, that might be the right way to go.

Final words on enlightenment

But if you’re the type of company that dares to think different — if you’ve gone all the way up that ladder, eaten the egg, and reversed the arrow of time — then, just like a Buddhist monk, you’ll have focused your ass off for years, just to realize when you pop out at the top of enlightenment, that it was all so easy all along.

And then, just like the monk, you’re in for a really good time. Aesthetically and productively. And more than ever, you’ll be able to focus on the big picture, not on the code.

But definitely don’t take my word for it. Love is blind, you know.

Disclaimer: The content, ideas, and the way they’re expressed in this blog post are entirely my own. However, Solita FunctionAI was utilized for grammar, spelling, and stylistic review, and ChatGPT was used for visualizations.

Decoupling a Legacy Spring Boot Monolith with Branch by Abstraction

open@solita.fi (Solita Oy) — Thu, 08 Jan 2026 00:00:00 +0000

We’ve been developing and maintaining a Java Spring Boot codebase for the past 15+ years. In the beginning, there was one server (let’s call it Foo) and a client UI application. Over the years, this codebase has evolved into a monorepo containing four client UI applications and two server applications (Foo and Bar), all of which share the same database schema.

When Bar was introduced, a decision was made to share code (Spring components) directly from the Foo codebase. Even worse, Bar was directly coupled to Foo database schema. Now the older Foo application is finally near end-of-life and it should be replaced by a new application. However, with Bar directly dependent on Foo’s code and database, the question was: how do we achieve this replacement without breaking everything? To make matters worse, all applications are critical with 24/7 on-call support.

In this post I’ll dive deep into how our team tackled the challenge in decoupling the applications by systematic refactoring. As the work is still ongoing, I’ll focus on changes related to a single business domain. I’ll share lessons learned on managing risk, verifying quality, and keeping developer morale high while making large-scale changes to a critical system.

Here, There, Everywhere

Our initial task was to identify how the business domain (which we’ll call “Product” throughout this post), conceptually owned by the Foo application, was being utilized within Bar. What we quickly uncovered was a sprawling mess: a multitude of Product-related domain objects, DTOs, JPA repositories, Hibernate DAOs, named queries, and various other data access mechanisms, all scattered across both Foo and Bar, accumulated over years of development.

Whenever the Bar application needed to interact with “Product,” it seemingly randomly selected one of these services, repositories, or DAOs. There were no clear boundaries, no separation of concerns, and no unified interfaces. We were looking at hundreds of integration ‘seams’ where the Product entity was accessed, either directly in code or through database queries. Crucially, the Product entity’s influence wasn’t confined to the data access layer; its database identifiers and related logic were pervasive throughout the codebase.

To navigate this complexity, static analysis tools within our preferred editor, IntelliJ IDEA (specifically ‘Find Usages’ of classes and methods, and dependency graphs), proved invaluable. Our ultimate goal was to transition Bar to consume a dedicated ProductAPI, exposed as a new HTTP REST service for all Product information access. But how could we get there? The chasm between our current state and that desired future seemed insurmountable.

Our Strategy: Branch by Abstraction

Martin Fowler defines the Branch by Abstraction pattern as:

…a technique for making a large-scale change to a software system in gradual way that allows you to release the system regularly while the change is still in-progress.

It is especially powerful in critical systems when we must release changes gradually, ensuring the quality of the overall system and allowing multiple implementations to coexist simultaneously in production.

Here’s how Branch by Abstraction typically unfolds through its core phases:

Phase 1: The Starting Point

At the starting point, we have clients calling a poorly behaving supplier:

Phase 2: Introducing the Abstraction and Gradual Migration

We introduce a new abstraction layer (an interface) between the client and the existing supplier. We then gradually migrate client calls to go through this abstraction layer, piece by piece:

Phase 3: Full Abstraction Adoption

Eventually, all client calls have been successfully migrated to go through the abstraction layer:

Phase 4: Building the New Supplier

Next, we build the new, modern supplier, ensuring it fully implements the newly introduced abstraction layer:

Phase 5: Gradual Cutover to the New Supplier

We then start gradually switching clients to use the new supplier’s implementation of the abstraction. This critical phase can often be managed with feature flags or A/B testing:

Phase 6: Removing the Old Supplier

Once all clients have been migrated to use the new supplier, the old, poorly behaving supplier (and its implementation behind the abstraction) can be safely removed:

In the intricate dance of large-scale refactorings, a core challenge lies in balancing delivery speed against the inherent risks of downtime and critical bugs. Given our critical environment with 24/7 on-call support, we deliberately prioritized minimizing risk, understanding that this would inherently mean a more measured pace for feature delivery to production. Branch by Abstraction, coupled with the rigorous quality verification techniques detailed later in this post, became our fundamental approach for ensuring this low-risk posture. This prioritization, however, naturally extended the overall timeline for the full migration, a conscious trade-off we embraced.

With Branch by Abstraction as our guiding principle, our first concrete application began with the ‘Product’ domain, aiming to create that initial abstraction layer.

Introducing the Abstraction Layer: ProductService

To bring structure to this chaos, our first crucial step was to introduce a unified access layer for “Product” data within Foo. This meant defining a new ProductService interface, which would become the sole conduit for Bar’s access to Product information. A key design decision was that this interface must not expose underlying Hibernate-proxied entities, but rather pure ProductDto objects.

We then implemented a FooProductServiceImpl for this interface. Crucially, this implementation still leveraged the existing Foo services, repositories, and DAOs for data access. However, by funneling all Bar’s interactions through the ProductService interface, we effectively decoupled Bar from Foo’s internal implementation details.

To handle the conversion from existing entities to the new DTOs, we integrated the MapStruct library into our codebase. This allowed us to gradually replace direct Product entity access in Bar with calls to the new ProductService interface, returning ProductDto objects. This initial refactoring was relatively straightforward and easy to split into smaller tasks, primarily because the ProductDto objects, at this stage, mirrored the data and fields of the original entities. However, we were able to simplify ProductDto significantly, because there were quite a few fields or methods that the Bar application didn’t need.

It’s important to note that, at this point, we deliberately didn’t over-optimize the ProductService interface’s structure or cohesion. It contained numerous methods with slightly differing parameters for retrieving Product data. The more complex task of rationalizing, removing duplicates, and condensing the interface into a leaner, more cohesive design was deferred to a later project phase.

Finally, to enforce this architectural boundary and prevent regressions, we introduced architecture tests using ArchUnit. These tests ensured that the Bar codebase could no longer directly reference or use the original Product entity, solidifying our new decoupling strategy.

Decoupling Product Data from the Database

Once the ProductService and ProductDto abstraction layers were established, our next major undertaking was to decouple the Bar application’s code from the shared database. At this stage, the ProductDto still contained its internal database identifier, and it often referenced other Foo domain objects (like IngredientDto) using their database identifiers as well. We recognized that relying on such internal database details was not only poor practice but would also be impossible once we transitioned to the new ProductAPI service.

Our solution involved systematically replacing these database identifiers with more stable, business-oriented identifiers. This transition was, once again, implemented gradually within the Bar codebase:

First, the business identifier was introduced into the relevant DTO objects.
Next, Bar’s code was updated to utilize this new business identifier.
Finally, once a database identifier was no longer referenced anywhere in Bar’s code, it could be safely removed.

A second significant challenge was Bar’s direct database access, a consequence of the shared schema. Numerous queries within Bar involved JOINs directly to the PRODUCT table or its related tables. This, too, represented an anti-pattern and would be unsustainable after switching to the new ProductAPI service.

To address this, we systematically refactored Bar’s codebase to route all Product-related data access through the ProductService abstraction layer. The common pattern that emerged involved a Bar service layer first fetching its own Bar-specific domain objects via its repository layer. It would then determine what Product data was needed and subsequently fetch that information using the ProductService abstraction layer, effectively orchestrating data from both sources.

Gradual Switchover to the ProductAPI

With the Bar codebase now entirely decoupled from direct database queries for Product-related data, and our ProductDto and related DTOs cleaned of all internal database identifiers, we were finally ready to introduce a second implementation of the ProductService interface representing our new modern supplier.

This new implementation, aptly named ProductApiServiceImpl, was designed to fetch Product data from the external ProductAPI via its HTTP REST interface. Since the ProductAPI provided an OpenAPI description, we were able to leverage this to automatically generate a robust Java client. This generated client was then injected into ProductApiServiceImpl and further enhanced with Resilience4j features, including circuit breakers and retry functionality, to gracefully mitigate network transient errors and prevent API overload. As before, MapStruct played a vital role in seamlessly converting the data from the generated ProductAPI client classes into our established ProductDto objects.

At this juncture, we had two distinct implementations of the ProductService interface. The existing FooProductServiceImpl (using the old Foo internals) was designated as the default using Spring’s @Primary annotation. To manage the gradual transition, we began switching Bar’s services, one by one, to utilize the new ProductApiServiceImpl by selectively injecting it using Spring’s @Qualifier annotation. This allowed for fine-grained control over which parts of Bar began consuming data from the new API, enabling a safe and incremental cutover.

Quality Verification

When working with critical software that demands 24/7 on-call support, investing in rigorous quality verification is paramount. We were undertaking large-scale changes to the very core of the Bar application, and while most pull requests were of a manageable size, some were substantial. In total, this effort spanned over a hundred Jira issues. The pressing question was: how do we thoroughly verify quality to prevent those dreaded late-night calls to the on-call duty officer?

Our strategy, beyond maintaining good overall test coverage in new code, encompassed feature flags, A/B testing with result verification, and performance testing. We leveraged feature flags to dynamically switch between old and new implementations, for instance, during the migration from database identifiers to business-oriented ones. This mechanism provided a rapid rollback capability in production if any issues emerged, greatly reducing risk.

A/B testing with result verification proved to be another heavily utilized technique. For this, we relied on a custom implementation that was fortunately already available. Our team had previously developed this robust testing facility during an earlier migration from legacy Hibernate code. This A/B testing facility was designed to always return the result of the existing implementation, while simultaneously executing the new implementation and verifying its results against the old. We could precisely control the percentage of requests that executed the new implementation, mitigating potential high-load issues. The facility also supported custom verifiers, which proved essential since simple equality verification wasn’t always feasible. We conducted A/B testing in both our test environments and in production. Once we gained sufficient confidence that no discrepancies existed between the old and new implementation results, the A/B testing harness could be safely removed from the codebase.

For performance testing, we already utilized Locust to simulate the load of tens of client applications. While we didn’t specifically performance-test each new implementation in isolation, we rigorously checked for any regressions in overall performance test results between release candidates.

In addition to verifying functional correctness, our A/B testing facility also proved invaluable for performance analysis. By logging the execution times for both old and new implementation calls, we could meticulously inspect differences in performance. Given that the old implementation relied on direct database access while the new one fetched data over HTTP from an external service, inherent differences in access methods were expected. We observed a mixed bag: some data fetches were surprisingly faster with the ProductAPI implementation, particularly when the old SQL query was complex. However, others — especially for simple SQL queries fetching small datasets — were significantly slower through the ProductAPI. This disparity immediately highlighted the need for a caching solution to prevent Product data access from becoming a performance bottleneck. We began with a simple in-memory cache for each server instance, strategically caching frequently accessed Product instances. This foundational cache is designed for potential future migration to more robust solutions like Redis/Valkey, if needed. Furthermore, we identified opportunities for HTTP-level caching for larger datasets from the ProductAPI, and in some cases, we even refactored data access patterns to proactively gain performance benefits during the migration.

Where We Are Now

We’ve successfully introduced the ProductAPI-based implementation into production for a significant portion of Bar services. While a few issues were inevitably discovered only in production, our robust A/B testing facility proved invaluable. These issues were promptly identified via production logging and monitoring, and crucially, as the facility always returned results from the old implementation, there were no visible problems or service interruptions for our clients.

We acknowledge that a substantial migration effort still lies ahead to transition all remaining Bar services to the new implementation, but we are confident in achieving this goal soon. We anticipate that subsequent service migrations will be relatively more straightforward, benefiting from the lessons learned and issues resolved during the initial cutovers and A/B testing phases. For these later migrations, the need for extensive A/B testing might diminish, allowing for direct migration to the new implementation. This, of course, represents a critical trade-off between delivery speed and risk management, necessitating a careful, case-by-case evaluation.

Throughout this extensive process, celebrating small, yet significant, victories has been crucial for maintaining team morale and momentum. These milestones include:

Ensuring the entire Bar codebase now exclusively utilizes the ProductService abstraction layer.
Implementing architecture tests to prevent the reintroduction of the old Product entity in the Bar application.
Eliminating all direct database queries within the Bar codebase that previously performed SQL JOINs to the PRODUCT table.
The first successful production migration of a Bar service to the ProductAPI.

Key Takeaways and Lessons Learned

Our journey through this large-scale refactoring provided several invaluable lessons that are applicable to similar complex projects:

Branch by Abstraction is Indispensable for Critical Systems: For high-traffic, continuously deployed applications, the incremental, low-risk nature of Branch by Abstraction is a powerful enabler for significant architectural changes without disruption.
Enforcement through Architectural Tests is Key: Tools like ArchUnit are not just helpful; they are essential for preventing regressions and maintaining newly established architectural boundaries. Without them, the carefully built seams can easily fray.
Proactive Resilience Pays Off: Integrating resilience patterns (like Resilience4j’s circuit breakers and retries) from the outset for new external API calls is non-negotiable. It protects the system from transient network issues and external service instability.
Custom A/B Testing Facilities are Strategic Assets: For deep, internal refactoring where external tools might not suffice, investing in a custom, controlled A/B testing harness that can verify results in production while shielding end-users is incredibly powerful for de-risking deployments.
Small Victories Fuel Long Journeys: Large, multi-month projects can be draining. Recognizing and celebrating intermediate achievements, even seemingly minor ones, keeps the team engaged, motivated, and focused on the long-term goal. It can be as simple as bubbles or cinnamon rolls in team retrospective.
Continuous Evaluation of Trade-offs: Even with a clear strategy, the path evolves. Regularly reassessing the risk-vs-speed trade-off (e.g., for subsequent A/B testing) ensures agility and efficiency.

This refactoring has significantly modernized our architecture, improved our data access patterns, and laid a solid foundation for future development, all while maintaining the stability required by a critical 24/7 service.

Disclaimer: The content and ideas expressed in this blog post are entirely my own. However, Solita FunctionAI was utilized for grammar, spelling and stylistic review, and ChatGPT was used for visualizations.

Using Model-View-ViewModel pattern for UI development in 2025

open@solita.fi (Solita Oy) — Fri, 21 Nov 2025 00:00:00 +0000

In this blog post we will see how Model-View-ViewModel UI design pattern can be used with different JavaScript, TypeScript, and .NET Core UI frameworks that are used today in many projects.

MVVM design pattern consists of three connected layers, where topmost is View, that has connection with data binding to ViewModel, which handles Model preparation and needed UI tasks for presenting the data in UI. Models can be data bound to UI like ViewModels. Models are data and domain representations of the actual domain or data models like data entities, or just conceptual models that are connected in example to REST API controllers and/or repositories. In theory, model can contain more information than is stored in the single data entity.

For the current state of the view for MVVM usage, and available up-to-date frameworks, Microsoft 365 Copilot was used. Copilot provided information about currently available MVVM supporting JavaScript and TypeScript frameworks for UI development. M365 Copilot provided a list of available alternatives for JS and TS MVVM usage, which was compared against already outdated not very well supported Knockout.js framework, that is most pure implementation of MVVM supporting frameworks for JS and TS. Currently available and popular MVVM JS and TS frameworks included Vue.js, Angular, and React, of which React does not really support MVVM design pattern.

For .NET Core based UI projects, there are two examples for MVVM use from original Windows Presentation Foundation (WPF) MVVM Windows application framework to newer Blazor ASP.NET Core framework, which both can use the same ViewModels and Models, and create different View layer implementations for the different environments, web and desktop app. Both .NET Core UI framework implementations support data binding to ViewModels and Models.

Model-View-ViewModel pattern

Model-View-ViewModel pattern was introduced for Windows Presentation Foundation (WPF) use in .NET and was also designed in 2005 for HTML use. In this design pattern the UI design is differentiated from program code as XAML or HTML layer, where UI design can be changed without changing the ViewModel or Model code.

From earlier experience, this kind of design is very useful when developer or designer wants to create different views of the same ViewModel and Models, like product list view, product overlay view, and product details view. All these views can use same ViewModel and Model implementations, and view can be totally different and contain all or part of the commands created for domain logic.

MVVM pattern uses commands to execute domain commands that are not directly attached to UI. Commands can have parameters, that are used to filter data from ViewModel state and make changes to data storage or do other kind of domain logic functionalities. Command pattern also makes it possible to use Command Query Responsibility Segregation (CQRS) design pattern that differentiates command execution and queries by using concepts like Write model and Read model, which both can reside in different service interfaces. Also, Read model can be seperated data store from write store when using Event-driven architecture like Azure Event Hub event data streaming service.

MVVM also uses data-binding that can be done with one way, one way to source, or two-way data-binding modes, where all changes in example to product name field, are updated to other places and views that have data-binding to the same Model. Different frameworks support different modes of data-binding.

JavaScript and TypeScript MVVM support in detail

When asking guidance from M365 Copilot, Copilot provided following diagram about MVVM usage for different JS and TS UI frameworks.

Knockout.js and Vue.js provide possibility to create ViewModels, Views, and Models for MVVM style based application. Angular has components model, which is replacing ViewModel, but works similarly.

Below is a table that was provided by GitHub Copilot, that describes the MVVM support for different UI frameworks.

Framework	MVVM Support	Data Binding	Notes
Knockout.js	Yes	Two-way	Pure MVVM, less maintained
Vue.js	Partial	Two-way	Uses ViewModel-like pattern
Angular	Partial	One/two-way	Uses components, not pure MVVM
React	No	One-way	Follows MV* patterns

Table shows that Knockout.js has been used more in earlier years, is not maintained so well anymore. From second and third options, in example Vue.js is a framework that can be used to create MVVM applications client side in TypeScript or JavaScript with up-to-date framework library.

Knockout.js, Vue.js and Angular provide possibility to use Two-way data-binding. Because React is not MVVM supporting framework, the usage of React is not the main concern in this blog post.

.NET Core MVVM support in detail

Below GitHub Copilot has created diagram that describes two .NET Core based case examples with WPF Windows application and Blazor Web application that are using MVVM pattern.

In past projects, there have been successful experiences about creating two user interface projects with same ViewModel library, like it is shown in the above diagram. This means that same business logic, and same UI logic can be used in Windows application and in Web applications with Blazor and WPF.

Framework / UI Type	MVVM Support	Data Binding	Shared ViewModel/Model Support	Notes
WPF	Yes	One-way, Two-way	Yes	Native MVVM, strong XAML binding
Blazor	Yes	One-way, Two-way	Yes	MVVM by convention, supports shared logic

Both UI frameworks for .NET Core support MVVM design style project fully. In this example case it is also possible to use both for same business case, if native workstation application and web application both are needed, in example in transition phase.

Experimentation code examples

For this blog post M365 Copilot provided code examples for JavaScript UI frameworks, for View, ViewModel, and Model layers, and for different pages in the application.

Knockout.js (Outdated pure MVVM example)

Below we can see product UI example code that was created for Knockout.js by M365 Copilot.

View (pages and single overlay view)

<!DOCTYPE html>
<html>
<head>
  <title>Knockout MVVM Example</title>
  <script src="https://cdnjs.cloudflare.com/ajax/libs/knockout/3.5.1/knockout-min.js"></script>
</head>
<body>
<div data-bind="if: currentView() === 'list'">
  <h1>Product Catalog</h1>
  <div class="product-grid" data-bind="foreach: products">
    <div class="product-card">
      <h3 data-bind="text: name"></h3>
      <p>Price: <span data-bind="text: price"></span></p>
      <p>Discounted: <span data-bind="text: discountedPrice"></span></p>
      <button data-bind="click: $parent.showOverlay">Quick View</button>
      <button data-bind="click: $parent.goToProductPage">View Page</button>
    </div>
  </div>
  <div class="overlay" data-bind="visible: selectedProduct">
    <div>
      <h2 data-bind="text: selectedProduct().name"></h2>
      <p data-bind="text: selectedProduct().description"></p>
      <p>Original Price: <span data-bind="text: selectedProduct().price"></span></p>
      <p>Discounted Price: <span data-bind="text: selectedProduct().discountedPrice"></span></p>
      <button data-bind="click: closeOverlay">Close</button>
    </div>
  </div>
</div>
<div data-bind="if: currentView() === 'product'">
  <h1 data-bind="text: selectedProduct().name"></h1>
  <p data-bind="text: selectedProduct().description"></p>
  <p>Price: <span data-bind="text: selectedProduct().price"></span></p>
  <p>Discounted: <span data-bind="text: selectedProduct().discountedPrice"></span></p>
  <button data-bind="click: goBack">Back to List</button>
</div>
<script src="app.js"></script>
</body>
</html>

In this example, there is single page application MVVM View HTML code for Knockout.js application. This code contains 3 different Views Product list page, Product details page, and product overlay page.

ViewModel and Model

function Product(name, price, description) {
  var self = this;
  self.name = name;
  self.price = ko.observable(price);
  self.description = description;
  self.discountedPrice = ko.computed(function() {
    let numericPrice = parseFloat(self.price().replace('$', ''));
    return '$' + (numericPrice * 0.9).toFixed(2);
  });
}

function ProductListViewModel() {
  var self = this;
  self.products = ko.observableArray([
    new Product("Laptop", "$1200", "High-end laptop"),
    new Product("Phone", "$800", "Latest smartphone"),
    new Product("Tablet", "$500", "Portable tablet")
  ]);

  self.selectedProduct = ko.observable(null);
  self.currentView = ko.observable('list');

  self.showOverlay = function(product) { self.selectedProduct(product); };
  self.closeOverlay = function() { self.selectedProduct(null); };
  self.goToProductPage = function(product) { self.selectedProduct(product); self.currentView('product'); };
  self.goBack = function() { self.currentView('list'); self.selectedProduct(null); };
}

ko.applyBindings(new ProductListViewModel());

In the above example of the Knockout.js MVVM Product list ViewModel and Product Model, there is M365 Copilot generated version of the design pattern implementation. This example uses same Product Model for all the three views, product list rows, product details page, and for product overlay page for quick views from product list rows to details.

Vue.js (Up to date MVVM example)

Below we can see product UI example code that was created for Vue.js by M365 Copilot.

View (pages and single overlay view)

<!doctype html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>Vue Example</title>
    <style>
      /* minimal styles to keep layout from breaking */
      .product-grid { display: flex; gap: 12px; }
      .product-card { border: 1px solid #ccc; padding: 12px; width: 200px; }
      .overlay { position: fixed; top: 20%; left: 20%; background: white; padding: 20px; border: 1px solid #333; }
    </style>
  </head>
  <body>
    <!-- view layer: mount target and router view -->
    <div id="app">
      <router-view></router-view>
    </div>

    <!-- Move templates into the HTML view layer -->
    <template id="product-list-template">
      <div>
        <h1>Product Catalog</h1>
        <div class="product-grid">
          <div class="product-card" v-for="p in products" :key="p.name">
            <h3></h3>
            <p>Price: $</p>
            <p>Discounted: $</p>
            <button @click="showOverlay(p)">Quick View</button>
            <button @click="goToProductPage(p)">View Page</button>
          </div>
        </div>
        <div v-if="selectedProduct" class="overlay">
          <h2></h2>
          <p></p>
          <p>Original Price: $</p>
          <p>Discounted Price: $</p>
          <button @click="closeOverlay">Close</button>
        </div>
      </div>
    </template>

    <template id="product-page-template">
      <div>
        <h1></h1>
        <p></p>
        <p>Price: $</p>
        <p>Discounted: $</p>
        <button @click="$router.push('/')">Back to List</button>
      </div>
    </template>

    <!-- include Vue + VueRouter from CDN (or use your local builds) -->
    <script src="https://unpkg.com/vue@3/dist/vue.global.prod.js"></script>
    <script src="https://unpkg.com/vue-router@4/dist/vue-router.global.prod.js"></script>
    <script src="./app.js"></script>
  </body>
</html>

In this example, there is single page application MVVM View HTML code for Vue.js application. This code contains 3 different Views Product list page, Product details page, and product overlay page.

ViewModel and Model

// ...existing code...
const Product = (name, price, description) => ({ name, price, description });
const products = [
  Product("Laptop", 1200, "High-end laptop"),
  Product("Phone", 800, "Latest smartphone"),
  Product("Tablet", 500, "Portable tablet")
];

const ProductList = {
  template: '#product-list-template',
  data() { return { products, selectedProduct: null }; },
  methods: {
    showOverlay(p) { this.selectedProduct = p; },
    closeOverlay() { this.selectedProduct = null; },
    goToProductPage(p) { this.$router.push({ name: 'product', params: { name: p.name } }); }
  }
};

const ProductPage = {
  template: '#product-page-template',
  computed: {
    product() { return products.find(p => p.name === this.$route.params.name); }
  }
};

const routes = [
  { path: '/', component: ProductList },
  { path: '/product/:name', name: 'product', component: ProductPage }
];

const router = VueRouter.createRouter({ history: VueRouter.createWebHashHistory(), routes });
const app = Vue.createApp({});
app.use(router);
app.mount('#app');

In the above example of the Vue.js MVVM Product list and ProductPage ViewModels and Product Model, is M365 Copilot generated version of the design pattern implementation. This example uses same Product Model for all the three views, product list rows, product details page, and for product overlay page for quick views from product list rows to details. In this M365 Copilot generated version for Vue.js, the pages have their own dedicated ViewModels, which can reuse the same Model implementation, and could also use same product ViewModel implementation for product specific UI functionalities.

React (not MVVM example)

Below we can see product UI example code that was created for React by M365 Copilot. This example is not following the MVVM design that was shown for Vue.js and for Knockout.js frameworks before. This example can be used to see differences in the UI implementation between MVVM based design and React design.

View (Single page application HTML code)

<!DOCTYPE html>
<html>
<head>
  <title>React MVVM Example</title>
  <script src="https://unpkg.com/react@18/umd/react.development.js"></script>
  <script src="https://unpkg.com/react-dom@18/umd/react-dom.development.js"></script>
  <script src="https://unpkg.com/react-router-dom@6/umd/react-router-dom.development.js"></script>
  <style>
body { font-family: Arial, sans-serif; margin: 20px; }
.product-grid { display: flex; gap: 10px; flex-wrap: wrap; }
.product-card { border: 1px solid #ccc; padding: 10px; width: 150px; }
.overlay { position: fixed; top: 20%; left: 30%; background: #fff; border: 1px solid #333; padding: 20px; }
button { margin-top: 10px; }
</style>
</head>
<body>
<div id="root"></div>
<script src="app.js" type="text/babel"></script>
<script src="https://unpkg.com/@babel/standalone/babel.min.js"></script>
</body>
</html>

In this example, there is single page application View HTML code for React application. In React, this HTML page does not contain all of the MVVM design based views, like Vue.js and Knowckout.js examples did.

View, ViewModel, and Model

const { BrowserRouter, Routes, Route, useNavigate, useParams } = ReactRouterDOM;

const products = [
  { name: "Laptop", price: 1200, description: "High-end laptop" },
  { name: "Phone", price: 800, description: "Latest smartphone" },
  { name: "Tablet", price: 500, description: "Portable tablet" }
];

function ProductList() {
  const navigate = useNavigate();
  const [selectedProduct, setSelectedProduct] = React.useState(null);

  return (
    <div>
      <h1>Product Catalog</h1>
      <div className="product-grid">
        {products.map(p => (
          <div key={p.name} className="product-card">
            <h3>{p.name}</h3>
            <p>Price: ${p.price}</p>
            <p>Discounted: ${(p.price * 0.9).toFixed(2)}</p>
            <button onClick={() => setSelectedProduct(p)}>Quick View</button>
            <button onClick={() => navigate(`/product/${p.name}`)}>View Page</button>
          </div>
        ))}
      </div>
      {selectedProduct && (
        <div className="overlay">
          <h2>{selectedProduct.name}</h2>
          <p>{selectedProduct.description}</p>
          <p>Original Price: ${selectedProduct.price}</p>
          <p>Discounted Price: ${(selectedProduct.price * 0.9).toFixed(2)}</p>
          <button onClick={() => setSelectedProduct(null)}>Close</button>
        </div>
      )}
    </div>
  );
}

function ProductPage() {
  const { name } = useParams();
  const navigate = useNavigate();
  const product = products.find(p => p.name === name);

  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <p>Price: ${product.price}</p>
      <p>Discounted: ${(product.price * 0.9).toFixed(2)}</p>
      <button onClick={() => navigate('/')}>Back to List</button>
    </div>
  );
}

function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route path="/" element={<ProductList />} />
        <Route path="/product/:name" element={<ProductPage />} />
      </Routes>
    </BrowserRouter>
  );
}

ReactDOM.createRoot(document.getElementById('root')).render(<App />);

In this React application example Product list and Product details pages are separated as own pages with functional design pattern. Overlay product view is included in the product list page function code, and not separated from as its own template here, when M365 Copilot was the one that generated this example. There can be ways to detach the overlay view from the page view, to its own function, but for this blog post, React is not the main concern, because MVVM support is not available in React applications.

Conclusion

When using MVVM design pattern in 2025 it is still possible to use up-to-date UI frameworks for development and create multi-UI applications with same business logic and UI logic layers.

When separating XAML markup (WPF), and HTML and CSS (JS and TS) there are many possibilities for using already existing UI logic and business logic, and creating updated UI designs, without a need for updating the code that is critical for the business.

When comparing these three code examples, the MVVM based applications and ViewModels and Models of these examples need no changes when updating the HTML or CSS for the UI, and if UI logic does not change, this MVVM based approach can provide possibility to do UI design changes without JavaScript or TypeScript coding skills.

Based on experiences from many projects where MVVM design pattern has been used, it has been easy way for maintaining the UI logic and business logic behind the actual UI markup code. Also, different assemblies can be used to extract the ViewModel and Model logic from the View layer in .NET Core project level. This also makes it possible to create new UI View layers for old applications, or creating different View layer projects for different platforms, like MacOS or other operating systems etc.

Speed Up Data Processing in Node with p-limit and Worker Threads

open@solita.fi (Solita Oy) — Tue, 18 Nov 2025 00:00:00 +0000

When I started writing this blog post, I realized that Node.js is now a teenager — at that age I was setting up my first website with PHP and only thinking about becoming a software developer. Back then, Node.js was created to let web servers use JavaScript, the same language powering websites. While Node.js is well-suited for I/O driven web servers, it faces challenges with CPU-intensive computations due to its single-threaded event loop. When heavy computations run on the main thread, they can block other events and degrade overall performance.

In this blog post, we’ll explore practical strategies to accelerate a real-world Node application that reads several large JSON files from disk, processes their contents, and outputs the results as a large number of smaller JSON files. We’ll introduce two powerful Node.js tools: p-limit library for managing concurrent I/O operations, and worker_threads for parallelizing CPU-bound tasks. By combining these techniques, we can significantly reduce processing time and make Node applications more scalable.

Limiting Factors in Node

To make sense of how to optimize performance in Node.js, it is essential to first understand the underlying limitations. At its core, Node.js is built on the V8 JavaScript engine, which provides high-speed execution of JavaScript code, but even highly optimized code cannot match the speed of native code. This means that Node.js is hardly the fastest tool available for raw data processing, so why use it for that in the first place? Well, it is a natural choice for handling JSON-based data due to its native support for JavaScript and rich node_modules ecosystem. It’s also a widely used tool and can be easily picked up by virtually any web developer.

Node’s architecture is fundamentally event-driven and single-threaded. This works fine for most web interfaces and servers, but can be seen as a limitation for pure data processing. In simple terms, single-threaded means that only a single JavaScript event or function can be on execution at a time. Even if you put your code in a Promise-returning function, its synchronous parts are still run sequentially and block the event loop from executing other tasks. Luckily, Node.js is still efficient for handling I/O operations such as reading/writing files and handling network traffic. These operations are delegated to run by the underlying system (mainly libuv thread pool) and thus do not overload Node’s main event loop.

To optimize our Node process, we are going to maximize the performance of parallel I/O operations and also parallelize CPU-bound operations. How much of an increase can we expect? It’s difficult to give a precise prediction, as it largely depends on the use case. In our case, we start with a processing time of about 40 seconds. Let’s see how much we can improve it.

Processing Data Overview

Let’s begin with a simple example of processing data and writing the result to the disk:

for (const file of files) {
  const result = await processData(file);
  await fs.promises.writeFile(result.path, result.data); // I/O operation, handled by libuv
}

Each file is processed and written to the disk one-by-one. This is simple and straightforward, and if it’s fast enough for you, you could stop reading here. Otherwise, we can see that this code is not very efficient since we are only either processing data or waiting for the write operation to complete. Let’s improve it by running the write operation in the background:

for (const file of files) {
  const result = await processData(file);
  fs.promises.writeFile(result.path, result.data); // no await here, let it run in background
}

Here we do not wait for file writing to complete, but schedule it and immediately continue processing the next file. However, error checking is still missing and we do not wait for those background operations to complete. Let’s fix it:

const writePromises = [];

for (const file of files) {
  const result = await processData(file);
  const p = fs.promises.writeFile(result.path, result.data);
  writePromises.push(p);
}

// Data processing done, wait for all write operations to successfully complete. This throws an exception if even one write failed.
await Promise.all(writePromises);

This looks better from performance perspective as we are now doing more than one thing at a time, but the gained performance highly depends on how fast processData is compared to file writing. If it’s slow, we might not gain much benefit at all. We also have a potential memory problem since we are queuing up all write operations to libuv at once. If result is large and there are many files to process, this could lead to high memory peaks. While libuv has some limits of how many write operations it does in parallel by default, the remaining operations are still put into queue. Let’s see if we can improve this further using p-limit.

p-limit

p-limit is a lightweight library for controlling concurrency in asynchronous operations. In other words, it can be used to easily limit the number of I/O-bound promises running simultaneously. The emphasis is on the word I/O-bound; p-limit does not help with CPU-bound tasks since it does not magically make JavaScript multi-threaded.

Going back to our previous example, what we actually want to do is to run multiple file write operations in parallel and in the background, but avoid running too many to cause high memory peaks. p-limit solves this for us by allowing to specify the maximum number of concurrently run promises.

The right amount of concurrent operations depends on the use case and the capability of the underlying hardware. I would suggest beginning with a value of 2-6 and finding the sweet spot manually by testing with real-world data.

Let’s take a look at how to use p-limit, first doing it incorrectly.

import plimit from "p-limit";
const limit = plimit(4); // Allow up to 4 concurrent operations
const tasks = [];

// Naive example: assuming that files come from somewhere and `processFile` is implemented somewhere
for (const file of files) {
  const result = await processData(file);
  // BAD! Memory peak can still occur here.
  const task = limit(() => fs.promises.writeFile(result.path, result.data));
  tasks.push(task);
}

// Wait for all writes to complete
await Promise.all(tasks);

In this example, we are limiting the total number of simultaneous file operations, but we are NOT limiting calls to processData. This means that eventually all finished result objects would be queued to p-limit, potentially causing high memory peaks if the result object is large.

The can be solved by limiting both data processing and file writing:

import plimit from "p-limit";
const limit = plimit(4);
const tasks = [];

for (const file of files) {
  const task = limit(async () => {
    const result = await processData(file);
    return fs.promises.writeFile(result.path, result.data);
  });

  tasks.push(task);
}

// Wait for all processing + writes to complete
await Promise.all(tasks);

This is starting to look good as we are now allowing parallel data processing and file writing while still setting a limit of how many result objects can be created at once. Again, the gained performance largely depends on the relative speed of processData and file writing. In our case, this trick decreased the processing time from 40 seconds to about 30 seconds.

p-limit with Pending Queue

Let’s assume there are so many files to be processed that we need to divide them into multiple different processing functions. This would mean that we needed to use p-limit on multiple different places, possibly losing a track of overall concurrency and memory usage. Each plimit instance only controls the tasks submitted to it, not the total number of tasks running across all instances. This can easily lead to more tasks executing simultaneously than intended.

To manage this safely, we could use a single global concurrency limiter that all processing functions use, ensuring the total number of active heavy tasks never exceeds your safe threshold. Note that this method might not give actual performance benefits, but it helps to keep memory usage more predictable across the whole application.

Here is an example of introducing a centralized write queue using a single instance of plimit. When data has been processed, it can be queued for writing via enqueueWriteToFile function. This queue is allowed to hold no more than eight pending write operations, setting a clear limit for memory usage in the whole application. If the pending queue is full, the caller is forced to wait until there is free capacity available. Finally, up to four write operations are allowed to run in parallel.

import { promises as fs } from "fs";

import plimit from "p-limit";

const MAX_ITEMS_IN_PENDING_QUEUE = 8; // Allow up to 8 operations to wait in the queue
const writePool = plimit(4); // Allow up to 4 concurrent operations
const pendingWrites = new Set();

interface DataFile {
  path: string,
  data: string
}

function waitForFreeCapacityInPendingQueue() {
  return new Promise((resolve) => {
    const check = () => {
      if (writePool.pendingCount < MAX_ITEMS_IN_PENDING_QUEUE) {
        resolve(undefined);
      } else {
        // Wait until pending queue is free
        setTimeout(check, 10);
      }
    };

    check();
  });
}

async function enqueueWriteToFile(file: DataFile) {
  // Main thread waits here if pending queue is full
  await waitForFreeCapacityInPendingQueue();
  // Schedule the write operation and continue processing
  const task = writePool(() => fs.writeFile(file.path, file.data));
  pendingWrites.add(task);
  task.finally(() => pendingWrites.delete(task));
}

async function waitForFileWritesToComplete() {
  await Promise.all([...pendingWrites]);
}

async function main() {
  for (const file of importantFiles) {
    const processed = await processFile(file);
    await enqueueWriteToFile(processed)
  }

  for (const file of moreImportantFiles) {
    const processed = await processFile(file);
    await enqueueWriteToFile(processed)
  }

  await waitForFileWritesToComplete();
}

We have now solved the problem of running both data processing and file writing in parallel while also avoiding high memory peaks by limiting the number of pending write operations. However, we are still processing data sequentially, one file at a time. To make this more efficient, we are going to look at worker_threads module next.

Worker Threads

Node.js has worker_threads module, which enables true parallelism by running code inside Workers. This practically frees us from the single-threaded limitation of Node. Hooray, all performance problems solved! But there is a catch: running code in a worker is kind of like running another Node inside Node. Each worker has its own execution context, call stack, heap memory and event loop. This makes worker threads completely separated and also requires some effort to setup.

Since running a task in a Worker requires its own “Node”, initialising a Worker practically requires initialising it with its own script. Here is a simplified example:

First, we create the worker file and import processData from the main application:

// worker_types.ts
interface DataFile {
  path: string,
  data: string
}

// worker.ts
import { workerData, parentPort } from "node:worker_threads";
import { processData } from "data/process";
import { DataFile } from "./worker_types";

async function runWorker() {
  // Params from main thread
  const params = workerData as DataFile;
  const result: DataFile = await processData(params);
  // Send result back to the main thread
  parentPort?.postMessage(result);
}

// Run the worker
runWorker().catch(err => {
  parentPort?.postMessage({ error: err.message });
});

We can compile this worker using esbuild, with a command like this: npx esbuild src/worker.ts --bundle --outdir=dist --format=esm --platform=node.

Finally, we call the worker from the main thread:

// main.ts
import { fileURLToPath } from "node:url";
import { Worker } from "node:worker_threads";
import * as path from "path";

import { DataFile } from "worker_types";
import { enqueueWriteToFile } from "io/write_queue"; // From previous p-limit example

const filename = fileURLToPath(import.meta.url);
const dirname = path.dirname(filename);

function runWorker(params: DataFile) {
  return new Promise((resolve, reject) => {
    const worker = new Worker(path.join(dirname, "worker.js"), {
      workerData: params,
    });

    worker.on("message", async (result) => {
      console.log("Result from worker:", result);
      await enqueueWriteToFile(result);
      resolve();
    });

    worker.on("error", reject);
    worker.on("exit", (code) => {
      if (code !== 0)
        reject(new Error(`Worker stopped with exit code ${code}`));
    });
  });
}

async function main() {
  // Assuming file comes from somewhere
  const workerPromise = runWorker(file);
  
  console.log("Worker started, main thread is still responsive.");

  await workerPromise;
  console.log("Worker finished!");
}

This example shows how to offload a single computation from main thread to a dedicated worker while allowing main thread to be responsive and continue handling other tasks without being blocked. While this method works, it requires us to manually initialise a new Worker every time we want to process something in parallel. Also, the worker must be tuned to handle different data processing tasks. This process can be simplified by using a library called workerpool.

Worker Pool

Here is a simplified example of what workerpool looks like. First, we create a worker file which exposes the functions it can execute:

// worker.ts
import { processData } from "data/process"
import { DataFile } from "worker_types";

const workerpool = require('workerpool'); // Must use require

async function processDataFile(file: DataFile) {
  return await processData(file);
}

// Expose what functions this worker can execute
workerpool.worker({
  processDataFile,
});

Main looks like this:

// main.ts
const workerpool = require('workerpool');
import { DataFile } from "worker_types";
import { enqueueWriteToFile } from "io/write_queue";

const filename = fileURLToPath(import.meta.url);
const dirname = path.dirname(filename);

// Create a worker pool with as many workers as there are logical CPU cores
const pool = workerpool.pool(dirname + '/worker.js', {
  maxWorkers: require("os").cpus().length,
});

async function main() {
  try {
    // Assuming file comes from somewhere
    const result = await pool.exec("processDataFile", [file]);
    await enqueueWriteToFile(result);
  } catch (err) {
    console.error(err);
  }

  // Terminate all workers when everything is done
  pool.terminate();
}

workerpool takes the implementation of creating and calling workers to a higher abstraction level, simplifying code and also making it more efficient since workerpool keeps a pool of workers “warm”, ready to be used for offloading multiple long-running computations in the background. No need to manually create them every time.

In the above examples, we have offloaded only a single data processing task to the worker pool, but naturally we want to process all data in parallel. However, in heavily parallelized applications, we have to be careful of not offloading and queueing too many operations to workers at once and thus (again) introducing potential memory peaks - just like we need to be cautious with queuing too many I/O operations. Thus, I would be careful of calling pool.exec for every file at once since it could cause worker pool queue to overload of file parameters.

Worker Pool with Pending Queue

If one needs to limit the number of worker tasks to be queued, we would need to use some kind of pending queue to force the main thread to wait for a free worker to be available. A simplified example would look something like this:

const pendingTasks = new Set();
let queuedTasksCount = 0;

function waitForFreeWorker() {
  return new Promise((resolve) => {
    const check = () => {
      if (pendingTasks.size < NUMBER_OF_WORKERS) {
        resolve(undefined);
      } else {
        setTimeout(check, 10);
      }
    };
    check();
  });
}

async function enqueueWorkerTask(config: WorkerParams) {
  // Wait until there is a free worker available in the pool.
  await waitForFreeWorker();
  const task = pool.exec(config.task, [config.params]);
  pendingTasks.add(task);
  
  task.finally(() => {
    console.log("Worker task completed:", config.task);
    pendingTasks.delete(task);
  });
}

async function waitForWorkerTasksToComplete() {
  await Promise.all([...pendingTasks]);
  await pool.terminate();
}

By using a worker pool and p-limit together, we were able to reduce the total processing time from original 40 seconds down to about 14 seconds! This is a significant improvement, though it comes with increased code complexity and memory usage since each worker has its own memory space and we are keeping processed results in memory until they are written to disk.

Tips for Working with Workers

Whether you decide to use workerpool or implement your own solutions, here are a couple of tips I wish I had known when I started working with Workers:

You are free to import stuff from your main application code to your worker, but everything you import gets compiled in the final worker.js. This can result in large bundles and potentially unwanted code if not done carefully. For example, if you introduce a worker pool in your main application code, and you accidentally import some code from there in your worker, every worker gets its own worker pool. Probably not what you want. This can be avoided by doing import { isMainThread } from "worker_threads" and checking if isMainThread is false when ever something should never be imported by a worker.
Worker’s JS code must be built separately every time you modify it and always before running tests (I’m not happy remembering spending a day figuring out why some changes in my worker code did not do anything). If you use Vitest, you can use its setup.ts file to run code like execSync("npm run build:worker", { stdio: "inherit" }); to get a fresh worker every time before running tests.
Worker threads have their own isolated memory and cannot reference objects from the main thread (okay, there is SharedArrayBuffer, but it’s a bit advanced concept). When you instantiate a worker and pass in some parameters, these parameters are passed by value (i.e. structured clone), not by reference. Thus, one needs to be careful about high memory peaks when using workers.

Conclusion

Here is a quick summary of the tools we covered:

p-limit is ideal for managing concurrency in I/O-bound tasks, such as reading or writing files and making HTTP requests. By limiting the number of simultaneous operations, you prevent resource exhaustion and avoid hitting system limits. The code is only slightly more complex than standard async code, making p-limit a practical choice for many I/O-heavy workloads.

worker_threads is designed for CPU-bound tasks that would otherwise block the event loop, virtually any heavy data processing. Worker threads run in parallel, leveraging multiple CPU cores for true concurrency. However, using worker threads increases code complexity and memory usage, as each worker has its own execution context. Using it also requires some planning of how to actually divide complex computation into workers effectively and may not be sensible if tasks depend on each other. For heavy parallel data processing, I recommend taking a look at workerpool library.

Both p-limit and worker_threads are powerful tools for improving Node.js performance, but they serve different purposes and come with trade-offs. Even if these tools allow us to maximize performance by running things in parallel, one needs to be mindful of not fulfilling memory with a queue of tasks or cpu with too many simultaneous workers. Using either or both tools always increases code complexity and memory usage, potentially crashing your application if not managed carefully. Thus, it’s important to evaluate whether the performance gains justify these costs for your specific use case.

C-ing the web part 2, Lambda boogaloo

open@solita.fi (Solita Oy) — Fri, 14 Nov 2025 00:00:00 +0000

Last time we implemented a simple front end application in C and compiled it to run in the browser using via WebAssembly.

Now, let’s consider the back end. The traditional way would be to run a C application in a web server like Apache httpd using the Common Gateway Interface. Instead of doing that, let’s run our C code inside AWS Lambda using the custom runtime support.

With a custom runtime, you can create serverless functions using any language. The custom runtime bootstrap is based on a simple loop that uses HTTP API to:

issue a GET request to fetch the next invocation
pass it on to the handler for processing
issue a POST request to send a response (or an error) back to the client
repeat

To follow along or just try the code yourself, check out the code from the clambda repo.

Getting a proper image

To make a custom runtime, we need to compile our C code in an environment that is compatible with the AWS Lambda image.

The easiest way to do this is to just make our own Docker image for building:

FROM amazonlinux:2
RUM yum groupinstall -y "Development Tools" && yum install -y libcurl-devel
ENTRYPOINT ["/opt/clambda/build.sh"]

We start with the Amazon Linux image, install development tools and cURL headers to it. We will run this image to build both the bootstrap and the handler code. Note that if you are running on Apple architecture, you should specify --platform=linux/amd64 to Docker so that you are building for the correct environment.

For local testing, we also want to build a runtime image. We start with the provided image and copy both the bootstrap and compiled handlers to it.

FROM public.ecr.aws/lambda/provided:al2023
COPY bootstrap ${LAMBDA_RUNTIME_DIR}
COPY *.o ${LAMBDA_RUNTIME_DIR}

Designing the API

We need some way for our bootstrap to hand off requests to the handler, and we want it to be minimal and feel natural from C.

I came up with a simple function interface:

typedef struct Invocation {
  uint8_t *payload; // the JSON payload, NUL terminated
  size_t size; // size of payload, not counting NUL byte

  // File handle to write the response to
  FILE *out;

  void *user_data;
} Invocation;

// optional _init fn to initialize user_data
void *handle_init();

// the handler itself
bool handle(Invocation *inv);

The handler code may provide an initialization function that is named by appending _init to the handler name. The initialization function returns an arbitrary user data pointer that is passed along in all invocations. This can be used to initialize any libraries or state needed in the actual invocations. The initialization is only called once before handling any events.

The handler itself takes a pointer to an invocation that contains the received data as a raw pointer and a file pointer for writing output.

The incoming data is not parsed in any way; it is up to the handler to make sense of it, like parsing JSON. See next part.

The output is simpler, the handler doesn’t need to allocate memory buffers, the bootstrap will provide a FILE* handle so the handler can simply call functions like fprintf to write output. Handler can also set the content type.

Finally, if the handler returns false, the handler is considered failed and an error reply is sent.

The bootstrap will load the handler code via a shared library. The handler only needs to include the clambda.h header file and implement the function.

Working with JSON

As Lambda is mainly for receiving and sending JSON, we should provide some facilities for working with it. C doesn’t really have data structures like objects built in, and manual memory management makes this more awkward.

Luckily JSON (as defined by ECMA-404) is quite a simple format. We can write our own code to extract data from it. For memory management, especially strings, we can modify and return pointers to the input buffer directly. Those will be valid for the duration of the Lambda handler.

We can use some C preprocessor macro magic to make extracting object fields to C structs a little more convenient. See json.h file in the repo for more details. This on-demand extraction obviates the need to parse the JSON data fully into an in-memory representation. We can just directly grab what we need from it.

Here’s an example for extracting a JSON like this:

{"id": "line1",
 "points": [{"x": 42.0, "y": 100},
            {"x": 66.2, "y": 90},
            {"x": 140,  "y": 123.4}]}

typedef struct Point {
  double x, y;
} Point;

typedef struct Line {
  char *id;
  size_t npoints;
  Point *points;
} Line;

bool parse_point(char **at, Point *p) {
  json_object(at, {
    json_field("x", json_double, &p->x);
    json_field("y", json_double, &p->y);
  });
  return true;
}

bool parse_points(char **at, Line *line) {
  json_array(at, &line->points, &line->npoints, Point, parse_point);
  return true;
}

bool parse_line(char **at, Line *line) {
 json_object(at, {
    json_field("id", json_string_ptr, &line->id);
    json_field("points", parse_points, line);
  });
  return true;
}

The above might look a little bit involved when compared to some language that has convenient generic data structures, but I like that we get the data extracted into typed structures. The json_array macro even handles dynamic size of arrays for us automatically. The application layer just needs to free any arrays at the end.

Outputting the response JSON is done with regular C formatted printing. Utilities for that are left as an exercise for the reader.

Putting it together

We have the API, the bootstrap, and even JSON parsing utilities ready. Let’s make a simple Lambda that analyzes a line and returns how many points it has and its length.

Taking the example from above and adding the handler function:

bool analyze_line(Invocation *inv) {
  char *json = (char*) inv->payload;
  char **at = &json;
  Line line = {0};
  if(!parse_line(at, &line)) return false;

  printf("Line %s has %d points\n", line.id, line.npoints);
  double len = 0;
  if(line.npoints) {
    for(int i=0; i<line.npoints-1; i++) {
      double dx = abs(line.points[i].x - line.points[i+1].x);
      double dy = abs(line.points[i].y - line.points[i+1].y);
      len += sqrt(dx*dx + dy*dy);
    }
  }
  fprintf(inv->out, "{\"npoints\": %d, \"length\": %f}",
          line.npoints, len);

  free(line.points); // remember to clean up!
  return true;
}

That’s all there is to it. To test it locally, we can build it by running the following commands:

$ make build
$ ./build-handler.sh example
$ make runtime-image
$ docker run -p 8080:8080 -t clambda/runtime example.analyze_line

# in another shell, call it:
$ curl http://localhost:8080/2015-03-31/functions/function/invocations \
       -d '{"id": "viiva", "points":[{"x": 10, "y": 10}, {"y":20, "x": 100}, {"x": 200, "y": 222}]}'
{"npoints": 3, "length": 315.951278}

See the file example.c for more examples, including a counter that keeps state between calls.

For deploying to actual AWS environment, see instructions in the AWS documentation site.

Caveat and final remarks

C is a low level language and doesn’t offer memory safety. You should carefully test any code you are exposing over the internet. There are mitigation strategies like fuzzing (using tools like radamsa), using AddressSanitizer or even compiling with the memory-safe C variant Fil-C.

The upside is that using C can give us small native code that starts up and executes fast. This makes it a good fit when you have a Lambda that needs to do some heavier processing.

Happy hacking!

/dev/solita

What happens to Code Quality and Developer Role in the AI era

Background: The Coding Janitor

The Fundamental Change

Productivity Improves

Post Scriptum

AI Summary: How Have These Predictions Held Up? (February 2026)

The Source Code

MCP: Connecting Language Models to the Real World

Introduction: What is MCP?

Architecture Overview

Real-World Applications: What Can You Build?

Knowledge Base Integration

Flight Information System (Our Example)

Multi-Source Intelligence

Implementation: Flights MCP Server

Setting Up the Environment

Let’s get prompting

Under the Hood: How MCP Works

Transport Layer

JSON-RPC: The Communication Protocol

Closing Thoughts

Further exploration

SQL Isolation Levels

Isolation in Brief

MVCC

Isolation level 1: Read Uncommitted (Dirty Read)

Isolation level 2: Read Committed

3. Isolation level: Repeatable Read

4. Isolation level: Serializable

Interlude

Read Committed and locks

Thanks and further reading

Using Generative AI tooling with Clojure

Clojure is easy to read for humans and AIs

Clojure MCP boosts Agentic development workflows

Getting AI to speak Clojure

Further reading

Prompt Engineering 101

So What’s the Problem?

Context Is Everything

Just Use Planning Mode

Prompting Is a Skill

How Not to Get Overwhelmed

Conclusion

Python in 2026: Popular As Ever, Avoided in Production

Popularity

To Use or Not To Use

When its strengths become its weaknesses

Causality vs. Python: 1–0

Final words on enlightenment

Decoupling a Legacy Spring Boot Monolith with Branch by Abstraction

Here, There, Everywhere

Our Strategy: Branch by Abstraction

Introducing the Abstraction Layer: ProductService

Decoupling Product Data from the Database

Gradual Switchover to the ProductAPI

Quality Verification

Where We Are Now

Key Takeaways and Lessons Learned

Using Model-View-ViewModel pattern for UI development in 2025

Model-View-ViewModel pattern

JavaScript and TypeScript MVVM support in detail

.NET Core MVVM support in detail

Experimentation code examples

Knockout.js (Outdated pure MVVM example)

View (pages and single overlay view)

ViewModel and Model

Vue.js (Up to date MVVM example)

View (pages and single overlay view)

ViewModel and Model

React (not MVVM example)

View (Single page application HTML code)

View, ViewModel, and Model

Conclusion

Speed Up Data Processing in Node with p-limit and Worker Threads

Limiting Factors in Node

Processing Data Overview

p-limit

p-limit with Pending Queue