Replies: 7 comments 5 replies
-
Hi @maaft. We're contemplating an idea of using wasm to let users define their own HTTP endpoints and functions that would be callable from EdgeQL/GraphQL. That would address Query Hooks. Still early into the research, so thank you for providing a use case. As for the insert/update/delete hooks we have an idea for a declarative data mutation API builder. That will cover input validation. Both wasm and the API builder are very early ideas though. |
Beta Was this translation helpful? Give feedback.
-
This will also be partially addressed by query rewrite policies, specifically the |
Beta Was this translation helpful? Give feedback.
-
I think we need to convert this into a Discussion to be able to have a proper threaded discussion, since it's a complex topic. |
Beta Was this translation helpful? Give feedback.
-
Another use case would be integrating with another API. I know this was mentioned very briefly, but a more thorough case point. If I am developing an application and I authenticate users with Github, then I can use their authentication to give them access to data inside of their Github. But I would need to store the user in my database still and relate to other database/api held data. So this could look something like:
I tried to use a form of esdl with adding a few extra things like |
Beta Was this translation helpful? Give feedback.
-
What if you wrapped your external APIs with a postgres FDW? Then you could Could EdgeDB work with existing schemas or FDWs? |
Beta Was this translation helpful? Give feedback.
-
Hi everybody! Has this been discussed internally already? Is there anything planned? This is a mission-critical feature for our company. |
Beta Was this translation helpful? Give feedback.
-
Hasura has a pretty good pattern for this concept, though it's not quite the same and has some serious limitations. I think the WASM avenue has the most potential because of the potential performance it unlocks: for validation of data on insert/mutation, making a call to another server introduces many more issues than "transpile my python/TS/C#" to WASM. A WASM executable is also going to play nice with version control and automatic migrations, where something in the external service may not (an argument for consistency, not for easy of deployment). |
Beta Was this translation helpful? Give feedback.
-
Preamble
Although probably mostly also applicable to EdgeQL, I talk mostly from a GraphQL point-of-view. My goal is to offer my frontend-devs the best experience they could possible get, by providing a complete, fully typed and single-endpoint endpoint API to all of our backend services.
Motivation
Modern web-apps are often dynamic in nature. You don't use only one database to get your data, but in fact multiple datasources (redis, azure, aws3, custom services, ...) are queried.
Also, mutations often have side-effects: When deleting the database entry that represents my image, I also want to delete the actual binary data from azure blob storage. Furthermore, I want to update certain statistics that are store somewhere else in my schema.
These requirements of modern web-apps can be solved by making use of both query- and mutation-hooks. These hooks could be implemented through web-hooks where the EdgeDB server sends (and receives) data to another webservice (either provided by EdgeDB itself or by a custom service, implemented by the user).
Q: Why webhooks?
A: They are easy to intergrate, and more importantly they make no assumptions on what programming language you want to use.
Query-Hooks
Sometimes you want to return fields to the user, which come from external sources.
Example:
When querying the database for an image, my web-app needs the binary data of the actual image. It would be bad-practice to force clients to figure out for themselves where and how to get that binary data.
Instead, the EdgeDB server could ask a service provided by the user (again; in a language of their choice) to resolve that field.
The service, would either resolve it return an error. In the latter case, the error is propagated to the client.
Mutation Hooks
These hooks will trigger on insert/update/delete. They should also be able to modify/extend the users intentions by returning data to EdgeDB
Following hooks will be needed to cover the mutation side of things:
1. Pre- Insert/Update/Delete Hooks
These hooks need to be called before data is added/updated/deleted. Use-cases are:
2. Post- Insert/Update/Delete Hooks
These hooks need to be called after data is inserted/updated/deleted successfully. Use-cases are:
Conclusion
Web-Hooks for Query/Mutations will bring the capabilities of EdgeDB on a complete new level by allowing to integrate with any existing backend service.
I hope I haven't forgot anything. Maybe @amaster507 has something to add.
For reference: @tailhook
Beta Was this translation helpful? Give feedback.
All reactions