suave
suave copied to clipboard
SuaveIO
split Suave request handling from hosting
I want to use Suave to handle requests because its API is great for F#, but I don't want to be tied to its particular web server. For our humble use case, deploying another web server is not desired. I'm thinking here more toward Nancy's model of where you include another package to adapt to the web server it is hosted on.
What do you think?
Aside: I was pretty confused by the OWIN support at first, because when I looked at the tests I was expecting Suave to run in OWIN, not the other way around, hah.
@kspeakman this might be of your interest https://github.com/Krzysztof-Cieslak/Suave.Kestrel
@ademar Thanks for the link. But hosting on Kestrel is roughly an equivalent scenario to using Suave's web server. In the near term, we need to deploy to IIS so I use Web API. I'd love to be able to leverage Suave on top of interfaces like OWIN (current) or ASP.NET Core (future), and then choose the hosting from there (IIS/azure, kestrel, etc) based on the use case.
There's also the HttpPlatformHandler to host Suave under IIS.
Ronnie
On Wed, Jul 20, 2016 at 2:17 AM, Kasey Speakman [email protected] wrote:
@ademar https://github.com/ademar Thanks for the link. But hosting on Kestrel is roughly an equivalent scenario to using Suave's web server. In the near term, we need to deploy to IIS so I use Web API. I'd love to be able to leverage Suave on top of interfaces like OWIN (current) or ASP.NET Core (future), and then choose the hosting from there (IIS/azure, kestrel, etc) based on the use case.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/SuaveIO/suave/issues/486#issuecomment-233804489, or mute the thread https://github.com/notifications/unsubscribe-auth/AA7ddwp6drIitaKkwWLx0cpfiTDdsZEgks5qXWkjgaJpZM4JIExk .
@ronnieholm I read about HttpPlatformHandler prior to filing the issue. Part of the difficulty I'm aiming at here is non-technical. It's already difficult getting the team to write idiomatic F# (Suave helps here). Simultaneously adding new deployment and ops factors can discourage that effort (Suave hurts here). Changes to deploy/ops are inevitable of course, but managing the timing can make a large difference.
So here is another example of where the Suave API would be useful as a separate thing from the web server. This post describes how to adapt the Suave API to be hosted as an Azure Function.
http://blog.tamizhvendan.in/blog/2016/09/19/scale-up-azure-functions-in-f-number-using-suave/
Since Azure functions have their own method of hosting, only the API is used, and the author creates adapter functions to convert between the host and Suave API. The Suave web server is just carried along for the ride.
I think we can do this for v3 we can split the web server to its own assembly.