or trailblazer or hamani?
yeah, it converts data to different formats depending on sorta complex biz logic, could make requests to other system as part of that
in this case i don’t expect the database to be a big component in the app, if it is at all.
also, it only supports roda atm, but we’re gonna add other routing front-ends soon
ie dry-web-hanami
or libs or whatever
i haven’t kept up in the last few years
w/ generators hopefully
fwiw I’m planning to add a new data transformation lib to dry-* family later this year
I don’t like rom-mapper anymore :)
@solnic imagine taking an ebay product in their api format and converting that to what amazon needs for their api
and what bing needs
so could be taking something in some weird xml format, applying biz logic, then send to whatever json format another service needs
i like hanami’s actions more than roda (at first glance) because it’s easy to see how to structure the code / actions
on a team i think having the convention is important
vs jumping between router dsl and action files
the way we use roda is that http-specific code lives in the routing trees, everything else is core app APIs
so basically http part of the whole system becomes an extension on top of the core app
I mean, that’s how it works in dry-web
how weird is the xml, and how complicated is the business logic?
we’re actually thinking about a dry-fp project with various functional APIs that many projects can rely on
there’s a big portion of transproc that could be moved there