edgedb VS uvloop

A new DB, with a new query language that's like "SQL done right"? This immediately reminded me of EdgeDB: https://edgedb.com/

Is there anyone here who knows enough about these two products to do a compare/contrast?

The whole thing consists of these main parts:

1. SQL parser: https://github.com/edgedb/edgedb/tree/master/edb/pgsql/parse...

>relational no-sql

Do you mean something like edgeDB?[0]

Or do you mean some non-declarative language completely? I don't see the latter making much sense. The issue with SQL for me is the "natural language" which quickly loses all intended readabilty when you have SELECT col1, col2 FROM (SELECT * FROM ... WHERE 1=0 AND ... which is what edgeDB is trying to solve.

[0]https://edgedb.com/

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

You have to do your own optimiser to avoid, for instance, the N+1 query problem. (Just Google that, plenty of explanations around.) Many GraphQL frameworks have a “naive” subquery implementation that performs N individual subqueries. You either have to override this for each parent/child pairing, or bolt something on the back to delay all the “SELECT * FROM tbl_subquery WHERE id = ?” operations and convert them into one “… WHERE id IN (…)”. Sounds like a great use of your time.

In the end you might think to yourself “why am I doing this, when my SQL database already has query optimisation?”. And it’s a fair question, you are onto it. Try one of those auto-GraphQL things instead. EdgeDB (https://edgedb.com) does it as we speak, runs atop Postgres. Save yourself the enormous effort if you’re only building a GraphQL API for a single RBDMS, and not as a façade for a cluster of microservices and databases and external requests.

Or just nod to your boss and go back to what being a backend developer has always meant: laboriously building by hand completely ad hoc JSON versions of SQL RBDMS schemas, each terribly unhappy in its own way. In no way does doing it manually but presenting GraphQL deviate from this Sisyphean tradition.

I read in the article that NOT having GraphQL exactly match your DB schema is a best practice. My response is “did a backend developer write this?”

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.

EdgeDB [1] has indeed a rich GraphQL layer, but it's a very different project.

While it also builds on top of Postgres, EdgeDB replaces the entire relational database front-end. EdgeDB features a SQL replacement language called EdgeQL (analytical capabilities of SQL married with deep-fetching in GraphQL), a higher-level data model (tables -> object types), integrated migrations engine, a custom protocol with great performance & great client APIs, and many other things. Read more here [2].

(disclaimer: I'm EdgeDB co-founder)

[1] https://github.com/edgedb/edgedb

[2] https://www.edgedb.com/blog/edgedb-1-0

I'm curious how this squares up with what someone linked elsewhere: https://github.com/edgedb/edgedb/discussions/3403

> EdgeDB does not treat Postgres as a simple standard SQL store. The opposite is true. To realize the full potential of the graph-relational model and EdgeQL efficiently, we must squeeze every last bit of functionality out of PostgreSQL's implementation of SQL and its schema.

This would seem to be an opposing view of how coupled EdgeDB and PostgreSQL are. Which is it?

I wound up on a different team with pre-existing Python code so temporarily shelved my use of Go for a bit, and we used Sanic (an async Python framework built on top of the excellent uvloop & libuv that also powers Node.js) to build some APIs for live channel management & operations. We hand-wrote our OpenAPI and used it to generate documentation and a CLI, which was an improvement over what was there (or not) before. Other teams used the OpenAPI document to generate SDKs to interact with our service.

If you're looking for maximum requests per second you can change the asyncio event loop with one like UVLoop.

An optional package uvloop can also be install if working on Linux:

The source code from the project resides in the github, with more than 8.6k stars and 596 forks is a very popular github, but no new releases are made since 2018, looks pure much not maintained anymore, no PR's are accepted no Issues are closed, still without windows or macOS Silicon, or PyPy3 support. Japronto it self uses uvloop with more than 9k stars and 521 forks and different from japronto is seems to be well maintained.

If you are building server-side applications using Python 3 and async API and if you didn't use https://github.com/MagicStack/uvloop, you are missing out on performance big time.

Also, if you happen to build microservices, don't forget to try PyPy, that's another easy performance booster (if it's compatible to your app).

Not that bad actually, with a different event loop implementation (such as https://github.com/MagicStack/uvloop). Not sure how well it will perform in a browser though

And so I did some searching, and found that SearX isn't officially supported on Windows. Not to be deterred, I did another quick search and found that with pip and/or docker, you should be able to install SearX straightforwardly on Windows. After trying this for a bit, I realized that uvloop, a (questionably optional dependency of SearX) is not supported on Windows. I tried a couple things to get it to work, but they didn't end up working for me either through user error, ignorance, or plain old not working.

they also wrote uvloop [0] which is fantastic and advances the cutting edge of what can be done with modern asyncio-based Python. I saw a ~3x improvement in the throughput of a microservice I wrote when I first tried it out years ago. currently at $dayjob we just use it by default in every Python service, whether or not we expect that service to be performance-critical.

0: https://github.com/MagicStack/uvloop

If you manage to grok how uvloop works as well as Python's default asyncio loop scheduler, you'll understand this style. It is not by itself a parallelism enabler, but network I/O the coroutines triggered would run in parallel nevertheless, though CPU bound computations would not by default.