Cache

IO server, compiler, rush parser, and UI are what we call the EdgeQL server
Rust parser is maintained by compiler team
Compiler is in pure Python
filter name = <string>
- string is extracted by parser so that cached query can still be leveraged if the string changes
cache is shared across all clients
- limited to 1,000 entries
We cache prepared statement in SQL so we can reuse later
Query results are not cache
LRU- least recently used (is discarded)
SQL is stored as text in cache with a hash
- Hash is used to see if a given Postgres connection

General

Server maps to edgedb/edgedb repo
Postgres uses vanilla postgres/postgres repo without any modifications
- Support up to postgres version 13
edgedb-python for server-side tests
pg layer to support BI tools (new)
- Doesn’t connect directly to the postgres server
EdgeDB binary protocol is the most common way to interface with the EdgeDB service
- Used by all the clients
GraphQL, EdgeQL, binary, and notebook protocol can all be used over HTTP
- notebook is legacy, used by the web site
- binary takes binary over HTTP and sends back binary
  - used by EdgeDB UI
UI maps to edgedb-ui
- UI is used by the web site
- Cloud instances will share a single UI accessing the selected instance
edgedb/edgedb-docker
- Can be managed by CLI
edgedb/nebula-ui will be different than edgedb-ui
- Used to manage
edgedb/shared-test-case
- Used to test all client bindings
Still discussing how to manage schema in production
- Don’t want users to connect CLI to production to run migrations
- Ongoing conversation
- Can connect CLI to production, but Fantix doesn’t recommend it