テルアビブのFacebook ConnectivityチームにおけるGoの活況について
20ヶ月前、私はテルアビブにあるFacebook Connectivity (FBC) チームに参加しました。Goでのプログラミングを約5年間行い、いくつかの企業に組み込んでいました。
私が参加したチームは新しいプロジェクトに取り組んでいて、このミッションのために言語を選択する必要がありました。 我々はいくつかの言語を比較し、Goと共に行くことにしました。
それ以来、Goは他のFBCプロジェクトでも普及し続け、テルアビブだけで約15人のGoエンジニアを抱える大成功を収めました。 新しいサービスがGoで書かれるようになりました。
Goで新しいORMを書いた動機について
Facebook以前の5年間の私の仕事のほとんどは、インフラツールやマイクロサービスに関するもので、データモデルに関する仕事はあまりありませんでした。 SQLデータベースでちょっとした作業をする必要があるサービスでは、既存のオープンソースのソリューションを使用していましたが、複雑なデータモデルを扱っていたサービスでは、堅牢なORMを用いて別の言語で書かれていました。 例えば、SQLAlchemy を使った Python です。
Facebookでは、データモデルをグラフの概念で考えています。 このモデルは社内でも良い経験になっています。
Goのための適切なグラフベースのORMがないため、私たちは次のような原則に基づいてここでORMを書きました。
- Schema As Code - 型、関係、制約の定義は、(structタグではなく) Goコードで行う必要があり、CLIツールを使って検証する必要があります。 Facebookの社内でも同じようなツールを使って良い経験を得ています。
- codegenを用いた静的型付けと明示的なAPI - 至る所に
interface{}があるAPIは、開発者の作業効率に影響を与えます。(特にプロジェクトの初心者に対して) - 問い合わせ、集計、グラフ のトラバーサル (横断) はシンプルであるべき - 開発者は、生のSQLクエリやSQL用語を扱いたくありません。
- 述語は静的に型付けされるべき どこにも文字列は持ちません。
context.Contextの完全なサポート - これは、トレースやログのシステムで完全な可視性を得るのに役立ち、キャンセルなどの他の機能にも重要です。- ストレージに依存しない - 当初はGremlin (AWS Neptune) で開発を開始し、後にMySQLに切り替えたため、codegenテンプレートを使用してストレージ層を動的に保つようにしました。
entのオープンソース化について
entは、上述の原則に基づいて構築された、Goのためのエンティティフレームワーク (ORM) です。 entは、任意のデータモデルやグラフ構造をGoコードで簡単に定義することを可能にします。スキーマ構成は、entc (entのcodegen) によって検証され、Go開発者の生産性と満足度を維持するための慣用的で静的に型付けされたAPIを生成します。 MySQL、MariaDB、PostgreSQL、SQLite、およびGremlinベースのグラフデータベースをサポートしています。
本日、entをオープンソース化し、entgo.io/docs/getting-startedから始めていただけるようにしました。