So for my understanding: The nlohmann::json type is actually quite similar to icinga::Value in the sense that it contains a union to store the different types of JSON values:

Now what does the nlohmann::adl_serializer<icinga::Value> implementation you provide actually do? Doesn't that basically transform its input into a copy represented as nlohmann::json?

In other words: doesn't this just add a new copy of the JSON to potentially save a copy in another place?

Even then, it wouldn't make any sense, I mean, why would we ever want to (async)write every and each of the JSON tokens individually into an Asio stream? Instead, we can just serialize the JSON into an asio::streambuf and pass that to any Asio write methods (see 4d1a2a9 for example usages).

I don't really see how asio::streambuf helps here. Conceptually, the usage there looks pretty similar to what it would look like when using a std::stringstream. So if you did the same thing for /v1/objects/* responses, wouldn't this still allocate the full JSON at once?

why would we ever want to (async)write every and each of the JSON tokens individually into an Asio stream?

We don't want to send them to the network individually. But that sounds exactly like the situation buffered streams are made for.

Now what does the nlohmann::adl_serializer<icinga::Value> implementation you provide actually do? Doesn't that basically transform its input into a copy represented as nlohmann::json?

Well, I guess you already answered your first question. Yes, it would hold a copy of the given Value type but if we don't want to perform the low level JSON serialization stuff then we need to transform the Value class into a nlohmann::basic_json<> instance or implement a custom serializer for the Value class like how it's done previously.

