@mrjn Hi. Just thought of suggesting an integration with Prisma 2 at some point so that users can have the flexibility to move betwen databases at ease.
Also, a guide or reference on how to handle data localization laws (geo sharding with dgraph) would be great. Thanks.
It’s able to be done already by putting an Apollo server as a proxy in front of your Dgraph instance. That’ll take a small amount of boilerplate, but I currently feel that if you are building an Apollo federation, it’s likely that you have the capability for that, and it’s a more Apollo native solution than us baking it in. (we have a blog coming soon around this)
Did the blog post about using DGraph as a leaf of a Apollo Gateway’s federation get posted?
We also wondered if there was any discussion or examples about using DGraph as a caching gateway for GraphQL queries?
We use traffic shadowing with Apollo Federation (and Apollo Gateway) and compare the differences in responses between the legacy Python implementation and our new Go GraphQL backend service.
After our port is complete, we wouldn’t need side-by-side comparisons, so we could then evaluate also using DGraph as a gateway instead of Apollo. I would be very interested in any sort of performance comparison (Apollo Gateway vs DGraph-as-a-gateway) or demonstration of DGraph-as-a-gateway.
Hi! Are audit logs supported already? Support for auditing of various operations including tracking access and changes to dgraph configurations, etc. Right now, we see the log feature (including being able to log changes in data (query and mutations) only. Thanks!
It would be interesting to implement lambda trough providers. Maybe implementing an abstract provider layer that describe the lambda invocation/call process.