|
Cro: libraries and tools for building reactive services in Perl 6 | cro.services/ | Logs: irclog.perlgeek.de/cro/ Set by moderator on 22 March 2018. |
|||
|
02:40
lizmat joined
02:57
ilbot3 joined
|
|||
| moderator | Cro: libraries and tools for building reactive services in Perl 6 | cro.services/ | Logs: irclog.perlgeek.de/cro/ | ||
|
09:47
sena_kun joined
|
|||
| Geth | cro-http: be7d659a06 | Altai-man++ | t/http-client.t Test external cookie setting |
11:18 | |
|
12:15
lizmat joined
16:06
stmuk joined
16:26
FROGGS joined
|
|||
| japhb | Are there any docs or best practices for testing the routes, independently of the business logic or transform pipeline? Conceptually, I was going to Test::Mock my top-level business logic object, and then check that triggering the various routes makes the right calls (or fails properly). But then I realized I don't know the best way to trigger the routes outside of the transform pipeline, and figured y'all | 19:53 | |
| might .... | |||
| jnthn | The generated structure puts the route block in a sub to encourage you to pass parameters to it in order to provide dependencies | 20:02 | |
| So those can be mocked | 20:03 | ||
| There's not yet a better way than "host it using Cro::HTTP::Server and make calls with Cro::HTTP::Client" | |||
| Though we don't really need to involve a network stack at all of course, just shuffle the Cro::TCP objects from one pipeline to the next | 20:05 | ||
| Which is one my wish list at some point, and probably quite easy, the harder part being coming up with a nice API for writing tests :) | 20:06 | ||
| japhb | Yeah, the route block dependency injection was already something I was doing, which would make the Test::Mock of the injected business logic easy. It was that "make HTTP calls" thing I was thinking probably had a simpler method. :-) | 20:07 | |
| jnthn | Alas, that's one part of Rome there hasn't been enough days to build yet | 20:09 | |
| Though I probably am getting to the point where I'll want it for work with one $client. :) | 20:10 | ||
| japhb | There are worse prioritization methods than "Will it be immediately useful in obtaining revenue without going insane?" | 20:13 | |
| BTW, in case it's not clear, jnthn++ and Altai-man++ for all your respective work on Cro. It's a delight. :-) | 20:14 | ||
| Design philosophy question: I'm planning to do an in-memory implementation of the business logic, a SQL-backed implementation, and possibly others. I see two implementation paths: BusinessLogic is an interface role, and BusinessLogic::InMemory/PostgreSQL implement it -- or BusinessLogic is a real class that has a DataStore, which is a role implemented by DataStore::InMemory/PostgreSQL. | 20:22 | ||
| In other words, the latter forms another layer of indirection from the upper layers. But does that extra layer turn out to be useful? | 20:23 | ||
| If you've gone down one path and decided to switch to the other, that's pretty telling .... | 20:24 | ||
| jnthn | For me, the ideal is business logic being a clean set of objects, or possibly functions over well-defined data structures, not coupled directly to any kind of framework or persistence model, such that said logic is easily tested in isolation. | 20:41 | |
| Of course, there's practical tensions to weigh up against that. | |||
| A bunch of them revolve around the fact that query efficiency tends to matter a lot | 20:43 | ||
| Which is why I got quite interested in the Command/Query responsibility seperation arhcitecture | 20:44 | ||
| The the invariants that make up most of the interesting business logic tend to sit on the command side of things, while the places carefully engineered queries matter are typically reads | 20:45 | ||
| s/architecture/arhictectural pattern/ to be precise :) | 20:46 | ||
| Anyway, that means that you might end up with a role dealing in interesting queries (reads), and then some more typical repository-pattern style thing for persisting business objects involved in commands | 20:47 | ||
| This all supposes, of course, that there is some interesting business logic, and the app isn't just a REST-y interface to insert/update/delete/select on handful of tables. In which case it's probably not worth worrying too much about anything. :-) | 20:52 | ||
| japhb | The complexity level is somewhere around Enterprise Grade Tipsy ... lots more functionality, lots more data, some complex problems like "support undo" and "this wad of data is actually a DAG" ... but essentially just a small purpose-built social network. | 21:00 | |
| I'm not exactly designing a telecom infrastructure, but it's not a guestbook either. :-) | 21:01 | ||
| But your points are good, I'll cogitate on them for the next phase of coding. | 21:02 | ||
| [ Thanks. :-) ] | |||
| jnthn | :) | 21:03 | |
|
21:41
lizmat joined
23:38
lizmat joined
|
|||