5 ms·

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

by aljgz 5y ago

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.

1st1 5y ago
Thanks! > 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] [1] https://www.edgedb.com/docs/edgeql/select#ref-eql-select-polymorphic https://www.edgedb.com/docs/edgeql/select#ref-eql-select-pol... [2] https://www.edgedb.com/blog/we-can-do-better-than-sql https://www.edgedb.com/blog/we-can-do-better-than-sql
RedCrowbar 5y ago
(EdgeDB CTO here) > 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).
- infogulch 5y ago
  annotation render_as := '"textbox"'; 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... :)
  - colinmcd 5y ago
    We have big plans for something quite similar to this. Stay tuned.
  - 1st1 5y ago
    Oh, that's very real with EdgeDB! 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.

by aljgz 5y ago

1st1 5y ago

Thanks! > 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] [1] https://www.edgedb.com/docs/edgeql/select#ref-eql-select-polymorphic https://www.edgedb.com/docs/edgeql/select#ref-eql-select-pol... [2] https://www.edgedb.com/blog/we-can-do-better-than-sql https://www.edgedb.com/blog/we-can-do-better-than-sql

RedCrowbar 5y ago

(EdgeDB CTO here) > 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).

infogulch 5y ago
annotation render_as := '"textbox"'; 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... :)
- colinmcd 5y ago
  We have big plans for something quite similar to this. Stay tuned.
- 1st1 5y ago
  Oh, that's very real with EdgeDB! 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.