Closed sleipnir closed 1 year ago
this is planned!, but not till 0.3
this is planned!, but not till 0.3
Cool. Thanks
Thanks for keeping it on the issue list. I might try to do it in 0.2 to make sure my abstractions are correct before getting too far into features.
Thanks for keeping it on the issue list. I might try to do it in 0.2 to make sure my abstractions are correct before getting too far into features.
Cool. Great work. This will be very helpful for me. I will try to help however I can.
so the complexity is going to be because it's rather tricky in base Plug to support distinct plug pipelines on a path parameter basis (phoenix provides the scope/pipeline mechanic). I think I know one way to do it, (create a module plug per operationId) but I would like to see how phoenix does it first. Might just be able to copy scope/pipeline from phoenix ha
I really think that the scope/pipeline semantics should be included directly in the Plug api, reusing work done by the Phoenix team. Well, that's very useful. As, maybe, this is beyond the scope of this project, it may be necessary to replicate the behavior of phoenix here, or implement a module per operationId really.
Basics done here: 1b2087a, needs some tests on path parameter resolution.
will close when:
completed in e39e45a]
Great work here @ityonemo
Hi. Nice library.
I would really like to be able to use something like what this library provides without the direct need for Phoenix. Some services are too simple for Phoenix features and could depend only on Plug, without direct dependency on Phoenix.