You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Stephen Mallette <sp...@gmail.com> on 2018/06/05 11:03:02 UTC

Apache TinkerPop's Position in the Graph Community

There have been a lot of changes and developments in the overall graph
community in recent times. In reflecting on those changes and the current
state of technical development here in Apache TinkerPop, I thought that I
would explain my opinion on where I think TinkerPop and Gremlin fit in the
graph community, both now and in the future, for users and vendors alike.

For as long as TinkerPop has been around (almost a decade), it has provided
a buffer to end users who wanted a single interface to any graph system.
That interface came in several forms over the years, but ultimately that
interface was and is the property graph query language, Gremlin. With
Gremlin, you can easily work with any TinkerPop-enabled graph system and if
you have any familiarity at all with our ecosystem, you know that list of
graph systems is filled with many high-profile names, covering both open
source and commercial options. The full listing of TinkerPop-enabled
systems that we are aware of is here[1] and includes names like, Neo4j,
JanusGraph, Amazon Neptune, DSE Graph, and Microsoft CosmosDB. Gremlin also
bridges OLTP and OLAP style processing, extending to Spark-based analytical
processing for dealing with the largest of graphs. When you look at that
full list, you can quickly see that as a user, the TinkerPop skill set can
transfer well into a wide variety of the major graph ecosystems available,
more so than any other property graph query language that I'm aware of.

So, that's what Gremlin as an interface to all these graphs gives to its
users - a lot of power without technology lock-in. That has been the
guiding path of this project since its earliest formation that I can recall
and it has paid off for the graph community in a big way, as a quietly
understood standard that is openly developed by the Apache Community.

Now, as we've moved into TinkerPop 3.x, two important developments occurred
that have helped expand TinkerPop's relevance to the graph community:

1. Gremlin Language Variants (GLVs) [2]
2. Gremlin Bytecode

GLVs made Gremlin natively available in languages that were not on the JVM.
To date, we officially support Gremlin in Javascript, .NET and Python. With
GLVs, developers in those ecosystems immediately gained access to the
extensive line-up of TinkerPop-enabled graph systems with first class
support for their programming language of choice. The development of GLVs,
led to the creation of Gremlin Bytecode (a language independent way of
representing a graph traversal). Gremlin Bytecode freed TinkerPop from its
script-compilation roots and opened up some interesting possibilities that
represent the future of TinkerPop's path.

TinkerPop has always been there to prevent lock-in, first for graph
databases and then,by 3.0, for graph systems (OLTP/OLAP). Now, with
Bytecode for currency, TinkerPop can effectively do the same thing for
query languages. We will see the beginnings of this with sparql-gremlin[3],
which acts as a translator to convert SPARQL to Gremlin Bytecode that can
then be consumed on any TinkerPop-enabled system (e.g. write SPARQL and
execute it in CosmosDB, write SPARQL and execute it in DSE Graph, write
SPARQL and execute it parallel over Spark over a multi-billion edge graph).
That model will serve to allow for other transpilers for Cypher, gsql, gql,
or whatever other language is made popular enough by the graph community to
warrant that capability.

Bytecode also presents the currency by which GLVs can evolve into full
Gremlin Virtual Machines (GVMs) [4]. With full GVMs available in major
languages, we can see Gremlin not only construct itself as a traversal on a
particular platform but also execute on that platform which means graph
systems not written for the JVM could easily consume Gremlin Bytecode.

For users, the key point is that, TinkerPop has never tried to tell you
what graph system to use. We let graph systems shine on their own merit and
let you choose the right one. I think that we now apply the same thinking
to graph query languages. Of course, we like Gremlin and encourage you to
use it as your first choice in query language, but if you prefer something
else, then TinkerPop is there to support that choice.

When we take the original and ongoing direction of TinkerPop to help
provide a standard way to talk to different graph systems and now expand
that guiding direction to, first, make Gremlin interfaces pervasively
available in different programming languages and, second, to make any
property graph query language ubiquitously connectable to any
TinkerPop-enabled system, it's hard to envision a more unifying query
language and framework for the graph community to rally around. TinkerPop
has always been a lock-in buffer for users, but with this evolution of
direction, it becomes a lock-in buffer for graph system vendors who can
then support ANY query language and ANY processing model deemed popular by
simply embracing TinkerPop. And, by doing so you always get Gremlin!

TinkerPop's relevance and benefit for users and graph system vendors has
never been higher. I look forward to participating in TinkerPop's continued
growth and adoption as it heads into these interesting times.

[1] -  http://tinkerpop.apache.org/#graph-systems
[2]  -
http://tinkerpop.apache.org/docs/current/tutorials/gremlin-language-variants/
[3] - https://issues.apache.org/jira/browse/TINKERPOP-1878
[4] -
https://www.datastax.com/dev/blog/the-benefits-of-the-gremlin-graph-traversal-machine