Database connectors and adapters

[marktani]

[marktani]

Please use Github reactions over restating a previous comment 🙂

[kimf]

I guess it would be easier for you guys to just write an API that all the different "database-adaptors" needs to adhere to. Like rails did with ActiveRecord. Then people can write adaptors for whatever database they have the need for.

[crubier]

@kimf That is an amazing Idea ! I'd be willing to write the arangodb adapter in that case

[kbrandwijk]

We should also look at what's already there, like Squeryl that already supports a whole set of databases, and also makes it easy to support more. Personally, I don't feel like starting all over again for every database out there...

[kbrandwijk]

@idkjs Wow, thank you for pointing me to that database. I wasn't aware of its existence, but it seems a lot faster than Neo4j! https://blog.dgraph.io/post/benchmark-neo4j/

[sorenbs]

@idkjs @crubier @kimf You have suggested databases that have very different characteristics than traditional relational databases. It would be very helpful if you could describe some different use cases so we can better understand how these query engines would fit in with the existing Graphcool capabilities. I have some ideas that I think are quite exciting, but i'd like to get some more diverse input from the community as well.

[crubier]

@sorenbs Arango db would fit really nicely thanks to its graph database feature: just use document collections for entities and edge collections for relations. Use AQL instead of SQL and you are done. No need for an Orm layer or anything. From my point of view this is the database that maps the best to graphql.

I used arango as a backend for my graphql server and it was really easy. The graphql layer was just a thin translation layer.

[kbrandwijk]

@crubier I agree that Arango is a great fit to GraphQL. But the consideration is also if it's a good fit to the way the current data layer is structured. I don't really see it as a drop-in replacement.

[crubier]

@kbrandwijk Aha hell no, for sure ! I totally agree with you.

It is definitely not a drop in replacement for a SQL database, that was not my message.

Clearly it seems to me that creating a new implementation of the data layer, dedicated to noSQL document databases such as mongo and arango would be waaaay easier than trying to make those fit into a SQL ORM layer (and back)...

[makstr]

I have been working on an apollo express server which closely mimics graph.cool behaviours, it uses ArangoDB as a backend.

Most importantly it is modular due to schema stitching, and that makes it easy to bend and expand to your own needs. So far there are some CRUD operations, filtering, sorting, JWT auth with email / password, social login with Facebook, a faker fixture script. Currently working on s3 uploads with presigned urls. It is not fully polished but is fully tested with graphql-tester. Need to add some examples.

Thinking maybe I should clean it up and release if there was more interest...?

[crubier]

@makstr I would definitely be interested ! That would basically totally fit my need.

I developed a arango graphql backend with apollo, but I got fed up with having to manually code each new entity, with all its resolvers and stuff. So I went into graphcool, but I loose the scalability and general niceness of my arango backend, for a SQL server that I do not have much direct control on.

If you developed a tool that does this work of automatically creating resolvers, collections and everything based on a schema, I would be really interested in it, even willing to help you out !

[4r7if3x]

That would be nice if we can connect GraphCool to our own DB server, in my case Postgres, however i have no idea about implementing logic layer on top of it.

[idkjs]

I was just making suggestions. I'm basically still confused about the DB in graphcool. In mongo, i can go into the data and mess with it if I want to. Graphcool, i have no idea how to do that or if its even possible. Importing data, for example, would be so much easier, even if I had to learn the sql to figure it out. dgraph was just an example where i was able to move a dataset into it and see how it works.

[marktani]

Hey @SamAriafar, your input in #1230 would be appreciated 🙂

[SeanStewart37]

I would love to use Graphcool if MSSQL was supported.

[sorenbs]

@SeanStewart37 could you describe your use case in more detail? Especially why MSSQL is a requirement. Feel free to ping me (@sorenbs) in the Graphcool slack if you'd rather talk in private :-)

[sorenbs]

Elasticsearch

[mark-james]

I think cassandra offers interesting features in terms of horizontal scale that would interest graph.cool. It's architecture is also quite complementary to graphql. (I haven't looked at the innards of the graph.cool framework yet, so not sure how easy an integration it actually is).

[crubier]

AWS AppSync ?

[lowsky]

Cassandra

For having a very powerful, scalable backend, can we have Apache Cassandra support?

This is interesting, when you need a real scalable database which is also fault tolerant.

There is this powerful Cassandra Query Language which support all the usual table oriented commands, for access by java there is e.g. this jdbc driver

[joshhopkins]

TimescaleDB – Home | Repo

[Shadow117]

MariaDB, please 🙇

[marktani]

Thanks everyone for the participation, that gives a great first impression for what is most asked and is super helpful 🙌

I'll split up this issue into the individual feature reqeusts, for example for MongoDB or PostgreSQL.

[lastmjs]

I'm curious about what happened to the idea of general database connectors and adapters?

[sorenbs]

@lastmjs The idea took off, so now we have split this issue into individual dbs all linked from the main readme https://github.com/graphcool/prisma#supported-databases

[rohanray]

@lastmjs https://github.com/biggora/caminte and https://github.com/1602/jugglingdb were based on similar principles. an abstraction layer for crud ops which was implemented by db specific operations behind the scene.... Sorry for polluting a closed thread, but i thought similar design can be thought of for this specific issue cross-cutting all DBs.