Declarative search the hard way:

Building an SRU-powered Next.js tool for the
National Library of the Netherlands

Valerie Gibson — Drupal & Search Developer

Something about me

Drupal • Solr • Search • AI techniques • Vector embeddings • Semantic search • Next.js • SRU

My session isn’t so much about theory — it’s more the story of how I tried to reverse-engineer a mysterious old tool that no one really understood anymore. Kind of like digital archaeology.

So hi everyone, welcome to my talk. I am Valerie Valkenburg-Gibson. --> I live in Almere, just east of Amsterdam, and I work for a company called Finalist, where I spend most of my time building search solutions in Drupal and Solr. click twice

In short: I help people find things on the internet — which sounds simple, but anyone who's ever configured Solr knows it's basically equal parts search CLICK, magic, and debugging code at midnight.

I've been working with Drupal for quite a while now, building everything from editorial workflows to custom search experiences. Lately I've been exploring how traditional search — the structured, keyword-based kind — can work together with newer AI techniques click like vector embeddings click and semantic search click, to make results feel a bit more human.

Outside of work, I have a family with five children, so there's never a quiet moment — except when I manage to pick up my violin, which is my way of relaxing. Though, to be honest, in a house with that many kids, calling it practice might be optimistic.

What I enjoy most in my work is the thinking part — figuring out how data moves, how queries turn into results, and how we can express intent in a way that systems actually understand.

And that curiosity led me to the project I'll talk about today — a modern web tool for the National Library of the Netherlands, built in Next.js click, that communicates directly with their old but wonderfully declarative SRU click endpoint.

It's a mix of old protocols, new frameworks, and a lot of "how on earth do I make this work?" moments — but I'll get to that part in a moment.

When I started this project...

No experience with Next.js
No idea how SRU/CQL really worked
No documentation of the XML responses

The Challenge

The Royal Library’s SRU endpoint was old, inconsistent, and last but not least: it was undocumented.

I had to reverse-engineer the XML structure
Responses changed even for similar queries

So the challenge was: what kind of tool was this anyway? What requests did it make? It was written in PHP so far so good, that was obvious, but… which version? And could I even get it to run at all?

I ended up feeding the ZIP file to the language model I was using at the time — I hadn’t yet entered my Claude phase, because this project took place just a couple of months before the summer holidays. And, as you all know, time flies!

My language model’s clues:

The files had a copyright notice from 2008–2009.
It used Zend Framework 1.8.0, which requires PHP 5.2.0 or higher.
Conclusion: The project was written for PHP 5.2.x It can probably run on a newer PHP version (like 7.3.33), but the code itself was definitely written for PHP 5.2.0+.

To give you an idea

This is what the old tool looked like.

What is SRU?

SRU = Search/Retrieve via URL
CQL = Contextual Query Language

It’s a declarative protocol — you describe what you want, not how to get it.


  ?operation=searchRetrieve&query=title all "climate"

The Legacy Reality

In Theory	In Practice
Elegant and declarative	Inconsistent XML
Structured metadata	Missing namespaces
Simple queries	No wildcard support 😬

Reverse-Engineering the Response

Send a request manually
Inspect the XML response
Guess what each element means
Write a parser
Realize it breaks for another record type 😅

Building the Frontend

Next.js (App Router, TypeScript, Turbopack)
Direct SRU communication — no API layer
Fully declarative browsing of journals, articles, ISSN and NBNs

The design

Declarative Design

Each interaction is a CQL query – no imperative API logic.

The UI simply renders whatever the request declares.

The Beauty and the Pain

💎 Elegant	🧨 Fragile
Transparent queries	Inconsistent responses
No backend needed	No validation or schema

AI Assistants to the Rescue

Understanding CQL syntax

Generating parsing code

Debugging strange XML edge cases

AI was my pair programmer 🤖

The Double-Edged Sword

AI accelerated development but also caused new fragility:

Hallucinated XML examples
Overfitted parsing logic
False sense of completion

“AI is great at making you think you’re done.”

The final result

This is what it has become.

Lessons Learned

Declarative protocols age gracefully — but not perfectly
Documentation matters less than actual data
Reverse-engineering teaches structure awareness
AI helps — but you still need to read the XML yourself

Reflection

Declarative search isn’t new — SRU proved that years ago.

But with modern web frameworks and AI tooling, it becomes relevant again.

Any questions?

@Declarative Amsterdam 2025