4 ms·
Show HN: WunderGraph – Back end for Front end Framework
- Nezteb 4y agoI wonder how this compares to SurrealDB: https://github.com/surrealdb/surrealdb https://github.com/surrealdb/surrealdb
- morbicer 4y agoCompletely different thing? SurrealDB is database and WunderGraph is BFF/API Gateway.
- Nezteb 4y agoWhoops my bad, I am wrong. When I see "BFF" I associate it with something like Nhost/Hasura/Supabase/Appwrite that's essentially a DB with REST/GraphQL APIs and extra goodies built on top; something that can replace Firebase for mobile/web clients. Granted, even SurrealDB isn't at that level (yet, the "future" feature list includes a lot of that functionality).
- morbicer 4y agoThere is some overlap, you can hook WunderGraph to db directly but I would say Supabase/Hasura has more fine grained capabilities there https://docs.wundergraph.com/docs/supported-data-sources/postgresql https://docs.wundergraph.com/docs/supported-data-sources/pos...
- jensneuse 4y agoWunderGraph uses Prisma internally to talk to the database, so I'd say this is quite mature. Here's a more comprehensive guide about our database support: https://docs.wundergraph.com/docs/databases/prisma https://docs.wundergraph.com/docs/databases/prisma
- morbicer 4y agoI am a big fan WunderGraph and I think it's a very promising project. Some solid design choices. What I like: - customization in TypeScript but running the core gateway in Go for performance - nicely typed auto-generated clients - cross-API joins to compose APIs - their approach of using GraphQL as schema language but not exposing it to clients https://wundergraph.com/blog/graphql_is_not_meant_to_be_exposed_over_the_internet https://wundergraph.com/blog/graphql_is_not_meant_to_be_expo... However, the project is still very fresh and not mature. Their current OpenAPI spec introspection is severely lacking on "real world" oas and many of the response structures won't parse properly and fallback to generic JSON. Related to this the docs are sparse so I was unable to find how one can customize/extend/override the auto-generated schemas. But they are actively working on it so I believe they will solve this. Sadly I need something right now and GraphQL Mesh offers very similar capabilities with much more mature OpenAPI parser which can even handle upcoming @oneOf tagged unions. https://the-guild.dev/graphql/envelop/docs/guides/using-graphql-features-from-the-future#oneof-input-objects-and-oneof-fields https://the-guild.dev/graphql/envelop/docs/guides/using-grap... GraphQL Mesh seems more operational ready with ready-to-use OpenTelemetry and Prometheus plugins. And it can be deployed easily to serverless. I really like WunderGraph approach and architecture so I hope I can pick it for a future project.
- jensneuse 4y agoBtw, we've adopted the OpenAPI parser from Mesh. The latest version allows you to use it already. Open Telemetry is almost done, will probably be released tomorrow. What else are you missing?
- morbicer 4y agoNice! You guys are crazy productive and responsive! What I like from Mesh is also some "tidying" utilities like renaming transforms https://the-guild.dev/graphql/mesh/docs/transforms/rename https://the-guild.dev/graphql/mesh/docs/transforms/rename I guess some error masking/customization can be done with your hooks but I haven't played with it yet. When .wundergraph/generated/wundergraph.schema.graphql is getting generated and there are some errors it can be harder to debug this (or I don't know how to do it properly) so I resorted to putting console.logs to places like node_modules/graphql/language/lexer.js Rate limiting per user can be nice, but not that important, I can live with broader limiting on ingress level.
- deleted 4y ago[deleted]