シンプルなHaskellブログ用のRESTサーバー

しばらく前、私は動的型付けの言語に完全にうんざりしていました。 Haskellは、コードの美しさと、純粋な機能と副作用を明確に分離するという妥協のない欲求が好きでした。 私はHaskellの本をいくつか飲み干し、すでに何かを書く時だと判断しました。



そして、失望が私を待っていました。こんにちは、world-a以外は何も書くことができませんでした。 つまり findなどのコンソールユーティリティの作成方法を大まかに想像していましたが、IOとの最初の出会いはすべてのアイデアを破壊しました。 Haskellには多くのライブラリがあるようですが、それらのドキュメントはほとんどありません。 典型的な問題を解決する例も非常に少ない。



症状は明確であり、診断は簡単です。練習不足です。 そして、Haskellにとって、これは非常に苦痛です。 言語は非常に珍しいです。 私がClojureをよく知っているという事実でさえ、私をあまり助けませんでした、なぜなら Clojureは関数に重点を置いており、Haskellはその型に焦点を当てています。



多くの新参者がHaskellでの練習不足の問題に直面していると思います。 インターフェイスなしで完全に何かを書くことは、どういうわけか面白くなく、初心者のHaskelist用のデスクトップまたはWebアプリケーションを作成することは非常に困難です。 この記事では、特にHaskellを練習したいが、どの方法でアプローチするのかわからない人のために、HaskellでWebアプリケーションサーバーを作成する方法の簡単な例を提供します。



最もせっかちな人のために：ソースはこちらです。



すぐに言います：これは別のYesodチュートリアルではありません。 このフレームワークは、Webアプリケーションを正しく作成する方法に関するアイデアを決定するものであり、私はすべてに同意するわけではありません。 したがって、ベースは小さなScottyライブラリーになり、 Warp Webサーバー用の美しいルート記述構文を提供します。

挑戦する

シンプルなブログ用のWebアプリケーションサーバーを設計します。 次のルートが利用可能になります。

• GET /記事-記事のリスト。
• GET / articles /：id-別の記事。
• POST / admin / articles-記事を作成します。
• PUT / admin / articles-記事を更新します。
• DELETE / admin / articles /：id-記事を削除します。

「/ admin」で始まるすべてのルートには、ユーザー認証が必要です。 ステートレスサービスの場合、 基本認証を使用すると非常に便利です。 各リクエストには、ユーザーのユーザー名とパスワードが含まれています。

何が必要ですか？

• Haskellの基本的な知識、モナドとファンクターの一般的な理解、デバイス設計、I / Oなど。
• Cabalユーティリティ、サンドボックスの使用、ライブラリの接続、プロジェクトのコンパイルおよび実行の機能。
• MySQLおよびそれに関する最も基本的な知識。

建築

アーキテクチャを実装するには、次のライブラリの使用を提案します。

• Webサーバー-ワープ。
• ルーター-Scotty。
• アプリケーション構成はコンフィギュレーターです。
• データベースへのアクセス：mysqlおよびmysql-simple。
• データベース接続プール：リソースプール。
• クライアントとの相互作用-JSON、ライブラリを使用したREST-aeson。
• 基本認証のwai-extra、として アプリケーションはステートレスになります。

アプリケーションをモジュールに分割します。

• Main.hsには、アプリケーション、ルーター、およびアプリケーションの構成を実行するためのコードが含まれます。
• Db.hs-データベースへのアクセスに関連するすべて。
• View.hs-データ表示。
• Domain.hsのタイプとサブジェクト領域を操作するための関数。
• Auth.hs-認証のための関数。

降りる

アプリケーション用の単純なcabalプロジェクトを作成しましょう。

mkdir hblog cd hblog cabal init
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでいくつかの質問に答える必要があります。プロジェクトの種類は実行可能ファイルを選択し、メインファイル-Main.hs、ソースディレクトリ-srcを選択します。 hblog.cabalファイルのbuild-dependsに追加する必要があるライブラリを以下に示します。

  base >= 4.6 && < 4.7 , scotty >= 0.9.1 , bytestring >= 0.9 && < 0.11 , text >= 0.11 && < 2.0 , mysql >= 0.1.1.8 , mysql-simple >= 0.2.2.5 , aeson >= 0.6 && < 0.9 , HTTP >= 4000.2.19 , transformers >= 0.4.3.0 , wai >= 3.0.2.3 , wai-middleware-static >= 0.7.0.1 , wai-extra >= 3.0.7 , resource-pool >= 0.2.3.2 , configurator >= 0.3.0.0 , MissingH >= 1.3.0.1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、ライブラリのバージョンとその依存関係の混乱を回避するために、サンドボックスを作成します。

  cabal sandbox init cabal install —dependencies-only
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

