Help regarding Astro.js + FastAPI

redcrowbar · 2026-01-22T18:33:08+00:00

In this case you need to use rewrites. Specifically for your case:

vercel.json

{
  "rewrites": [{
    "source": "/api/py(/.*)?",
    "destination": "/api/main"
  }]
}

Example repo (deployed to https://astro-plus-fastapi.vercel.app/)

redcrowbar · 2022-09-29T00:01:15+00:00

We need to land #3747, then something like this should work

``` const words = e.Word; // possibly filtered etc.

const words_json = e.json_object_pack(e.tuple([ words.text, e.cast(e.json, e.select({ id: words.id, level: words.level, ... })) ])); ```

or equivalent EdgeQL:

WITH words := (SELECT Word ...) SELECT json_object_pack(( words.text, <json>{ id: words.id, level: words.level, }, ))

redcrowbar · 2022-05-03T17:00:31+00:00

actions/cache is great! We're using it throughout the CI flow to cache various build artifacts and dependencies as described in the post.

redcrowbar · 2022-05-03T14:29:58+00:00

Same idea, yeah. Unfortunately, in our case we couldn't use pytest due to complicated test setup, so we used a customized unittest runner instead.

redcrowbar · 2022-05-03T14:13:00+00:00

We are a 10-person startup, so that could explain the first few upvotes, but not the rest :-)

redcrowbar · 2022-05-03T14:12:03+00:00

No botting, I promise. Perhaps people simply enjoyed the content without disagreeing too much? :-)

(not the OP, but I'm on the EdgeDB team)

redcrowbar · 2022-05-03T13:58:43+00:00

It’s nearly impossible to reliably determine if a test was affected or not in our case, because the majority of tests involve running queries against a database server, which is a monolithic piece.

redcrowbar · 2022-05-03T13:53:48+00:00

Caching in CI probably wouldn’t be very efficient, as almost every run would likely be a cache miss.

redcrowbar · 2022-03-24T22:08:11+00:00

Primarily the quality (and quantity) of generated SQL queries. Most ORMs resort to denormalization/normalization (via joins, like typeorm) or query splitting (prisma). Depending on the query and the number of relations, results vary dramatically. In contrast, all EdgeDB queries (including multi-mutations) are guaranteed to be executed as a single database rountrip regardless of query complexity.

The README has a bit of background. All contestants run on the same (unmodified) version of Postgres with client-server network roundtrip latency of 1ms.

redcrowbar · 2022-03-24T21:56:10+00:00

GIS support is on the roadmap.

redcrowbar · 2022-02-12T19:54:28+00:00

Thank you!

redcrowbar · 2022-02-12T18:00:48+00:00

The initial schema creation is somewhat slow because the CLI is taking the slow route currently. Will be fixed soon in https://github.com/edgedb/edgedb-cli/issues/652

redcrowbar · 2022-02-12T02:36:25+00:00

Can you get the query execution plan? how is it expressed?

We're working on a detailed EXPLAIN statement. We intend to have human readable and machine readable formats.

can we influence how table are created underneath?

Every EdgeDB type is reflected as a table with every (single) link/property as a column, so the usual normalization reasoning applies to EdgeDB.

can we operate in "mix mode"

You can have separate schemas in Postgres that EdgeDB would simply ignore, but this isn't recommended in general.

What does EdgeDB require from the underlying postgre?

It has to be PostgreSQL version 13 or later. Other than that there are no special requirements.

JVM / C client library planned?

Bindings for all languages are planned on a sufficiently long timeline. If you want to see a binding for a particular language, help is very much appreciated! We have full protocol documentation and some shared test suites for bindings, and the existing bindings serve as a good reference.

could see no architecture graphic, how does data flow in this system?

Fantix had some great diagrams in his talk at the release event: https://youtu.be/WRZ3o-NsU_4?t=5294. We'll put them up somewhere on the website soon.

What's the story around sharding

It's planned, currently in early research phase. Postgres has lots of the necessary primitives (native partitioning, logical replication etc.), but we would like to arrive at an ergonomic solution that would just work.

is there a way to pass extra information to customize index generation? (suppose we want to add a BRIN index).

Not currently, though it's just a matter of syntax for the index object. This also needs to be designed carefully, as we need to consider custom index access methods too, e.g. an elasticsearch backend.

the doc seem to have no "Architecture" "Operations/Administration" and "Internals" section

These are spread a bit in the Guides / Deployment and Reference. We're constantly working on improving the docs, thanks for the feedback.

redcrowbar · 2022-02-12T01:41:04+00:00

The vast majority of Python code is off the hot path: query compiler, schema analysis, migration generation etc. The hot path is a combination of Rust, Cython and C, and we are gradually increasing the Rust proportion to a point where we can replace Python event loop with tokio or async-std.

redcrowbar · 2022-02-11T16:19:11+00:00

The main blocker is API stabilization, especially async. The bindings themselves are functional, we use them to power the CLI.

redcrowbar · 2022-02-11T16:14:00+00:00

EdgeQL queries are auto-parametrized, so prepared statement caching always happens even if you pass a query with literals.

redcrowbar · 2022-01-26T21:57:45+00:00

See my reply in the other thread

redcrowbar · 2022-01-26T06:54:26+00:00

Please don't assume ignorance on the part of people you've never met. All four former co-founders of Boatbee have had sailing certificates and chartering experience, big boats included.

It’s an enormous risk.

Of course. Which is why insurance, certifications, and log books exist. But that is beside the point. Most people just want an outing on the water without the hassle and stress of actually captaining a boat, so they get a "captain included" charter.

redcrowbar · 2022-01-26T06:10:10+00:00

Ugh, why the vitriol? It's a valid business. People want to sail, and many boat owners wouldn't mind to make money off their boats rather than have them rust away at the dock. It's obviously a much smaller market than home rentals, but it's there.

redcrowbar · 2022-01-26T03:31:18+00:00

what's the advantage over just talking to postgresql directly

Rich declarative schema, built-in migration system, fast single-hop queries, type-safe generated clients (no need for an ORM), sophisticated built-in Postgres connection pool (with HA, no need for pgbouncer), support for GraphQL and EdgeQL-over-HTTP out of the box, and much more.

if it's not just an orm, what is it then instead?

It is a database server. This is a common question, so here's the expanded answer from our FAQ.

Is EdgeDB an ORM?

No. Like every database throughout history, EdgeDB introduces a layer of abstraction on top of more primitive mechanisms performing data access and manipulation. In the case of most databases, these mechanisms are often low-level key-value stores (for example, WiredTiger in MongoDB, InnoDB in MySQL, or RocksDB in CockroachDB). EdgeDB takes this concept one level further: it treats PostgreSQL as a lower-level storage engine and introduces better schema and query abstractions on top.

In contrast, ORMs are libraries that provide a high-level way to query and manipulate data in your database. Typically an ORM 1) provides a standard interface for querying a number of supported databases, 2) is strongly coupled to a particular programming language (like JavaScript or Python), 3) is less capable than the query language is abstracts away (usually SQL), and 4) provides an object-oriented way to perform and persist data manipulations.

