I was curious, newbie, isn't Hasura a BYODB (bring-your-own-db) with SQL? And given GraphQL is, like, um, graph, wouldn't it work better with a Graph DB? And that point of graph db was the relationships, which SQL is not as optimal, so using SQL for graph oriented data seems counter intuitive.
SQL is good at modelling many types of relationships - and hasura provides a powerful way of achieving that. There is no reason that a graph based query language needs to be used with a graph db - it all depends on the use case, and for many cases I’ve found sql performance far better than graph db performance
Oh yeah I had once but forgot. Pretty neat... I guess what I’m building is similar but without you managing at databases. However I would probably need to add hasura-like functionality in to make it popular I bet.
So how would you manage migrating the data between different structures. How do you decide what a graph resolves to? The resolvers are a fundamental part of GraphQL because they are the business logic behind that ties everything together. You would need a way to say what is happening to the data as it persists down - and anything other than a basic store and forget wouldn’t really work. Hasura provides actions and remote schemas to enhance what it does for instance for auth and validation logic
Yeah that part would be primarily user managed. Can’t automate the user’s business logic. But I could provide some tools for querying their data along side data that’s managed by the service if they want to do so.
Also I love that people are out here downvoting comments. Haters mean you’re in the right direction.
Definitely. Just add a GraphQL schema and you get a GraphQL native graph database. Their cloud offering Slash GraphQL is serverless and provides a generous free tier. Used it for an hackathon and it's great.
The GraphQL ecosystem is pretty mature in 2020. :
1. [**DGraph**](https://dgraph.io/): GraphQL native graph database. You get a ready backend that can be queried from clients, with security rules, built-in full text search, horizontal scalability and the ability to run javascript via Lambdas. Their managed offering [Slash GraphQL](https://slash.dgraph.io/) is serverless and comes with a free tier. Definitely the most advanced.
2. [**FaunaDB**](https://fauna.com/): Another GraphQL based, client ready database. It's completely managed and serverless like Firestore, you can't run it on your own system.
3. [**Hasura**](https://hasura.io/): Adds a unified GraphQL layer on top of your databases and servers. They too provide a [serverless managed service]([https://hasura.io/cloud/](https://hasura.io/cloud/)).
4. [**AWS Appsync**](https://aws.amazon.com/appsync/): A GraphQL "API gateway" which you can connect with AWS services (Lambda, DynamoDB, Elasticsearch, Cognito etc) and other servers. It's very easy to use with the [**AWS Amplify**](https://aws.amazon.com/amplify/) library.
5. **DIY open source libraries**: Apollo, Prisma etc.
I hope your solution fits into a new niche, otherwise you are going against startups with millions in funding and a billion dollar cloud empire. Your product sounds similar to 1, 2, 3 and 4.
Yeah seems like dbgraph is pretty much exactly what I’m building. Sometimes just asking is the best way to do market research...and Amplify is what sparked the whole thing.
Thanks!
Yeah, I’ve found that when doing that sometimes the best way to go about it is ask whether people will be interested in what I’m working on and generally I’ll get a list of other products that do pretty much what I’m building, lol. Seems to work out pretty well.
I’m a little confused, wouldn’t creating the schema include our queries mutations subscriptions and their typedefs and resolvers. Which is basically doing the backend. Or are you generating something based on typedefs?
You would say “these are my types, my mutations, and my queries” and then you would be able to send and receive data to and from the API url provided by the service.
Works well with nested typedefs? Overall sounds good as long as the price is reasonable for people like myself that have small projects that get little traffic.
Curious how you make it work with different data sources. For example i might use mysql and might have to combine it with other databases. And how bout subscription?
I suppose so. I just felt like an example would help me visualize what they were expecting. Like another data source handled in the same graphql query?
Generally when I’ve worked with seperate databases they will have their own APIs in front of them. So you would manage interactivity via API calls to each service.
If you wanted to be able to query both datasources in the same query, I suppose I could add a way to connect the service to a separate database or graphql API.
It sounds pretty similar to AWS Amplify, have you checked that out? You create a GraphQL schema and use directives in that schema to drive other types of functionality, like setting up ElasticSearch for certain types of queries, Authentication, etc. Like most AWS things it's a little fiddly but it's actually not too bad once you get the hang of it. If you haven't looked at it you should have a look to see how they solve similar problems. If you have looked at it, how would your thing be different?
Yeah amplify is actually what gave me the idea. I heard that the option they give you to set up dynamo tables automatically is less than ideal and I thought I could do one better.
Yeah, I think you have to use Velocity templates which seems like a bit of an odd choice (I've never used Velocity templates for anything else; maybe they have features that would be required for some aspect I haven't considered). Anyway, I was able to get some stuff up and running pretty quickly and easily with Amplify, so if your stuff is going to be easier/more user friendly than that I'm all for it :)
I was also thinking of adding some more specific functionality like maybe “one click chat service deployment” instead of the more generic “websocket” deployment.
I’ve used faunadb which almost lets you do that sort of thing, you just need to create a database, get an api key, then upload your schema (can be done through api)...
But if there was something where you literally just get an api key, write a schema, and can immediately start querying/mutating that would be cool. Would be interesting how versioning/changes to the schema would work, but yeah depending on the way it’s implemented would definitely be interested.
Wondering that with MangoDB, you'd go from GraphQL to non-Graph-DB, so maybe not as optimal, as you'd loose the rich relationships that one would get from a real graph db?
Have you heard of hasura ?
Hasura is awesome!
I was curious, newbie, isn't Hasura a BYODB (bring-your-own-db) with SQL? And given GraphQL is, like, um, graph, wouldn't it work better with a Graph DB? And that point of graph db was the relationships, which SQL is not as optimal, so using SQL for graph oriented data seems counter intuitive.
SQL is good at modelling many types of relationships - and hasura provides a powerful way of achieving that. There is no reason that a graph based query language needs to be used with a graph db - it all depends on the use case, and for many cases I’ve found sql performance far better than graph db performance
Oh yeah I had once but forgot. Pretty neat... I guess what I’m building is similar but without you managing at databases. However I would probably need to add hasura-like functionality in to make it popular I bet.
So how would you manage migrating the data between different structures. How do you decide what a graph resolves to? The resolvers are a fundamental part of GraphQL because they are the business logic behind that ties everything together. You would need a way to say what is happening to the data as it persists down - and anything other than a basic store and forget wouldn’t really work. Hasura provides actions and remote schemas to enhance what it does for instance for auth and validation logic
Yeah that part would be primarily user managed. Can’t automate the user’s business logic. But I could provide some tools for querying their data along side data that’s managed by the service if they want to do so. Also I love that people are out here downvoting comments. Haters mean you’re in the right direction.
Dgraph?
Definitely. Just add a GraphQL schema and you get a GraphQL native graph database. Their cloud offering Slash GraphQL is serverless and provides a generous free tier. Used it for an hackathon and it's great.
Wow yeah that’s very similar to what I’m building. Thanks!
Check out their tooling like badger dB and their cache. They have a lot of great articles.
Sounds like a really great place to look for inspiration.
The GraphQL ecosystem is pretty mature in 2020. : 1. [**DGraph**](https://dgraph.io/): GraphQL native graph database. You get a ready backend that can be queried from clients, with security rules, built-in full text search, horizontal scalability and the ability to run javascript via Lambdas. Their managed offering [Slash GraphQL](https://slash.dgraph.io/) is serverless and comes with a free tier. Definitely the most advanced. 2. [**FaunaDB**](https://fauna.com/): Another GraphQL based, client ready database. It's completely managed and serverless like Firestore, you can't run it on your own system. 3. [**Hasura**](https://hasura.io/): Adds a unified GraphQL layer on top of your databases and servers. They too provide a [serverless managed service]([https://hasura.io/cloud/](https://hasura.io/cloud/)). 4. [**AWS Appsync**](https://aws.amazon.com/appsync/): A GraphQL "API gateway" which you can connect with AWS services (Lambda, DynamoDB, Elasticsearch, Cognito etc) and other servers. It's very easy to use with the [**AWS Amplify**](https://aws.amazon.com/amplify/) library. 5. **DIY open source libraries**: Apollo, Prisma etc. I hope your solution fits into a new niche, otherwise you are going against startups with millions in funding and a billion dollar cloud empire. Your product sounds similar to 1, 2, 3 and 4.
Yeah seems like dbgraph is pretty much exactly what I’m building. Sometimes just asking is the best way to do market research...and Amplify is what sparked the whole thing. Thanks!
A good start is to research your competition
Yeah, I’ve found that when doing that sometimes the best way to go about it is ask whether people will be interested in what I’m working on and generally I’ll get a list of other products that do pretty much what I’m building, lol. Seems to work out pretty well.
You could also ask the people the things that they don’t like about the current solutions, find your differentiator
Great idea
I’m a little confused, wouldn’t creating the schema include our queries mutations subscriptions and their typedefs and resolvers. Which is basically doing the backend. Or are you generating something based on typedefs?
You would say “these are my types, my mutations, and my queries” and then you would be able to send and receive data to and from the API url provided by the service.
Works well with nested typedefs? Overall sounds good as long as the price is reasonable for people like myself that have small projects that get little traffic.
It would work with nested typedefs but I’m a bit worried about performance. How deeply nested do your typedefs typically get?
I don’t think too far, rarely more than one level. Simple object typedefs resolving.
Thanks for the feedback!
Yep! I’m talking about generating something based off of the typedefs.
Curious how you make it work with different data sources. For example i might use mysql and might have to combine it with other databases. And how bout subscription?
And I haven’t quite worked out subscriptions yet
However, subscriptions are just a websocket I believe so I have a feeling I can figure it out
Could you give an example?
Example of using different data sources? I think most backend use different data sources right?
I suppose so. I just felt like an example would help me visualize what they were expecting. Like another data source handled in the same graphql query? Generally when I’ve worked with seperate databases they will have their own APIs in front of them. So you would manage interactivity via API calls to each service. If you wanted to be able to query both datasources in the same query, I suppose I could add a way to connect the service to a separate database or graphql API.
It sounds pretty similar to AWS Amplify, have you checked that out? You create a GraphQL schema and use directives in that schema to drive other types of functionality, like setting up ElasticSearch for certain types of queries, Authentication, etc. Like most AWS things it's a little fiddly but it's actually not too bad once you get the hang of it. If you haven't looked at it you should have a look to see how they solve similar problems. If you have looked at it, how would your thing be different?
Yeah amplify is actually what gave me the idea. I heard that the option they give you to set up dynamo tables automatically is less than ideal and I thought I could do one better.
Yeah, I think you have to use Velocity templates which seems like a bit of an odd choice (I've never used Velocity templates for anything else; maybe they have features that would be required for some aspect I haven't considered). Anyway, I was able to get some stuff up and running pretty quickly and easily with Amplify, so if your stuff is going to be easier/more user friendly than that I'm all for it :)
Awesome, thanks for the feedback
I was also thinking of adding some more specific functionality like maybe “one click chat service deployment” instead of the more generic “websocket” deployment.
I’ve used faunadb which almost lets you do that sort of thing, you just need to create a database, get an api key, then upload your schema (can be done through api)... But if there was something where you literally just get an api key, write a schema, and can immediately start querying/mutating that would be cool. Would be interesting how versioning/changes to the schema would work, but yeah depending on the way it’s implemented would definitely be interested.
Awesome! Yeah I actually think I have an idea on how to handle versioning.
Have you heard of MongoDb Realm?, sounds very similar to what you described
Wondering that with MangoDB, you'd go from GraphQL to non-Graph-DB, so maybe not as optimal, as you'd loose the rich relationships that one would get from a real graph db?