src / Main.hsファイルを忘れずに作成してください。



最小限のScotty Webアプリケーションがどのように機能するかを見てみましょう。 このマイクロフレームワークの使用に関するドキュメントと例は非常に優れているため、一目ですべてが明らかになります。 また、シナトラ、コンポジュレ、またはスカラトラの経験がある場合は、幸運だと考えてください。 この経験はここで完全に役立ちます。



これは、最小のsrc / Main.hsの外観です。

 {-# LANGUAGE OverloadedStrings #-} import Web.Scotty import Data.Monoid (mconcat) main = scotty 3000 $ do get "/:word" $ do beam <- param "word" html $ mconcat ["<h1>Scotty, ", beam, " me up!</h1>"]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードの最初の行は、初心者を驚かせる可能性があります：オーバーロードされた行は他​​に何ですか？ これから説明します。



私は、他の多くの人と同じように、「 より良い利益のためにHaskellを学ぼう 」と「 Real World Haskell 」という本からHaskellを学び始めたので、テキスト処理はすぐに大きな問題になりました。 Haskellのテキストの操作に関する最良の説明は、第10章の最初のHaskellで見つけました。



非常に短い場合、実際には3つの基本的なタイプの文字列データが使用されます。

• 文字列は文字のリストです。 このデータ型は言語に組み込まれています。
• テキストは、ASCII文字とUTF文字の両方を対象としたデータ型です。 テキストライブラリにあり、strictとlazyの2つの形式で存在します。 詳細はこちら
• ByteString-文字列をバイトのストリームにシリアル化するように設計されています。 これは、 バイト文字列ライブラリと、厳密と遅延の2つのバージョンで提供されます。

OverloadedStringsの見出しに戻ります。 問題は、いくつかのタイプの文字列データが存在する場合、ソースはT.pack "Hello"などの呼び出しでいっぱいになり、トークン "Hello"をテキストに変換する必要があることです。 または、トークンをByteStringに変換する必要があるB.pack“ Hello”。 この構文ガベージを使用するために、文字列トークンを目的の文字列型に独立して変換するOverloadedStringsディレクティブを次に示します。

Main.hsファイル

主な機能：

 main :: IO () main = do --      application.conf,         loadedConf <- C.load [C.Required "application.conf"] dbConf <- makeDbConfig loadedConf case dbConf of Nothing -> putStrLn "No database configuration found, terminating..." Just conf -> do --    (    — 5 ,      -- 10) pool <- createPool (newConn conf) close 1 5 10 --   Scotty scotty 3000 $ do --       «static» middleware $ staticPolicy (noDots >-> addBase "static") --   .    logStdout  logStdoutDev middleware $ logStdoutDev --       middleware $ basicAuth (verifyCredentials pool) "Haskell Blog Realm" { authIsProtected = protectedResources } get "/articles" $ do articles <- liftIO $ listArticles pool articlesList articles --     :id       get "/articles/:id" $ do id <- param "id" :: ActionM TL.Text maybeArticle <- liftIO $ findArticle pool id viewArticle maybeArticle --      Article     Article   post "/admin/articles" $ do article <- getArticleParam insertArticle pool article createdArticle article put "/admin/articles" $ do article <- getArticleParam updateArticle pool article updatedArticle article delete "/admin/articles/:id" $ do id <- param "id" :: ActionM TL.Text deleteArticle pool id deletedArticle id
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

configuratorパッケージを使用して、アプリケーションを構成します。 設定をapplication.confファイルに保存し、その内容を以下に示します。

 database { name = "hblog" user = "hblog" password = "hblog" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

接続プールには、リソースプールライブラリを使用します。 データベースへの接続は高価なので、リクエストごとに作成するのではなく、古いものを再利用する機会を与えてください。 createPool関数のタイプは次のとおりです。

 createPool :: IO a -> (a -> IO ()) -> Int -> NominalDiffTime -> Int -> IO (Pool a) createPool create destroy numStripes idleTime maxResources
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、createおよびdestroyはデータベース接続を作成および終了するための関数、numStripesは個別の接続サブプールの数、idleTimeは未使用の接続の存続時間（秒）、maxResourcesはサブプール内の最大接続数です。



接続を開くには、newConn関数（Db.hsから）を使用します。

 data DbConfig = DbConfig { dbName :: String, dbUser :: String, dbPassword :: String } deriving (Show, Generic) newConn :: DbConfig -> IO Connection newConn conf = connect defaultConnectInfo { connectUser = dbUser conf , connectPassword = dbPassword conf , connectDatabase = dbName conf }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

DbConfig自体は次のように作成されます。

 makeDbConfig :: C.Config -> IO (Maybe Db.DbConfig) makeDbConfig conf = do name <- C.lookup conf "database.name" :: IO (Maybe String) user <- C.lookup conf "database.user" :: IO (Maybe String) password <- C.lookup conf "database.password" :: IO (Maybe String) return $ DbConfig <$> name <*> user <*> password
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

入力には、application.confから読み取って解析するData.Configurator.Configが渡され、出力はIOシェルに囲まれたDbConfigである可能性があります。



初心者向けのこのようなエントリは少しわかりにくいかもしれませんが、ここで何が起こっているのか説明しようと思います。

式タイプC.lookup conf "database.name"は、おそらくIOで囲まれた文字列です。 次のようにIOから抽出できます。

 name <- C.lookup conf "database.name" :: IO (Maybe String)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、定数名、ユーザー、パスワードの種類は多分文字列です。



DbConfigデータコンストラクターのタイプは次のとおりです。

 DbConfig :: String -> String -> String -> DbConfig
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この関数は3行の入力を受け取り、DbConfigを返します。



関数のタイプ（<$>）は次のとおりです。

 (<$>) :: Functor f => (a -> b) -> fa -> fb
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり 通常の関数、ファンクターを取り、その値に適用された関数を持つファンクターを返します。 要するに、これは通常のマップです。



DbConfig <$> nameエントリは、名前から文字列を取得し（型のタイプはMaybe String）、DbConfigコンストラクターの最初のパラメーターに値を割り当て、Maybeシェルでカリー化されたDbConfigを返します。

 DbConfig <$> name :: Maybe (String -> String -> DbConfig)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、すでに1つの文字列の転送が少なくなっていることに注意してください。



タイプ（<*>）は<$>に似ています：

 (<*>) :: Applicative f => f (a -> b) -> fa -> fb
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

彼は値が関数であるファンクターを取り、別のファンクターを取り、最初のファンクターからの関数を2番目のファンクターから値に適用し、新しいファンクターを返します。



したがって、エントリDbConfig <$> name <*> userのタイプは次のとおりです。

 DbConfig <$> name <*> user :: Maybe (String -> DbConfig)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パスワードを入力する最後の文字列パラメーターが残っています。

 DbConfig <$> name <*> user <*> password :: Maybe DbConfig
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

認証

メイン関数では、最後の複雑な構造が残りました-これはミドルウェアbasicAuthです。 basicAuth関数のタイプは次のとおりです。

 basicAuth :: CheckCreds -> AuthSettings -> Middleware
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初のパラメーターはデータベース内のユーザーの存在をチェックする関数で、2番目は認証保護が必要なルートを決定します。 それらのタイプ：

 type CheckCreds = ByteString -> ByteString -> ResourceT IO Bool data AuthSettings = AuthSettings { authRealm :: !ByteString , authOnNoAuth :: !(ByteString -> Application) , authIsProtected :: !(Request -> ResourceT IO Bool) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

AuthSettingsデータ型は非常に複雑であり、もう少し詳しく知りたい場合は、こちらのソースを参照してください 。 ここでは、authIsProtectedという1つのパラメーターのみに関心があります。 これは、リクエストにより、認証を要求するかどうかを決定できる関数です。 ブログの実装は次のとおりです。

 protectedResources :: Request -> IO Bool protectedResources request = do let path = pathInfo request return $ protect path where protect (p : _) = p == "admin" protect _ = False
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

pathInfo関数には次のタイプがあります。

 pathInfo :: Request -> [Text]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リクエストを受け取り、リクエストルートを区切り文字「/」で部分文字列に分割した後に取得した文字列のリストを返します。

したがって、リクエストが「/ admin」で始まる場合、protectedResources関数はIO Trueを返し、認証を要求します。



ただし、ユーザーとパスワードを確認するverifyCredentials関数は、データベースとの相互作用を参照するため、以下のとおりです。

データベースの相互作用

接続プールを使用してデータベースからデータを抽出するユーティリティ関数：

 fetchSimple :: QueryResults r => Pool M.Connection -> Query -> IO [r] fetchSimple pool sql = withResource pool retrieve where retrieve conn = query_ conn sql fetch :: (QueryResults r, QueryParams q) => Pool M.Connection -> q -> Query -> IO [r] fetch pool args sql = withResource pool retrieve where retrieve conn = query conn sql args
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パラメータなしのクエリにはfetchSimple関数を使用し、パラメータ付きのクエリにはfetchSimple関数を使用する必要があります。 データの変更は、execSql関数を使用して実行できます。

 execSql :: QueryParams q => Pool M.Connection -> q -> Query -> IO Int64 execSql pool args sql = withResource pool ins where ins conn = execute conn sql args
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

トランザクションを使用する必要がある場合、execSqlT関数を次に示します。

 execSqlT :: QueryParams q => Pool M.Connection -> q -> Query -> IO Int64 execSqlT pool args sql = withResource pool ins where ins conn = withTransaction conn $ execute conn sql args
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

たとえば、フェッチ関数を使用すると、ログインによってデータベース内のユーザーのパスワードのハッシュを検索できます。

 findUserByLogin :: Pool Connection -> String -> IO (Maybe String) findUserByLogin pool login = do res <- liftIO $ fetch pool (Only login) "SELECT * FROM user WHERE login=?" :: IO [(Integer, String, String)] return $ password res where password [(_, _, pwd)] = Just pwd password _ = Nothing
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Auth.hsモジュールで必要です：

 verifyCredentials :: Pool Connection -> B.ByteString -> B.ByteString -> IO Bool verifyCredentials pool user password = do pwd <- findUserByLogin pool (BC.unpack user) return $ comparePasswords pwd (BC.unpack password) where comparePasswords Nothing _ = False comparePasswords (Just p) password = p == (md5s $ Str password)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、パスワードハッシュがデータベースで見つかった場合、md5アルゴリズムを使用してエンコードされたリクエストからパスワードにマッピングできます。



ただし、データベースにはユーザーだけでなく、ブログが作成、編集、表示できる記事も保存されます。 Domain.hsファイルで、id title bodyTextフィールドを使用してArticleデータ型を定義します。

 data Article = Article Integer Text Text deriving (Show)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、このタイプのデータベースにCRUD関数を定義できます。

 listArticles :: Pool Connection -> IO [Article] listArticles pool = do res <- fetchSimple pool "SELECT * FROM article ORDER BY id DESC" :: IO [(Integer, TL.Text, TL.Text)] return $ map (\(id, title, bodyText) -> Article id title bodyText) res findArticle :: Pool Connection -> TL.Text -> IO (Maybe Article) findArticle pool id = do res <- fetch pool (Only id) "SELECT * FROM article WHERE id=?" :: IO [(Integer, TL.Text, TL.Text)] return $ oneArticle res where oneArticle ((id, title, bodyText) : _) = Just $ Article id title bodyText oneArticle _ = Nothing insertArticle :: Pool Connection -> Maybe Article -> ActionT TL.Text IO () insertArticle pool Nothing = return () insertArticle pool (Just (Article id title bodyText)) = do liftIO $ execSqlT pool [title, bodyText] "INSERT INTO article(title, bodyText) VALUES(?,?)" return () updateArticle :: Pool Connection -> Maybe Article -> ActionT TL.Text IO () updateArticle pool Nothing = return () updateArticle pool (Just (Article id title bodyText)) = do liftIO $ execSqlT pool [title, bodyText, (TL.decodeUtf8 $ BL.pack $ show id)] "UPDATE article SET title=?, bodyText=? WHERE id=?" return () deleteArticle :: Pool Connection -> TL.Text -> ActionT TL.Text IO () deleteArticle pool id = do liftIO $ execSqlT pool [id] "DELETE FROM article WHERE id=?" return ()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで最も重要なのは、insertArticleおよびupdateArticle関数です。 入力としてMaybe Articleを受け入れ、データベース内の対応するエントリを挿入/更新します。 しかし、この多分記事はどこで入手できますか？



すべてが単純で、ユーザーはJSONでエンコードされたArticleをPUTまたはPOSTリクエストの本文で渡す必要があります。 JSON内外の記事をエンコードおよびデコードするための関数は次のとおりです。

 instance FromJSON Article where parseJSON (Object v) = Article <$> v .:? "id" .!= 0 <*> v .: "title" <*> v .: "bodyText" instance ToJSON Article where toJSON (Article id title bodyText) = object ["id" .= id, "title" .= title, "bodyText" .= bodyText]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

JSONを処理するには、aesonライブラリを使用します 。詳細については、 こちらをご覧ください 。



ご覧のとおり、デコード時にはidフィールドはオプションであり、JSONの行にない場合、デフォルト値は0に設定されます。Articleエントリの作成時にはidフィールドは存在しません。 idはデータベース自体を作成する必要があります。 ただし、idは更新リクエストに含まれます。

データ提示

Main.hsファイルに戻り、リクエストパラメータを取得する方法を見てみましょう。 param関数を使用して、ルートからパラメーターを取得できます。

 param :: Parsable a => TL.Text -> ActionM a
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、リクエスト関数はbody関数で取得できます：

 body :: ActionM Data.ByteString.Lazy.Internal.ByteString
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リクエストの本文を取得して解析し、Maybeを返すことができる関数を以下に示します

 getArticleParam :: ActionT TL.Text IO (Maybe Article) getArticleParam = do b <- body return $ (decode b :: Maybe Article) where makeArticle s = ""
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後に残ったのは、クライアントにデータを返すことです。 これを行うには、Views.hsファイルで次の関数を定義します。

 articlesList :: [Article] -> ActionM () articlesList articles = json articles viewArticle :: Maybe Article -> ActionM () viewArticle Nothing = json () viewArticle (Just article) = json article createdArticle :: Maybe Article -> ActionM () createdArticle article = json () updatedArticle :: Maybe Article -> ActionM () updatedArticle article = json () deletedArticle :: TL.Text -> ActionM () deletedArticle id = json ()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サーバーのパフォーマンス

テストには、8GBのメモリとクアッドコアIntel Core i7を搭載したSamsung 700Zラップトップを使用しました。

• 記事エントリを作成するための1000回の連続PUT要求。
  
  平均応答時間：40ミリ秒。1秒あたり約25リクエストです。
  
  
• それぞれ100 PUTリクエストを含む100スレッド。
  
  平均応答時間：1248ミリ秒、1秒あたり約80の同時要求。
  
  
• 1000個のGETリクエストを含む100個のスレッド、10個の記事エントリを返します。
  
  平均応答時間：165ミリ秒、1秒あたり約600リクエスト。
  
  

少なくとも何かと比較できるようにするために、Java 7とSpring 4でTomcat 7 Webサーバーを使用してまったく同じサーバーを実装し、次の数字を受け取りました。

• 記事エントリを作成するための1000回の連続PUT要求。
  
  平均応答時間：51ミリ秒。1秒あたり約19〜20リクエストです。
  
  
• それぞれ100個のPUT要求を含む100個のスレッド。
  
  平均応答時間：104ミリ秒、1秒あたり約960の同時要求。
  
  
• 1000個のGETリクエストを含む100個のスレッド、10個の記事エントリを返します。
  
  平均応答時間：26ミリ秒、1秒あたり約3800リクエスト。
  
  

結論

Haskellの練習が不足していて、その上でWebアプリケーションを作成しようとする場合、記事-記事で説明されている1つのエンティティに対するCRUD操作を使用した単純なサーバーの例を見つけることができます。 アプリケーションはJSON RESTサービスとして実装され、安全なルートでの基本認証が必要です。 MySQL DBMSはデータストレージに使用され、接続プールはパフォーマンスを改善するために使用されます。 アプリケーションはセッションに状態を保存しないため、水平方向へのスケーリングは非常に簡単です。さらに、ステートレスサーバーはマイクロサービス アーキテクチャの開発に最適です。



Haskellを使用してJSON RESTサーバーを開発することで、短くて美しいソースを取得できました。これは、とりわけ、リファクタリング、変更、追加に多くの作業を必要としないため、保守が容易です。 コンパイラは、すべての変更の正確性をチェックします。 Haskellを使用することの欠点は、Javaで作成された同様のサービスと比較して、結果のWebサービスのパフォーマンスがそれほど高くないことです。

PS

コメントのアドバイスに基づいて、追加のテストを実施しました。 スレッド数をN = 8に変更しても、パフォーマンスには影響しません。 Nがさらに減少すると、パフォーマンスが低下します。 私のラップトップには8つの論理コアがあります。



別の興味深いこと。 データベースへのレコードの保存を無効にすると、Haskellに対するサービスの応答の平均遅延は6ミリ秒（！）に低下します。Javaの同様のサービスでは、今回は80ミリ秒です。 つまり 示されているプロジェクトのボトルネックはデータベースとの相互作用です。これをオフにすると、HaskellはJavaの同様の機能よりも13倍高速になります。 メモリ消費量も数倍低くなります。400MBに対して約80MBです。