blog/1-abstracted-routing-with-adr

[utterances-bot]

Abstracted Routing with Action Domain Responder - Hiraeth PHP Nano Framework

https://hiraeth.dev/blog/1-abstracted-routing-with-adr

[alturic]

I’d love to see some simple pseudo code implementing even a hello world. The article seems nicely written.

[mattsah]

@alturic -- I'm not sure I follow. A simple hello world could be as simple as returning a string of 'Hello World!' from an action. Because the responders handle converting it to a response, the magic is mostly in having a responder set up that will match a string and create a response from it. The hiraeth-php/routing package has a handful of responders (some complete, some not) that handle basic data types like this, including a one to convert arrays to JSON, for example, see:

• https://github.com/hiraeth-php/routing/blob/master/src/responders/StringResponder.php
• https://github.com/hiraeth-php/routing/blob/master/src/responders/JsonResponder.php

[alturic]

Ha, 100% correct on the string being returned in the action. I did mean an example of the most basic ADR pseudo code. I suppose even then there might not be a point as without a container and all it wouldn’t really implement DI or anything like that.

I did appreciate the article, and suppose basic “working examples” would be silly as people who know how to implement it just could.

I always liked the simplicity of ADR but never really could wire together all of the basic niceties (reeuest,response,routing,DB et al) to make it work without just using a full-blown framework.

[mattsah]

@alturic -- Well, the framework is operational. Not all features are complete, but you're welcome to test what is complete and documented just click the "Documentation" link at the top of the site and start from the beginning. Unfortunately, I don't have the Responders page done yet on the docs... but the StringResponder and JSONResponder are registered by default, and most pages up to Actions have content.

As for overall pseudocode, not sure code is the best, but here's what the basic framework lifecycle looks likes:

1. Request is created in index.php and passed to registered PSR-15 Request Handler Interface -- for hiraeth/bootstrap I use Harmony.
2. Harmony loops through middleware, executing or returning accordingly.
3. Final middleware is the router. The router implementation, current request, and default response are registered with the resolver.
4. Target (Action/Controller) is returned by router on URL / Method Match
5. Resolver loops through registered adapters to find one that matches according to match(), then converts the target to a callback using __invoke().
6. Callback is constructed and executed to return a Result
7. Resolver loops through registered responders to find one that matches according to match(), then converts the result to a response using __invoke().
8. Response is passed back down the middleware stack

I should add, although adapters were originally written to handle particular routers' possible targets... in theory it could examine the target for patterns. Nothing would, for example, prevent you from writing an adapter that allowed you to route to a URL and proxy the request / response from that URL. Maybe I'll do a blog article on that some time.