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: ~~発注した~~ → 届いて分析した。

okuoku

★ fork

okuoku

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で良いかな。。

okuoku

(GitAsBackend)

そろそろ命名要るな。。

いわゆるHeadless CMSとの違い

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

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

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