What do you all think about this new API from Facebook?
https://facebook.github.io/graphql/
Looks like ArangoDB is looking at it too.
https://github.com/arangodb/arangodb/issues/1468#issuecomment-141038342
Scott
I was about to ask for it too :)
I would be a real plus and could be use in a jar plugin.
In the meantime please take a look at https://github.com/arangodb/arangodb/issues/1468#issue-104571974 (first comment).
As a fervent orientdb user, I already have some idea how to integrate it .
@tychota We're interested on supporting GraphQL. If you'd like to contribute to it with a PR (please send it to "develop" branch in case) it will be evaluated or sure ;-)
@lvca : I'm interrested in discussing with you first about design of the integration. Then I can move on starting a PR. But after year of "no-java', it will be hard ! ;)
FWIW :+1:
Thumbs up on this too
@tychota could you please contact me in private? l.garulli -/at/- orientdb .-dot.- com
:+1:
:+1:
:+1:
:+1:
Huge :+1: right now this might just be the thing to massively increase OrientDB's adoption rate
I am also waiting for it and would switch right now if it starts supporting GraphQL :+1:
:+1: Any ETA?
:+1:
I can't believe this request is already a year old. How time flies. :smile:
Scott
So what's the status, is anyone working on it?
This won't be integrated as of today. The APIs available now are the only ones that will be available in 3.0, just improved. So, nothing new.
Scott
Hi guys just to understand, how do you suggest the should be done?
ODB would need to develop a standard querying language over/ with GraphQL and it could be offered beside the REST API. That was my thinking, when I made this issue.
GraphQL solves a number of problems REST APIs have. However, as I have learned, GraphQL is meant to be more an API layer between application servers and clients and not really between clients and database servers.
Unless ODB intends to become an application server too, I don't really think moving to GraphQL would offer a lot of advantages to make the change worthwhile.
Anyone else with a different opinion please do chime in.
Scott
This might be of interest and kind of what I would have been looking for from ODB.
https://www.youtube.com/watch?v=b3pwlCDy6vY
Scott
I think particularily in microservices environments, it would be a great feature. For a Microservice architecture, this marshelling needs to be done in the MS layer (I am doing this using AWS Lambda and Graphene), invoking one or more backend calls (on orientDB) that introduces latency and compelxity in this layer.
Orients APIs are powerful we know this and love this :) - so I would think GraphQL would be a natural fit extension over it that introduces a form of 'external' standardisation of access to the data. Not as expressive or powerful as the native API of course, but when exposing APIs externally (e.g mobile apps, partners etc), you would not want to expose orientDBs raw APIs anyway (big MS anti-pattern) - so regardelss some abstraction has to be done, native GQL would simplify this immensely for a microservices architecture.
Hope this comes onto the roadmap - other DBs are certainly starting to offer this and its becoming more and more a big point to consider.
Keep up the good work!
馃憤
Hey, I see that it's been while since this was raised. I'm curious about the thoughts of the team members on this one.
I created a small example which uses OrientDB in combination with GraphQL.
https://github.com/Jotschi/vertx-graphql-example
It also uses the microservice framework Vert.x - Maybe it is useful to some of you.
The example is not yet completely finished. I need to rewrite some parts but it should be enough to illustrate how to use OrientDB with GraphQL in a pure-java fashion.
Hi guys, it looks like we have GraphQL on top of OrientDB: https://blog.kensho.com/compiled-graphql-as-a-database-query-language-72e106844282
That's nice, but I've come to the conclusion that GraphQL access directly to any database is only useful for a rudimentary crud administration system of the database or for adhoc querying. It is nothing for a full application. In other words, there must be a layer of business logic between the GraphQL gateway and the database for any decent application to work.
Scott
@smolinari Is it possible to expand on that? What type of business logic usually needs to happen?
Hi @bionicles.
It would make little sense to connect to a GraphQL connection of the database from a server to server perspective (where one server is the client). The REST API is already available and covers this same use cases. My contemplation at first was a direct connection of a real client (web clients, mobile devices, etc.) and this would require a layer of business logic including things like authorization, etc.
Does that make any sense?
Scott
Maybe it is late but any updates on this?
Most helpful comment
I think particularily in microservices environments, it would be a great feature. For a Microservice architecture, this marshelling needs to be done in the MS layer (I am doing this using AWS Lambda and Graphene), invoking one or more backend calls (on orientDB) that introduces latency and compelxity in this layer.
Orients APIs are powerful we know this and love this :) - so I would think GraphQL would be a natural fit extension over it that introduces a form of 'external' standardisation of access to the data. Not as expressive or powerful as the native API of course, but when exposing APIs externally (e.g mobile apps, partners etc), you would not want to expose orientDBs raw APIs anyway (big MS anti-pattern) - so regardelss some abstraction has to be done, native GQL would simplify this immensely for a microservices architecture.
Hope this comes onto the roadmap - other DBs are certainly starting to offer this and its becoming more and more a big point to consider.
Keep up the good work!