Newest first, grouped by year. Search or filter by topic.
GET /payments returns a 404 in Inflow's own root request file. The reason is not a typo - it is the Payments module exercising exactly the architectural freedom the README advertises, which makes this 404 the best evidence in the repository that the claim is true.
Trill's hand-rolled framework follows the ASP.NET Core registration convention with unusual discipline, then breaks it twice on purpose - and the exceptions turn out to be more instructive than the rule.
Trill's Stories service ships a complete caller-identity abstraction - context, factory, claims, an IsAdmin flag - registers it in the container, and injects it into nothing, while every endpoint reads the user id out of the request body instead.
Trill's gateway authenticates the caller, parses the subject claim out of the JWT and writes it into the request body as a userId - a Content Enricher at the edge that explains the whole estate's API shape, and carries four defects in fifty lines.
Trill's gateway parses the story id out of the URL, boxes it into a route-value dictionary, and uses the result as a boolean - so the synchronous and asynchronous versions of the same operation have different contracts and only one of them honours the URL.
A four-field record that makes it impossible to register a route without stating who may call it - the best idea in the mini-framework - and the one line it did not write, which costs every 404 in the estate.
Pacco's naming system is consistent enough to parse - exchanges are bounded contexts, queue names spell their own bindings, commands and events conjugate in snake_case, and every command has a _rejected twin. Reading the estate as a language, including its irregular verbs and the fact that no grammar-checker exists.
Pacco's Ntrada gateway is ninety lines of C# and five hundred of YAML, and swapping one route key - use downstream for use rabbitmq - turns the same HTTP surface from a proxy into a bus publisher answering 202. The two compose files disagree about which one you get.
In Pacco the CQRS split is not a diagram - it is wiring you can read. Every command arrives through two front doors, RabbitMQ subscription and controller-less HTTP dispatch, while queries ride HTTP only; commands assign their own ids in the constructor, and a marker attribute turns each service into its own runtime contract registry.
DShop's gateway answers a write with 202 Accepted and a header pointing at an operation that hasn't happened yet. Reading the contract shows a clean async-REST design - and two small bugs that undercut it.
DShop.Api.Next rebuilds the whole code-first gateway as Ntrada configuration - a 17-line Program.cs and a folder of YAML. Reading both side by side shows exactly what you trade when a gateway becomes data.
DShop's gateway reads over HTTP and writes over a message bus - two dispatch mechanisms behind one controller. Reading it shows how a gateway can be a router and a publisher at the same time.
DShop.Common's error middleware maps every exception to HTTP 400, computes a safe message, then throws it away and serialises the raw exception text to the caller.
DShop.Common stamps a server-generated Guid into an immutable command by reflecting into its compiler-generated backing field - immutability the type system only pretends to enforce.
