ノードからクリスタルへの旅

Duoは長年にわたってNodeをメインプラットフォームとして使用してきました。 しかし、最近、彼らは非常に新しいCrystal言語で実験しており、まだ完全には形成されていません。 彼らによれば、彼らがそれをやればやるほど、彼らはそれに執着するようになりました。



本日は、NodeおよびCrystalプラットフォームの長所と短所、およびDuoでますます多くのサーバープロジェクトがCrystalに移行される理由についての翻訳を翻訳したいと思います。

ノード

▍期待

数年前にノードに切り替えました。 当時私たちは少数の開発者を抱える小さな会社であり、従業員はできるだけ多才である必要がありました。 開発者がフロントエンドまたはバックエンドに特化できるようにすることは、私たちにとって達成不可能な贅沢でした。 サーバーまたはアプリケーションのクライアント部分で多くの作業が行われた場合、専門分野に関係なく、問題に対処できる人が必要でした。



Nodeは私たちにとって完全に明白な選択肢のように思えました。 JavaScriptを知っている開発者を採用した場合、これは彼がクライアントプロジェクトとサーバープロジェクトの両方で作業できることを意味していました。 ツール、構文、依存関係は重複し、すべてのタスクはJavaScriptを使用するため、スキルが向上します。

▍現実

サーバーコードとクライアントコードの目標はまったく異なります。これらのタイプのコードには、非常に異なる作業方法の知識が必要です。 通常、クライアントコードは、ユーザーとの対話、インターフェイスの更新、サーバーからのデータ要求の実行です。 開発者は通常、webpackまたはbrowserifyを使用してコードをパッケージ化し、Reactでインターフェイスを開発し、CSSフレームワークを使用してページレイアウトを簡素化しました。



サーバー上で、プログラマはデータベースへのSQLクエリ、ORM、ファイルの読み取りと書き込みを処理し、サードパーティAPIとの相互作用を整理します。 サーバー上のデータストリームは、要求/応答モデルに従います。 リクエスト間で、すべてのタスクが回答を提供する必要があり、これはすべて特定の方法で実行する必要があります。 特定のステップが前のステップで得られた結果に依存している場合、対応するプロセスを順番に実行する必要があります。そうでない場合は、並行して実行できます。

▍標準的な非同期性

Nodeは、各タスクを非同期で実行するように設計されています。 つまり、5つのタスクを完了するようにNodeに依頼すると、彼はこれをすべて同時に実行しようとします。 過去数年間、約束はこの仕事のモデルをサポートする主な手段でした。 一言で言えば、Promiseを使用すると、プログラマは非同期タスクのセットを連鎖できます。非同期タスクは、次々に実行される一連のステップです。



サーバーでは、並列タスクの標準的な使用は非常に効果的なアイデアのように思えるかもしれません。 実際には、私たちが直面しているほとんどのタスクについて、以前のタスクから取得したデータが必要です。 タスクを並行して実行できたとしても、システムリソースはすぐに使い果たされる可能性があります。つまり、データベースに対する多数の並行クエリの実行により、接続のプールが使い果たされ、同時にサービスを提供できるユーザーの数が減ります。



Nodeを長年使用して、約束からチェーンを作成することは私たちの標準になりました。 記述されたコードの半分は、非同期タスクを順次解決されるタスクに変えることを目的としていました。 これらの一連の約束は、テストやデバッグが難しく、コードが特にわかりにくいわけではありません。 タスクとサブタスクが実行される順序でさえ、コードを単に見るだけでは理解しにくいことがよくあります。



Nodeの作成者であるRoal Dahlは、この状況を非常にうまく説明し、インタビューでNodeとGoを比較しました 。



