저는 웹 - 앱 - services 서비스를 개발함으로써 하스켈에 대해 더 익숙해 지려고합니다.하스켈 웹 서버 : 응용 프로그램 상태 유지
웹 서버를 개발 중이며 요청간에 영구 상태를 유지하려고합니다. 예를 들어 카운터. 하스켈이하는 일은 무엇입니까?
나는 Google 검색에서이 discussion을 발견했습니다. 제안 된 솔루션은하지 않을 일의 좋은 예입니다.
하나의 아이디어 나 요청 처리기는 MVAR에 걸릴 가졌다했다 :
requestHandler :: MVar State -> IO (Maybe Response)
더 좋은 방법이 있어야합니다. 나는 도움이 될 수 없지만 나는이 문제를 비 기능적인 방식으로 접근하고 있다고 생각한다.
감사합니다.
아마도 당신은 정확하게 : Haskell 데이터 유형에 대한 영속 상태를 제공하는 acid-state을 원할 것입니다. 내가 연결 한 문서는 요청한 카운터와 마찬가지로 요청한 것처럼 시작됩니다.
MVars는 지속적이지 않습니다. 서버가 다시 시작되면 카운터가 재설정됩니다. 그것이 실제로 당신이 원하는 행동 인 경우 나는 대신 TVar을 사용하는 것이 좋습니다. 그런 식으로 잠금을 사용하지 않고 카운터를 원자 적으로 업데이트하거나 함께 진행되는 교착 상태의 위험을 방지 할 수 있습니다.
지속성 및 TVars가 좋으면 TVars와 동일한 의미 및 사용 패턴을 가진 DBRefs을 사용할 수 있습니다. 상태에 대한 고유 키를 정의해야하며 자동 파일 지속성이 있습니다. 데이터베이스 지속성을 위해 IResource 인스턴스를 정의해야합니다.
import Data.Map as M
import Data.TCache
import Data.TCache.DefaultPersistence
type Counter= Int
type SessionId :: String
data State= State SessionId Counter deriving (Read, Show, Typeable)
instance Indexable State where
key (State k _)= k
requestHandler :: Request -> DBRef State -> IO (Maybe Response)
이유는 서버 자체에 지속 상태를 전달하려고 :
상태는 각 세션에 대해 고유 한 카운터를해야합니다? 나에게 하스켈은 RESTful 디자인과 훨씬 잘 어울리는 것 같다. –
그 접근법에 대해 "기능 외"란 무엇입니까? 공유 할 필요가있는 상태가 있으므로 참조를 둘러 싸서 전달하십시오. 나에게 꽤 똑바로 보인다. – sclv
sclv : FRP 접근법이 더 많았는지 궁금합니다. – David