You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To make it better we have to measure it from the start I think so we should provide easy to use performance testing utils as a part of this framework or as a contrib.
Because we are working on top of the purescript-run I think that we can consider interpretation to different HTTP backends (purescript-warp, purescript-httpureor even to Node.js) directly.
Thanks to the run we can consider parsing pieces of the request on demand and providing them as an effect. We can even mutate the request object underneath as we won't expose it directly.
It would be interesting to check how much speedup can we gain by interpreting State (or session API) as a ReaderT { ref :: Effect.Ref | r } Aff.
To make it better we have to measure it from the start I think so we should provide easy to use performance testing utils as a part of this framework or as a contrib.
Because we are working on top of the
purescript-run
I think that we can consider interpretation to different HTTP backends (purescript-warp
,purescript-httpure
or even to Node.js) directly.Thanks to the run we can consider parsing pieces of the request on demand and providing them as an effect. We can even mutate the request object underneath as we won't expose it directly.
It would be interesting to check how much speedup can we gain by interpreting
State
(or session API) as aReaderT { ref :: Effect.Ref | r } Aff
.Is it possible / feasible to drop Reader all together and provide the context per request by using something like
continuation-local-storage
mentioned here: https://stackoverflow.com/questions/25151952/global-data-per-http-session-requestHow fast is routing duplex? How much we can tune it?
The text was updated successfully, but these errors were encountered: