Revision history for PAGI::FastAPI
0.1.0 2026-08-10
[BREAKING]
- The add_cors function now utilizes PAGI::Middleware::CORS instead
of implementing its own version, based on the recommendation of the
author of the PAGI specifications. The reason to make this switch
is the established use of PAGI::Tools in other components of the
package. The previous names of the options have been changed, as
follows: allow_origins and allow_methods were replaced with origins
and methods, respectively, while the new default value for max_age
changed from 600 to 86,400. The value of max_age is the default one
used by PAGI::Middleware::CORS. There is also a new value called
expose_headers.
- CORS is added as the outermost level in to_app() and will be
applied after mount()-ed sub-applications and static files are
created. Thus, CORS will be applied throughout the application and
not only to get/post/other functions like before.
- New requirement: PAGI::Middleware::CORS >= 0.002002 (comes with the
same PAGI::Tools package as PAGI::WebSocket, already in the list of
prerequisites. Also, presented here explicitly as being directly
utilised).
[DOCUMENTATION]
- The previous event-loop section has been revised (renamed from
"MIXING WITH OTHER EVENT LOOPS" to "EVENT LOOPS: FUTURE::IO IS THE
GOAL, IO::ASYNC IS AN IMPLEMENTATION DETAIL"), at the request of
the author of the PAGI specification: previously, it stated that
"PAGI::FastAPI works entirely on IO::Async," although this makes it
sound like a load-bearing requirement instead of simply an
implementation detail. It now insists on Future::IO being the
recommended way of writing your own event-driven code (timers,
delays) and provides a working example following the heartbeat
pattern presented in the chat-server example. The
IO::Async::Loop::EV/IO_ASYNC_LOOP=EV technology has been preserved,
but it is defined as simply a backup solution used in very specific
cases involving the use of Mojo::IOLoop-based libraries that
appeared prior to Future::IO.
0.0.9 2026-08-08
[BREAKING]
- Removed PAGI::FastAPI::WebSocket entirely.
- websocket() handlers now receive a plain PAGI::WebSocket instance
directly. For anyone who wasn't relying on the class name itself
(isa checks, `use PAGI::FastAPI::WebSocket` directly), this is a
no-op - every method, return type, and calling convention is
unchanged from 0.0.10, since that version was already a strict,
override-free subclass.
- _handle_websocket now sets $scope->{path_params} directly and
calls PAGI::WebSocket->new($scope, $receive, $send) - the same
glue that used to live in the now-removed class's constructor.
- Dropped the now-unused JSON::MaybeXS prereq (it was only ever
needed by the removed class) and the PAGI::FastAPI::WebSocket
entry from t/00-load.t and the provides map.
0.0.8 2026-08-08
[DOCUMENTATION]
- There is a new "MIXING WITH OTHER EVENT LOOPS" section which
describes the interoperability issue between IO::Async (on which
PAGI::FastAPI is based) and Mojo::IOLoop-based libraries like
Mojo::Pg. The paragraph in question explains that IO::Async allows
calls to the non-blocking API to hang unless both libraries utilise
the same reactor. The other method of calling a library in a
blocking manner locks every other connection in the process. The
solution is detailed (IO::Async::Loop::EV + IO_ASYNC_LOOP=EV,
along with wrapping the callback API in a Future).
0.0.7 2026-08-08
[DOCUMENTATION]
- Reworded PAGI::FastAPI::WebSocket's receive_text()/receive_bytes()
POD, which previously said they "block asynchronously" - a
self-contradictory phrase that read as "this blocks the server" to
at least one reader. Now states plainly that they suspend only the
current connection's coroutine and never block the event loop or
other connections. Added the same clarification to the module
DESCRIPTION. No code changes; the implementation was already
correctly non-blocking (verified against PAGI::Server::Connection's
per-connection dispatch, which detaches each handler via
adopt_future rather than awaiting it inline).
0.0.6 2026-08-08
[ENHANCEMENTS]
- Full support for WebSocket routing has been added and is available
by creating a $app->websocket() endpoint. The implementation is
completed with async frame handling and parameter extraction
capabilities.
- A new class called PAGI::FastAPI::WebSocket has been introduced. It
allows for the non-blocking implementation of the handshake and
message methods: accept(), close(), receive_text(), receive_json(),
receive_bytes(), send_text(), send_json(), send_bytes().
- The mount() method has been implemented, allowing PAGI
sub-applications, static files, and routers to be mounted via
PAGI::App::URLMap.
- The add_middleware() method has been implemented for registering
custom async middleware.
- The WebSocket routes were excluded from the generated OpenAPI
documentation version 3.1.
[BUG FIXES & ERROR HANDLING]
- The unmatched WebSocket routes already reject the connections with
a close code 4004 before the acceptance of handshake.
- Unhandled exceptions in the WebSocket handlers lead to open
connections termination with a close code 1011 automatically.
- Dialing execution errors on the WebSocket endpoints lead to the
closure of the connections automatically with the status code 1008.
[DOCUMENTATION & EXAMPLE]
- Chat server application was added to showcase HTML/JavaScript
and WebSocket functionality.
- Updated module documentation and SYNOPSIS for PAGI::FastAPI and
PAGI::FastAPI::WebSocket.
[TESTING]
- Created t/11-websocket.t that includes handshakes, echo flows,
path parameters, JSON payload handling and status codes of close.
- Updated t/00-load.t to incorporate PAGI::FastAPI::WebSocket.
0.0.5 2026-08-06
[ENHANCEMENT]
- The POST/PUT/PATCH request bodies can now be in the application/x-www-form-urlencoded
format instead of being restricted to JSON. The body parser examines
the Content-Type header; therefore, the charset suffix (such as ";charset=utf-8")
will be ignored.
Furthermore, the body parser will process url-encoded data in the
same manner as query string in which the body is decoded using
percent-/plus-decode algorithm. However, the same Type::Tiny
validation can be applied in either format and the handler will
receive a HashRef object as a result of a processed request
regardless of the sent format.
- It is backward compatible, i.e., if the Content-Type header is not
set or not recognised, the body will be processed in the same way
as before. In particular, the default behavior of parsing requests
is JSON parsing.
- Also the new feature was tested in t/10-form_urlencoded_body.t.
- The plugin is documented in the `body` configuration option as well
as in the ERROR HANDLING section. The decision to implement this
feature was influenced by the example provided on a
PAGI::FastAPI::Security page.
0.0.4 2026-08-05
[DOCUMENTATION]
- Included an AUTHENTICATION AND SECURITY part in the POD to highlight
the dependencies and components of middleware and provided information
about the new companion distribution called PAGI::FastAPI::Security
for the ready-to-use schemes related to HTTP Bearer, HTTP Basic,
API Key, and OAuth2 password-bearer.
- Added a Pluggable Authentication item in Key Features List.
- Added PAGI::FastAPI::Security and DBIx::Class::Async to SEE ALSO section.
- Mentioned in the SYNOPSIS the introduction about the functionality
of hand-rolled Bearer-token checks in this context and referring to
PAGI::FastAPI::Security for production use.
- Added a similar entry in README.md as well.
[EXAMPLE]
- Updated the example to demo authentication using PAGI::FastAPI::Security:
eg/dbic_async_integration.pl
0.0.3 2026-08-04
[EXAMPLE]
- Added integration demo script:
eg/integration_demo.pl
0.0.2 2026-08-04
[BUGFIX]
- Routes no longer consider metacharacters in their static paths
(like ".", "+", "?") as wildcards. Only placeholders {param}
are transformed into capture groups. Previously, it would allow
the route '/items.json/{id}' to match paths like '/itemsXjson/{id}'.
- The values of path parameters and query string parameters are now
appropriately decoded: '%XX' and '+' decoding is now done as it
should be according to the application/x-www-form-urlencoded rules.
Until now strings like 'John%20Doe' were sent to handlers unchanged.
- The request body reader no longer goes into an infinite loop when
the PAGI server sends a non-'http.request' event (for example
'http.disconnect') while transmitting POST/PUT/PATCH requests.
- When registering routes, the process now fails with a clear message
instead of just ignoring misconfiguration. For instance, absence
of a 'handler' property, 'dependencies' property not being a HashRef
or an ArrayRef is rejected immediately during route registration.
[TESTING]
- A new test was added in t/08-input_handling_and_registration.t
covering the above-mentioned aspects.
- A new test was added in t/09-external_async_resource_integration.t
to cover DBIx::Class::Async integration.
[EXAMPLE]
- Added additional DBIx::Class::Async integrated application:
eg/dbic_async_integration.pl
0.0.1 2026-08-03
- Initial CPAN release.
- Asynchronous routing engine built on top of PAGI ($scope, $receive, $send).
- Type-safe parameter & POST JSON body validation via Type::Tiny.
- Async Middleware pipeline support with built-in CORS helper (add_cors).
- FastAPI-style Dependency Injection system via PAGI::FastAPI::Depends.
- Integrated OpenAPI 3.1 schema (/openapi.json) and interactive Swagger UI (/docs).