This is very interesting. For years I've been primarily working on LOB software and always wished for such a movement.
My thought stream in no particular order:
I intentionally make these comments before reading the complete documentation, as I'll forget some higher-level thoughts.
1- Adding schema to the DBMS is a big step. Suddenly most queries become much simpler and generating them dynamically even more so.
2- The schema you have designed helps a lot on the server-side. If this schema can be extensible (that is, people can make extensions by allowing extra information in the schema that the DBMS ignores, similar to comments) and available to an authorized user, people can create great tools for the client-side as well.
3- A surprisingly huge portion of developer time is spent on building data administration tools, even in projects and companies that are focused on something else.
4- It is vital to allow the developer to take control and query the underlying Postgresql whenever needed. Most huge abstractions that are all or none are doomed to fail in non-trivial ways. I'm throwing away Prisma integration of my company's project because they did not provide enough extension points, hooks and all the other ways to use the full power of the database. So as soon as you need something they don't support, you have to bypass the whole abstraction layer.
> The schema you have designed helps a lot on the server-side. If this schema can be extensible (that is, people can make extensions by allowing extra information in the schema that the DBMS ignores, similar to comments) and available to an authorized user, people can create great tools for the client-side as well.
EdgeDB supports arbitrary JSON annotations on all schema objects, for example:
type User {
property name -> str {
annotation render_as := '"textbox"';
constraint expression on (len(.name) < 10) {
annotation comment := '"needed for external reasons"';
}
}
annotation data_for_app := "some-json-data"
}
> I'm throwing away Prisma integration of my company's project because they did not provide enough extension points, hooks and all the other ways to use the full power of the database. So as soon as you need something they don't support, you have to bypass the whole abstraction layer.
This is why we are investing so hard into EdgeQL. If you can't express something with EdgeQL that you can with SQL -- it's a bug. If whatever you do seems _harder_ (or slower) with EdgeQL than with SQL, it's also a bug. Same applies to generated database clients (we'll be releasing a JavaScript/TypeScript client generator / query builder alongside EdgeDB 1.0).
When working on the perl ORM DBIx::Class and its underlying SQL generator SQL::Abstract, we always took the principle "if you can't get it to generate the exact SQL you'd've written by hand, it's a bug" and lots of people I know who have since (for entirely understandable reasons) moved on to other languages as their daily driver continue to periodically complain about everybody else's ORMs to me (though when I've had beer with sqlalchemy devs at conferences they've been notable for having the same attitude, more power to 'em).
I have a horrible feeling I'll end up cracking and porting the whole stack to typescript at some point if nothing else because peer pressure/nerd sniping (and if I can make that work, probably also golang) but that's said in the spirit of "you are doing the right thing where so many people aren't".
I'm kinda waffling and not entirely sure how to best end this comment but I both hope you have great success and also that we get to have beer at a conference sometime to share war stories and trade-offs because you sound like you have the Right Ideas (because they're similar to mine and I'm always right, obviously, but still ;).
> If you can't express something with EdgeQL that you can with SQL -- it's a bug.
This is a huge promise. Especially with all the little "extra"s all different vendors have added. Love to read more.
One thing that separates EdgeDB from ORMs is the explicit design decision to be coupled with one specific database.
One more thing that can make me happy is to see if connection cost to EdgeDB is much lower than PostgreSql (one of the few architectural problems with PG).
Connecting only (or almost only) through EdgeDB fixes this one as a side effect.
> One thing that separates EdgeDB from ORMs is the explicit design decision to be coupled with one specific database.
Yes, this is fundamental, and it is what enables us to drive the innovation in the query language. PostgreSQL's query engine is awesome and very powerful, but it is hopelessly obscured by SQL and its data model, and then further by the ORMs. EdgeDB and EdgeQL liberate that power and present it in a modernized way. EdgeQL wouldn't be possible or practical today without Postgres.
Love what you're doing. I've built a fairly sizable cloud based POS with postgres on the backend. In doing so I've written thousands of lines of sql and stored procedures over the last 3 years. You've managed to tackle almost all the stuff I've been bitching about in sql.
any plans to implement a full stored procedure language?
how well does it integrate with calls to postgres functions?
> any plans to implement a full stored procedure language?
There are plans, and they have the word "Wasm" in them :-) You can also do a lot with pure-EdgeQL functions already.
> how well does it integrate with calls to postgres functions?
In theory all you need to do is write a function declaration with `USING SQL FUNCTION` [2], however we are currently limiting this functionality to the standard library, until we grow a well-defined user extension mechanism (a-la `CREATE EXTENSION` in Postgres).
This is the thing that piqued my interest when looking into EdgeDB a few weeks ago. Imagine developing your front end by first designing your data queries, and calling a function on the query definition that generates the frontend ui derived from the schema's type system and annotations that can display the result of that query. A man can dream... :)
We used to have a React UI framework for exactly this: ease the pain of generating server and client code for form and data-grid components. You could either describe a form layout in declarative YAML file (binding data types to form fields) or just use the framework to generate components for types fully automatically (based on types and annotations). Our data model, query language, and full introspection makes this possible and almost simple to implement in a generic way. We are thinking about building and open sourcing some of this functionality for EdgeDB, but we don't have an ETA for that yet.
> 2- The schema you have designed helps a lot on the server-side. If this schema can be extensible (that is, people can make extensions by allowing extra information in the schema that the DBMS ignores, similar to comments) and available to an authorized user, people can create great tools for the client-side as well.
This is so very much on point!
We've designed EdgeDB with schema re-use in mind. Our type system allows types to be composed with mixins. And the query language allows to write polymorphic queries against all types having a particular mixin [1] (like "give me all objects that implement NamedObject type).
The core idea here is that we can make re-usable libraries of schema types that's easy to integrate into your project. Finally making "schema re-use" and "code re-use" possible.
> 4- It is vital to allow the developer to take control and query the underlying Postgresql whenever needed. Most huge abstractions that are all or none are doomed to fail in non-trivial ways. I'm throwing away Prisma integration of my company's project because they did not provide enough extension points, hooks and all the other ways to use the full power of the database. So as soon as you need something they don't support, you have to bypass the whole abstraction layer.
And this is also on point. That's why we spent years designing EdgeQL - our query language and really a foundation of our project. It had to be sound in terms of its design and underlying math to allow proper composability. We hint at some design aspects of EdgeQL in this blog post [2]
My thought stream in no particular order: I intentionally make these comments before reading the complete documentation, as I'll forget some higher-level thoughts.
1- Adding schema to the DBMS is a big step. Suddenly most queries become much simpler and generating them dynamically even more so.
2- The schema you have designed helps a lot on the server-side. If this schema can be extensible (that is, people can make extensions by allowing extra information in the schema that the DBMS ignores, similar to comments) and available to an authorized user, people can create great tools for the client-side as well.
3- A surprisingly huge portion of developer time is spent on building data administration tools, even in projects and companies that are focused on something else.
4- It is vital to allow the developer to take control and query the underlying Postgresql whenever needed. Most huge abstractions that are all or none are doomed to fail in non-trivial ways. I'm throwing away Prisma integration of my company's project because they did not provide enough extension points, hooks and all the other ways to use the full power of the database. So as soon as you need something they don't support, you have to bypass the whole abstraction layer.