In GraphJin an automatic GraphQL to SQL compiler we use the gnomock library it startups a database instance (docker) then create the schema and tests data and finally our code connects to it and runs a series of tests. We run these across Mysql, Postgres and a few other DB's. Gnomock supports a wide range of them. Right now we don't take down the db for every test only between test runs but its fast enough that we could. This whole thing runs of a simple `go test -v .` command and we run it on every commit using a githook. https://github.com/dosco/graphjin/blob/master/tests/dbint_te...
This is more common that you would believe other issues i've seen are no `limit` on the query, fetching all the results and then sorting in your own app code, using wrong joins. Many of these happen while using ORMs as well. SQL is a context switch for more devs and very few understand it and even those that do might not be familiar with the capabilites of your startups db choice.
Shameless plug but this was my motivation behind building GraphJin a GraphQL to SQL compiler and it's my single goto force multipler for most projects. https://github.com/dosco/graphjin
It depends on how you use it. With GraphJin you use GraphQL to define your API and GraphJin auto compiles it into SQL and instantly gives you a REST and a GraphQL API endpoint to use it with.
GraphQL takes security pretty seriously the way we think of GraphQL as a DSL for bulding APIs. The queries you issue in DEV are saved to an allow list and only those queries are compiled in production. Any other queries (or changes to existing queries) from the client is ignore. So you can use it to expose your primary DB. It's really no different that you writing code to build an HTTP endpoint, except of-course here you only write GraphQL
GraphJin can be used within your own http handlers (REST) sort of like an ORM. Or you can use the @script directive to add a JS script to handle the before and after of the request.
Here's an example of a relatively complex query that you'd need when building something like a blog. GraphJin will compile this nested query into a single efficient SQL statement.
Author of GraphJin here, thanks for all the comments on here. It's a labour of love for me over several years. Today it's so useful to me and other that I'm probably going to work on it forever. GraphJin is used as the backend for my startup https://42papers.com a site to discover and read top trending research papers in CS, DL, ML, and other fields.
+1 to that additionally there is nothing like subscriptions, defer, async on the REST side of things. These are really great capabilities to have towards building snappy data rich apps.
I won't comment on GraphQL itself. But GraphJin builds an internal graph of your db relationships, etc and uses that to write a single efficient query. Even if you have a deeply nested query, insert or update it will only result in a single efficient SQL query. Additionally we also support GraphQL subscriptions out of the box and soon, defer and async as well allowing you to build live updating apps using the same GraphQL queries.
You can do this with GraphJin. We support adding custom resolvers currently we have an HTTP resolver built in which allows you to join your DB GraphQL query with a remote HTTP Rest endpoint. For example you want users from your db and their subscription data from Stripe. It works out of the box, GraphJin will write out the correct Rest call using data from the db call eg stripe_customer_id from the db will be inserted into the rest calls. Additionally its smart enough to handle rate limits and parallel fetches if required.
Happy you're sharing this on here, glad to have more options on the table. However I will say GraphJin is not complex to use nor does it have any boilerplate. It's feature rich and hence has knobs to help you tune it to your needs. However it's defaults are well thought out and so should work out of the box in most cases. For example to use GraphJin as a library in your own code this is all it takes.
Here's a quick example of using it as a library in your own code.
GraphJin DOES NOT hook GraphQL straight to a DB. It is a backend service which in DEV mode saves queries to an allow list and in production on queries from this list are allowed to be run. GraphQL does not mean clients are allowed to change the query willy nilly in production that would be a nightmare.
Also in production the query is compiled into a db prepared statement the first time and then on queries after validation go directly to the prepared statement.
This is no different than a hand written HTTP endpoint + ORM.
Addition if using the standalone service is not for you then you can use GraphJin as sort of an ORM within your own http handlers.
The question around why use it is complex. Some reasons even nested queries and mutations are compiled to a single SQL query. Knowledge of indexes is used to write a fast query. Support for things like joining again Postgres Array columns, JSON columns, fast cursor pagination, Graph queries using recursive CTEs, full-text search and a lot more out of the box and will work on Postgres, Mysql, Cockroach, Yugabyte and I'm working on more.
Also GraphJin is the only one built in Go and therefore can be used as a library within your own Go app allowing you to use it while also adding any business logic you might need.
GraphJin does auto db discovery and hence builds a relationship graph which it then uses to write out a single efficient sql query for any Graphql query or mutation even nested ones. As GraphJin improves and uses new capabilities of newer versions of the db you get that for free. In the backend your query is compiled only the first time into a prepared statement and from then on requests pretty much go directly to db.
No real issues have been closed cursor pagination has been working for years. This issue clear says "frederikhors closed this as completed on Mar 3, 2020" as in closed by the person who opened it.
Cursor pagination works fine just ask for a cursor with any query and you can then pass that back with the next query to paginate. We don't support Relay atall.