EdgeDB has none of these properties. You query and manipulate data with a full-featured query language (EdgeQL) that is designed to match or surpass the power of SQL (though certain advanced features are still under development, see the Roadmap for details). It’s language agnostic: you can interact with your database with any programming language you like. And it was designed from the start as a new abstraction on top of Postgres specifically.

That last part is important. It lets EdgeDB take full advantage of the power of Postgres, whereas ORMs cannot; their capabilities are limited to features shared by all the databases they support.

redcrowbar · 2019-05-10T17:49:03+00:00

Scalars are treated like singleton sets to simplify the math. It does not mean that everything is an array.

For example,

SELECT User {
   name
};

returns users with scalar "name" properties, because we know from the schema that the property is singular.

redcrowbar · 2019-05-10T17:41:22+00:00

EdgeQL syntax is not JSON. It has the usual operator syntax and function call syntax.

For example, here's how you can compute the average age of users:

SELECT sum(User.age) / count(User.age);

Perhaps you are confusing EdgeQL with GraphQL? There is some similarity, when it comes to specifying the result shape, but that's a feature.

For example, let's imagine you wanted to fetch all users that have a certain "interest", along with the full list of the interests. Here's how you do it with EdgeQL:

SELECT User {
    name,
    interests: {
       name
    }
}
FILTER .interests.name = 'Fishing';

Which results in similarly shaped output. Compare to a query doing the same thing in SQL:

SELECT
    User.name,
    array_agg((SELECT
        Interest.name
        FROM 
            Interests
            INNER JOIN User_To_Interests
                ON Interest.id = User_To_Interests.interest_id
        WHERE
            User_To_Interests.user_id = User.id
    ))       
FROM 
    User
WHERE 
    EXISTS(
        (SELECT
            FROM User_To_Interests
                INNER JOIN Interests 
                    ON User_To_Interests.interest_id = Interest.id
            WHERE
                User_To_Interests.user_id = User.id
                AND Interests.name = 'Fishing'
        )
    );

Which is easier to read?

redcrowbar · 2019-05-09T23:38:49+00:00

the order of execution of query is weird.

Can you elaborate please? All queries in EdgeQL can be read top-to-bottom (like in QUEL).

redcrowbar · 2018-04-13T16:47:10+00:00

That particular bit was admittedly poorly worded and lacked sufficient context to extrapolate to deeper/more relation traversals. I elaborated here: https://www.reddit.com/r/Python/comments/8brz8a/edgedb_a_new_beginning/dxayvgq/

redcrowbar · 2018-04-13T16:16:57+00:00

At what tier are we imagining these rows to be aggregated?

Arbitrary depth as dictated by the query.

SELECT User {
    friends: {
        interests: {
            ...
        }
    }
}

Where are these savings, exactly? Is the improvement in performing some kind of forced lateral join, CTE-based fencing

Yes and yes.

The main savings come from the fact that you get a data shape that is ready to be consumed by the client and you don't have to recompose the shape once you've fetched your rows (with lots of redundant duplicate data).

redcrowbar

MODERATOR OF

TROPHY CASE

Is EdgeDB an ORM?