Closed5

Meta: 2020.11w5

okuokuokuoku

prev: https://zenn.dev/okuoku/scraps/8977ee384285683980ce
next: https://zenn.dev/okuoku/scraps/b485da18176fdc

★ queue

  • DryScheme(C++): SECDV Scheme VM バイトコードの復習 → 共通bootstrap I/Oフレームワーク設計 → Scheme-on-Scheme 実装。 C++例外として try catch での実装をやるとして、VMバイトコードを追加するべきか?それともVM stateをいじるintrinsicで十分か? ← call-in intrinsic 1つで済ませる。YuniFFIやI/Oフレームワークのcalloutと共有する。
  • YuniFFI: libclangでのAPIスクレイピング → API request packer の仕様決め → packer実装とbytevector APIの見直し → バインディング実装(apidataリポジトリ分離)
  • GitAsBackend: XMLどうすんのか問題、index hintsの書き方問題、MongoDB + Groonga アプライアンスを作ってGitのコミットメッセージ検索をしてみるとか。。?
  • WebGL-C: EGL部分の抽象化をどうすんのか問題。 ... SDLとかを抱えるしかないかな。。
  • RISC-V: https://qiita.com/okuoku/items/0aaa76c34f8ee3aa330a の続き。
  • WASM: Yunibaseに相当する実装アーカイブが必要だけど死んでる実装が多く難しい。Scheme処理系みたいになってないかコレ。YuniFFI stubの呼び出しプロトコルを決める、各インタプリタ向けに実装する、null libcを移植、LLVM libcの調査。 setjmp / longjmp の出力コード比較の会。
  • DualSense: 4ch Audioで歩かせたい 歩かず。
  • Tew: Behaviour TreeベースのAIに替える。Atari記事化とドロップ。
  • deCoda: 買った → JUCE部分の音声出力が不調すぎる
  • GameSynth: 買った → ライセンスが割と不安。外部VSTと合わせてAmbisonicsの制作を試す。
  • SonarPen: 発注した → 届いて分析した。
okuokuokuoku

GraphQL

https://techlife.cookpad.com/entry/2020/12/01/093000

から、

https://github.com/graphql/express-graphql

でプロダクションのサーバを作っているのを知る。。GraphiQLのホストとかもできるのかコレ。

GraphQLはチュートリアルの:

https://www.howtographql.com

が割と良い出来。

... で、ただのREST代替として採用するのはどうだろうか。重要なConsとしてWeb標準だけではクライアントが事実上作れない(クエリビルダを作るのがめんどい)という問題があるけど、 サーバサイドでGraphQLを使う (REST API to GraphQLのブリッジサーバを用意する)という解決策を思いついた。よくあるユースケースは逆で、GraphQLで既存のRESTやgRPC APIサーバをwrapするというもの。

制御リポジトリに置いたSchema YAMLをgraphQLスキーマに変換する良い処理系が書ければ、MongoDB ←→ GraphQL APIサーバのブリッジは適当に世間の実装を流用できないだろうか。

express-graphql も機能はすると思うけど、まぁApollo serverで良いかな。。

https://github.com/apollographql/apollo-server

okuokuokuoku

(GitAsBackend)

そろそろ命名要るな。。

いわゆるHeadless CMSとの違い

ココZennも含めgitでコンテンツを管理できるCMSも割とある。営業上のポイントは?

  1. ステートレス性 。状態を持つのはGitリポジトリのみ。URL決めてHelmで導入 → pushすれば終わり。
  2. 柔軟性 。初心者向けではない(DB設計と同等の努力が要る)。
  3. Fire and forget / 再現性 。失敗したなと思ったらDBを消して再構築すれば良い。Gitリポジトリ以外の状態はない。

クラウド各社のManaged NoSQL類との相互運用性も考えられるけど、ちょっと料金モデルが合わない。insertのようなオペレーションに課金があるので100万オブジェクトのリポジトリのDBを再構築するだけでだいぶ掛かる。今はまだManaged DBよりもIaaSの方が安く、マネージドサービスにおけるメンテナンス性やスケーラビリティに載っているプレミアムをこのアーキテクチャは活用できない。

Gitコンテンツサーバ

ココをGraphQLにできるか検討する(GitHub互換にするという意味ではなく、単にコミットログとoidをfetchするだけのAPIサーバをGraphQL語彙で作ったらどうなるか)。phase1はGitHub/GitLab直接アクセスはやらない。Webhookでmirrorをキックするのみ。

XMLデータ

phase0のxml-js → 独自Schemaをxml2jsと比較したい。たぶん検索index定義にschemaを吸収させてしまうのが良い。データは100万件 〜 1000万件くらいだし 〜 1日で再パースできる。

https://www.npmjs.com/package/xml2js

https://www.npmjs.com/package/xml-js

例えば、mongoDBにXML生データをxml2jsしただけのオブジェクトを突っ込んで、indexだけで頑張ることは可能か?ドキュメントが簡単に16MiB超えると厳しいかもしれない。

16MiBに決まったJIRA:

https://jira.mongodb.org/browse/SERVER-431

Textデータ

正規表現でフィールド分割する。検索indexに混ぜる。

Groonga index

一旦Elasticを落としてphase1はGroongaに集中する。

https://github.com/groonga/groonga

検索indexの定義方法

つまりindex定義YAMLが超高機能になってしまう。JSON Schema書いた方が良いかも。。

  • いわゆる普通の検索index定義機能
  • ファイルパスフォーマットの定義機能
  • 要素の事前split機能 -- 16MiB超えないように人間が手動で分割できるようにする
  • Textのフィールド定義機能
  • ...
このスクラップは2020/12/05にクローズされました