http_adapter.hpp File Reference

HTTP/REST/SSE implementation of IViewAdapter. More...

#include "aria/abi/export.hpp"
#include "aria/binding/view_adapter.hpp"
#include "http_config.hpp"
#include "http_view.hpp"
#include <cstdint>
#include <functional>
#include <memory>
#include <string>
#include <string_view>
#include <vector>

Include dependency graph for http_adapter.hpp:

Go to the source code of this file.

Classes
class	aria::adapters::http::HttpAdapter
	HTTP/REST/SSE implementation of IViewAdapter. More...
struct	aria::adapters::http::HttpAdapter::ViewInfo
	Snapshot of currently registered (id, kind) pairs. More...

Namespaces
namespace	httplib
namespace	aria
namespace	aria::adapters
namespace	aria::adapters::http

Detailed Description

HTTP/REST/SSE implementation of IViewAdapter.

HttpAdapter is the "Web sibling" of QtAdapter / AppKitAdapter / UIKitAdapter. It exposes Aria ViewModels to a remote frontend (typically a browser running plain JS or Vue/React/Svelte) over a small REST + SSE protocol — see wire_protocol.hpp.

Design goals

1. Drop-in replacement for any other adapter. Same IView/IViewAdapter contract → same BindingEngine wiring. A ViewModel written against IViewAdapter sees no difference between Qt and HTTP. You can bind one ViewModel to BOTH adapters simultaneously and the binding engine fans out updates correctly.
2. Zero JS dependencies on the server. The adapter ships a pure-vanilla JS SDK (~12 KB unminified) that works in any modern browser without a build step. Frameworks like React/Vue/Svelte can wrap the SDK trivially.
3. Reasonable defaults; safe-by-default. Bind to localhost; limit SSE connections; no CORS by default; no auth (rely on the network boundary or a reverse proxy). The framework's job is to ship a usable adapter, not a production web server — see docs/guide/adapters/http.md for deployment notes.

Usage and threading

See docs/guide/adapters/http.md for a compiled complete example. Construct a shared HttpAdapter and pass it with the graph owner's dispatcher to BindingEngine using DispatchPolicy::SmartMarshal.

• Registry maps and shadow state are mutex protected. Returned view pointers/references are not lifetime pins: coordinate replacement, removal and binding teardown on the graph owner thread.
• Setters enqueue SSE data without waiting for socket writes; getters copy shadow state under the registry mutex.
• Direct subscriptions and custom command handlers run on HTTP workers. BindingEngine marshals bound Property/Command callbacks when configured with a dispatcher. Custom handlers must marshal graph access themselves.
• Subscription handles may be released during or after adapter destruction; they do not keep the adapter or its registered callbacks alive.
• start/stop are serialized; invoke them from the host lifecycle thread, outside an HTTP callback (stop joins the worker pool). Calls from this server's tasks throw std::logic_error. Destroying the adapter inside a callback requests asynchronous shutdown; native state is retained until every active worker and both background threads have finished.