scotty-web / scotty

Haskell web framework inspired by Ruby's Sinatra, using WAI and Warp (Official Repository)
http://hackage.haskell.org/package/scotty
BSD 3-Clause "New" or "Revised" License
1.71k stars 132 forks source link

Reimplement `ScottyT` in terms of ReaderT #340

Closed ocramz closed 9 months ago

ocramz commented 9 months ago

This would give us local, allowing to apply specific middlewares (e.g. authentication) only on given sets of routes (See #187 ).

Also it would let us unify the exception handling mechanism.

It's only a breaking change if we put the reader variable inside a TVar and some modifying functions gain a MonadIO constraint.

We can use the predicates defined here to inspect HTTP status codes and act accordingly (i.e. throw an exception or not): https://hackage.haskell.org/package/http-types-0.12.3/docs/Network-HTTP-Types-Status.html#v:statusIsInformational


Screenshot 2023-10-15 at 13 39 35
It was ReaderT all along?
Always has been.
ocramz commented 9 months ago

@fumieval what do you think?

fumieval commented 9 months ago

ScottyT has nothing to with exceptions because it should never fail, as its sole purpose is to build a WAI application. For this purpose I think State-like monad is a better fit

ocramz commented 9 months ago

good points! While I'm a bit concerned by that "should never fail", I don't have a counterexample currently, so I'll close this.

On Sun, 15 Oct 2023 at 15:43, Fumiaki Kinoshita @.***> wrote:

ScottyT has nothing to with exceptions because it should never fail, as its sole purpose is to build a WAI application. For this purpose I think State-like monad is a better fit

— Reply to this email directly, view it on GitHub https://github.com/scotty-web/scotty/issues/340#issuecomment-1763393846, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNBDKHDCAJPC4SZV4RCK6TX7PR7VAVCNFSM6AAAAAA6A4NME6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRTGM4TGOBUGY . You are receiving this because you authored the thread.Message ID: @.***>

fumieval commented 9 months ago

If the route definition contains a mistake (e.g. get "/foo" defined twice), perhaps it should throw an error. It should not be caught anyway

ocramz commented 9 months ago

ok, closing this !