So if you did the same thing for /v1/objects/* responses, wouldn't this still allocate the full JSON at once?
We don't want to send them to the network individually. But that sounds exactly like the situation buffered streams are made for.

Hm, then I will add that overload once the other questions are answered regarding how the Value type should be serialized.

if we don't want to perform the low level JSON serialization stuff then we need to transform the Value class into a nlohmann::basic_json<> instance or implement a custom serializer for the Value class like how it's done previously.

Not entirely. In the current implementation, everything ends up in m_Result which is written by barely three methods:

(AppendChar could even call AppendChars, making them only two.)

Simple enough to overload, I guess.

Well, I guess you already answered your first question. Yes, it would hold a copy of the given Value type but if we don't want to perform the low level JSON serialization stuff then we need to transform the Value class into a nlohmann::basic_json<> instance or implement a custom serializer for the Value class like how it's done previously.

Alternatively, since we're shipping the json library in this repo, we can just directly patch it to support our Value type similar to how other users of that library are doing. That way, we wouldn't have to transform the value beforehand and doesn't require us to implement a custom serializer as well.

Edit: Sorry, they don't use a patched version of the library but a newer version than that we currently use.

if we don't want to perform the low level JSON serialization stuff then we need to transform the Value class into a nlohmann::basic_json<> instance or implement a custom serializer for the Value class like how it's done previously.

Not entirely. In the current implementation, everything ends up in m_Result which is written by barely three methods:

Well, isn't that just the "or [...] like how it's done previously" part?

Alternatively, since we're shipping the json library in this repo, we can just directly patch it to support our Value type similar to how other users of that library are doing. That way, we wouldn't have to transform the value beforehand and doesn't require us to implement a custom serializer as well.

I'm not sure what to look for in the code search you've linked. Forking the library (that's basically what you're suggesting) is possible, but sounds like something I'd rather try to avoid.

I'm not sure what to look for in the code search you've linked. Forking the library (that's basically what you're suggesting) is possible, but sounds like something I'd rather try to avoid.

I've already updated my previous comment and actually they don't use a patched version of the library but they convert their custom type to the json object just like how I am doing in this PR.

Edit: Sorry, they don't use a patched version of the library but a newer version than that we currently use.

if we don't want to perform the low level JSON serialization stuff then we need to transform the Value class into a nlohmann::basic_json<> instance or implement a custom serializer for the Value class like how it's done previously.

Not entirely. In the current implementation, everything ends up in m_Result which is written by barely three methods:

Well, isn't that just the "or [...] like how it's done previously" part?

No, it's an implementation detail (to visualize the low effort).

I think, I've implemented now all the requested points in #10408 and also updated the PR description, including listing two remaining open questions. So, please have a look again!

I've now adjusted the encoder to incrementally build JSON objects and arrays, which allows for more efficient memory usage and avoids the need to store large intermediate results in memory. I've modified the ObjectQueryHandler to use this new encoder and would roughly look like this (the generated response doesn't satisfy the HTTP specification, but it gives you an idea of how the encoder works):

diff --git a/lib/remote/httpserverconnection.cpp b/lib/remote/httpserverconnection.cpp
index 17e61f160..75356479f 100644
--- a/lib/remote/httpserverconnection.cpp
+++ b/lib/remote/httpserverconnection.cpp
@@ -458,7 +458,7 @@ bool ProcessRequest(
                return false;
        }

-       http::async_write(stream, response, yc);
+       //http::async_write(stream, response, yc);
        stream.async_flush(yc);

        return true;
diff --git a/lib/remote/objectqueryhandler.cpp b/lib/remote/objectqueryhandler.cpp
index f6f049e4e..685d5d928 100644
--- a/lib/remote/objectqueryhandler.cpp
+++ b/lib/remote/objectqueryhandler.cpp
@@ -3,6 +3,7 @@
 #include "remote/objectqueryhandler.hpp"
 #include "remote/httputility.hpp"
 #include "remote/filterutility.hpp"
diff --git a/lib/remote/httpserverconnection.cpp b/lib/remote/httpserverconnection.cpp
index 17e61f160..75356479f 100644
--- a/lib/remote/httpserverconnection.cpp
+++ b/lib/remote/httpserverconnection.cpp
@@ -458,7 +458,7 @@ bool ProcessRequest(
                return false;
        }

-       http::async_write(stream, response, yc);
+       //http::async_write(stream, response, yc);
        stream.async_flush(yc);

        return true;
diff --git a/lib/remote/objectqueryhandler.cpp b/lib/remote/objectqueryhandler.cpp
index f6f049e4e..685d5d928 100644
--- a/lib/remote/objectqueryhandler.cpp
+++ b/lib/remote/objectqueryhandler.cpp
@@ -3,6 +3,7 @@
 #include "remote/objectqueryhandler.hpp"
 #include "remote/httputility.hpp"
 #include "remote/filterutility.hpp"
+#include "base/json.hpp"
 #include "base/serializer.hpp"
 #include "base/dependencygraph.hpp"
 #include "base/configtype.hpp"
@@ -166,9 +167,6 @@ bool ObjectQueryHandler::HandleRequest(
                return true;
        }

-       ArrayData results;
-       results.reserve(objs.size());
-
        std::set<String> joinAttrs;
        std::set<String> userJoinAttrs;

@@ -194,6 +192,10 @@ bool ObjectQueryHandler::HandleRequest(
        std::unordered_map<Type*, std::pair<bool, std::unique_ptr<Expression>>> typePermissions;
        std::unordered_map<Object*, bool> objectAccessAllowed;

+       auto adapter(std::make_shared<AsioStreamAdapter<AsioTlsStream>>(stream, yc));
+       JsonEncoder encoder(adapter, params && HttpUtility::GetLastParameter(params, "pretty"));
+
+       bool started = false;
        for (ConfigObject::Ptr obj : objs) {
                DictionaryData result1{
                        { "name", obj->GetName() },
@@ -311,15 +313,18 @@ bool ObjectQueryHandler::HandleRequest(

                result1.emplace_back("joins", new Dictionary(std::move(joins)));

-               results.push_back(new Dictionary(std::move(result1)));
-       }
-
-       Dictionary::Ptr result = new Dictionary({
-               { "results", new Array(std::move(results)) }
-       });
+               if (!started) {
+                       started = true;
+                       response.result(http::status::ok);
+                       response.set(http::field::content_type, "application/json");
+                       http::response_serializer<http::string_body> serializer(response);
+                       http::async_write_header(stream, serializer, yc);

-       response.result(http::status::ok);
-       HttpUtility::SendJsonBody(response, params, result);
+                       encoder.Encode(JsonEncoder::BeginObject, JsonEncoder::MakeField("results", JsonEncoder::BeginArray));
+               }
+               encoder.EncodeItem(new Dictionary(std::move(result1)));
+       }

+       encoder.Encode(JsonEncoder::Flush);
        return true;
 }

Sorry! As @julianbrost already found out, we don't need to introduce our own std::string output adapter, since the library already provides one on its own. Besides, apart from introducing that new StringOutputAdapter class, I didn't even make use of it in the JsonEncoder class, so it's now completely removed.