しかし、このシステムがプログラマーに提供するインターフェースはブロックされており、実際、これはより成功したプログラミングモデルだと思います。 ブロッキングアプローチを使用すると、多くの状況で、実行されたアクションの本質を確認する方がはるかに優れています。 一連のアクションが多数ある場合、システムに次のようなことを伝える機能は非常に便利です。「タスクAを解決し、答えを待って、エラーを出してください。 問題Bを解決するか、回答を待つか、エラーを返します。 Nodeでは、関数呼び出し間で絶えず「ジャンプ」する必要があるため、これを達成することははるかに困難です。

yn動的タイプ

JavaScriptで定期的にプログラムしている人はだれでも、遅かれ早かれ「undefined is not object」というエラーに慣れるでしょう。 このエラーは、オブジェクトと見なすが、null値が書き込まれている変数のメソッドまたはプロパティにアクセスしようとすると発生します。 コードの非同期セクション間で転送されるデータを制御するだけでは十分ではありません。また、アプリケーションコードの任意の場所の型で何が起こっているかを認識する必要があります。 アプリケーションが1つのプロセスからデータを受信して​​別のプロセスに渡すたびに、クラッシュが発生する場合があります。 すべての可能な値を処理する可能性を提供しない場合、サーバーはエラーをスローするか、さらに悪いことに、予期しないことを行います。

クリスタル

Nodeで作業しながら、Python、PHP、Ruby、Goなど、他の多くの言語とプラットフォームを調べました。 原則として、それらはNodeよりも遅いか、開発目的にはそれほど便利ではありませんでした。 速度と構文は、特定の制限までしか最適化できない言語の2つの要素です。



その後、昨年、Crystal言語に関する記事を読みました。 これは、LLVMを介してマシンコードにコンパイルされる新世代の言語のものです。 その構文はRubyに似ています（私は気に入っています）が、Goと同じくらい高速に動作します（そしてこの獣は速度を取りません！）。



クリスタルはまだ非常に若いですが、コンテンツ管理システムの一部のサーバー部分をクリスタル上でやり直すことにしました。 うまくいきました。 仕事中に私が見つけたものは次のとおりです。

• クリスタルは高性能を備えています。 私のタスクでは、Nodeの2倍高速でした。
  
  
• 使用するメモリはごくわずかです。 Crystalは通常、プロセスごとに5 MB未満、ノードは200 MB以上必要です。
  
  
• その結果、典型的な問題を解決するために優れた標準ライブラリを備えており、100個のNode依存関係と比較して、12個の依存関係のみが必要でした。
  
  
• デフォルトでは、コードは同期的に見え、Nodeなどのイベントループを使用しますが、同時実行の整理には軽量スレッドが使用され、Goのようなチャネルを介して対話が整理されます。 これにより、コードが理解しやすくなります。
  
  
• Crystalは静的に型指定されているため、コンパイル時にエラーを見つけることができます。
  
  
• Crystalは型を推測します。その結果、型注釈を頻繁に使用する必要がないため、その型システムは使いやすいです。
  
  

Crystalでのプログラミングが大好きだったので、CMSのバックエンド全体をこの言語で書き直しました。 そのAPIはNodeベースのCMSと互換性があるため、比較的少ない労力でWebサイトを新しいシステムに転送したり、古いシステムに戻したりできます。 Crystalはまだ若いプロジェクトであり、保険が必要なので、これは重要です。



DuoCMSをCrystalに完全に書き換えた後、実稼働環境でテストする必要がありました。 実際、この資料のオリジナルは、Crystalで実行されるサイトに投稿されています。

NodeNodeとCrystalのコード比較

比較のために、以下は、CrystalおよびNodeで記述されたコントローラーコードのわずかに簡略化されたバージョンです。



これがNode上のコントローラーです（Expressフレームワークを使用）。

const express = require('express') const app = express() const bodyParser = require('body-parser') const UserService = require('user-service') app.use(bodyParser.json()) app.get('/', function (req, res) {  res.send('Hello World!') }) app.post('/api/users', function (req, res) {  if(request.body){    UserService.save(request.body)    .then(function(){      res.send('user saved')    })    .catch(function(err){      res.send(err)    })  }else{    res.send("no user provided")  } }) app.listen(3000, function () {  console.log('Example app listening on port 3000!') })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これがCrystal上のコントローラーです（Kemalフレームワークを使用）。

 require "kemal" require "user" require "user-service" get "/" do "Hello World!" end post "/api/users" do |ctx| if (json = ctx.request.body)   user = User.from_json(json)   UserService.new.save(user)   "user saved" else   "no user provided" end end Kemal.run
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これら2つの例の構造が非常に似ていることは簡単にわかります。 ただし、Promiseが不要になると、コードの合計量は減少しました。 より大きなアプリケーションを作成する場合、これは著しく強力です。 DuoCMS 5サーバーコードは、約15,609行のJavaScriptで構成されています。 DuoCMS 6コードは、10,186行近くです。 DuoCMS 6には現在、実装に必要なコードが30％少ない、より多くの機能があります。 同時に、約束がないため、このコードは読みやすく、保守しやすいです。

Crystalには何が欠けていますか？

開発者は、Crystalの現在のリリースをアルファバージョンと呼びます。 ここで、生産用に設計されたはるかに複雑でないフレームワークを使用しなければならなかったことを言わなければなりません。 最悪のシナリオでは、Crystalは現在ベータ版です。 ただし、開発者の注意は理解できます。 アルファ版について話します。これにより、操作、変更、APIの破壊などの余地が与えられます。



Crystalを約1年間使用していますが、プロジェクトの開発と、これがまだアルファ版であるという事実のために、わずかな変更にしか遭遇していません。 フロントエンドでReactを更新する際にさらに問題が発生しました。 さらに、CrystalはCrystalで書かれていると言っておく価値があります。つまり、動作しないことが判明した場合は、言語と標準ライブラリで修正を行うことができます（私はそうしました）。



現時点では、Crystalの主な欠落機能には次のものがあります。

• Windowsのサポートはまだありません（これは気にしません。Macで作業し、Linuxでコードを展開します）。
  
  
• まだ真の並列性はありません（Nodeではそうではありません）。
  
  
• インクリメンタルコンパイルはありません（これは、コードに変更を加えた後にシステムをコンパイルするのに非常に便利なため、約8秒かかります）。
  
  
• Crystal向けに十分にサポートされているオープンソースライブラリはあまりありませんが、ここでは、Crystalが本格的なプロジェクトで使用されるようになったときにすべてが整いました。
  
  

私たちにとって、これらの欠点はどれもクリスタルを放棄する理由ではありませんでした。 私たちが使用するライブラリに欠けている機能を実装する追加を行う必要がありましたが、これはNodeで作業しているときにも起こりました。 最後に、クリスタルにとても満足していると言えます。

まとめ

クリスタルを試してみませんか？ はい、そうです！ 事は本当に素晴らしいです。 Crystalでプログラムするのは良いことです。コードは読みやすく、編集も簡単です。 ちなみに、Crystalを使用してこの言語の開発に貢献する人が多ければ多いほど、その言語は良くなります。 すべてを自分の目で見たいですか？ インストール手順は次のとおりです。 こちらがプロジェクトサイトです。 そして、これはCrystalチャットです 。もしあれば、@ criswardに私を書いてください。



Crystalを実稼働環境で使用するかどうかを尋ねる場合は、それが必要です。 個人的には、実用に適したものを作る唯一の方法は、失敗が許容される問題でそれを試してから、徐々に大きなプロジェクトでこれに切り替えることだと思います。 たとえば、非常にトラフィックの多いプロジェクトや重要なエリアで、クリスタルをどこでも使用していません。 すべてのサイトを監視し、定期的にバックアップします。さらに、Crystalに何かが発生した場合に備えて、Nodeは常に手元にあります。



親愛なる読者！ プロジェクトでCrystalを試す予定はありますか？