Graphik

https://graphikdb.github.io/graphik/

Graphik is a Backend as a Service implemented as an identity-aware, permissioned, persistant document/graph database & pubsub server written in Go.

Support: support@graphikdb.io

Quick Start

Download sample .env & docker-compose file for configuration:

curl https://raw.githubusercontent.com/graphikDB/graphik/master/.sample.env >> .env
curl https://raw.githubusercontent.com/graphikDB/graphik/master/docker-compose.yml >> docker-compose.yml

Change GRAPHIK_ROOT_USERS in .env to your email address

Start the server:

  docker-compose -f docker-compose.yml pull
  docker-compose -f docker-compose.yml up -d

Visit localhost:7820/ui and login to get started. See Sample GraphQL Queries for sample graphQL queries.

when you're done, you may shutdown the server:

docker-compose -f docker-compose.yml down --remove-orphans

• Problem Statement
  • Traditional relational databases are powerful but come with a number of issues that interfere with agile development methodologies:
  • Traditional non-relational databases are non-relational
  • Traditional non-relational databases often don't have a declarative query language
  • Traditional non-relational databases often don't support custom constraints
  • No awareness of origin/end user accessing the records(only the API/dba making the request)
  • Solution
• Features
• Key Dependencies
• Flags
• gRPC Client SDKs
• Implemenation Details
  • Primitives
  • Identity Graph
  • Login/Authorization/Authorizers
    • Authorizers Examples
  • Secondary Indexes
    • Secondary Index Examples
  • Constraints
    • Constraint Examples
  • Triggers
    • Trigger Examples
  • GraphQL vs gRPC API
  • Streaming/PubSub
  • Additional Details
• Sample GraphQL Queries
  • Get Currently Logged In User(me)
  • Get the Graph Schema
  • Set a Request Authorizer
  • Create a Document
  • Traverse Documents
  • Traverse Documents Related to Logged In User
  • Change Streaming
  • Broadcasting a Message
  • Filtered Streaming
• Deployment
  • Docker-Compose
  • Kubernetes
  • Mac/OSX (Homebrew)
• Open ID Connect Providers
  • Google
  • Microsoft
  • Okta
  • Auth0
• Glossary
• FAQ

Problem Statement

Traditional relational databases are powerful but come with a number of issues that interfere with agile development methodologies:

• database schema setup requires application context & configuration overhead
• database schema changes are often dangerous and require skilled administration to pull off without downtime
• password rotation is burdensome and leads to password sharing/leaks
• user/application passwords are generally stored in an external store(identity provider) causing duplication of passwords(password-sprawl)
• traditional database indexing requires application context in addition to database administration

Because of these reasons, proper database adminstration requires a skilled database adminstration team(DBA).

This is bad for the following reasons:

• hiring dba's is costly
• dba's generally have little context of the API accessing the database(only the intricacies of the database itself)
• communication between developers & dba's is slow (meetings & JIRA tickets)

Traditional non-relational databases are non-relational

• many times developers will utilize a NOSQL database in order to avoid the downsides of traditional relational databases
• this leads to relational APIs being built on non-relational databases

Because of these reasons, APIs often end up developing anti-patterns

• references to related objects/records are embedded within the record itself instead of joined via foreign key
  • as an API scales, the number of relationships will often grow, causing embedded relationships and/or multi-request queries to grow
• references to related objects/records are stored as foreign keys & joined client-side via multiple requests(slow)

Traditional non-relational databases often don't have a declarative query language

• declarative query languages are much easier to build via graphical tooling for since a single query "console" is generally the only requirement.
• without a declarative query language, interaction with the database often involves complicated forms on a user-interface to gather user input.
• declarative query languages open up database querying to analysts, operators, managers and others with core competencies outside of software programming.

Traditional non-relational databases often don't support custom constraints

• constraints are important for ensuring data integrity
• for instance, you may want to apply a constraint to the "age" field of a user to ensure it's greater than 0 and less than 150
• this leads to developers enforcing constraints within the applications themselves, which leads to bugs

No awareness of origin/end user accessing the records(only the API/dba making the request)

• database "users" are generally expected to be database administrators and/or another API.
• 3rd party SSO integrations are generally non-native
• databases may be secured properly by the dba team while the APIs connecting to them can be insecure depending on the "origin" user

This is bad for the following reasons:

• dba teams falsely assuming their database resources are secured due to insecure APIs
• api teams falsely assuming their api resources are secured due to insecure database administration

Solution

• a loosely typed Graph database with built in identity awareness via a configured identity provider(Google, Microsoft, Okta, Auth0, etc)
  • relational-oriented benefits of a SQL database
  • non-relational-oriented productivity benefits of a NOSQL database
• zero password management- this is delegated to the configured identity provider
• schema-optional for productivity gains - constraints enforce custom constraints when necessary
• "identity graph" which creates automatically creates connections between users & the database objects the create/modify
  • index-free-adjacency allows insanely fast relational lookups from the POV of the origin user
• fine-grained authorization model to support requests directly from the origin user/public client(user on browser, ios app, android app, etc)
  • enforce role-based-access-control based on attributes found on the profile of the user manged by the identity provider
• graphQL API to support a declarative query language for public clients(user on browser, ios app, android app, etc), data analysts, and database administrators
• gRPC API for api -> database requests - gRPC tooling server side is more performant & has better tooling
  • auto-generate client SDK's in most languages (python, javascript, csharp, java, go, etc)
• database schema operations managed via integration with state of the art change management/automation tooling - terraform

Features

• [x] 100% Go
• [x] Native gRPC Support
• [x] GraphQL Support
• [x] User Interface
• [x] Native Document & Graph Database
• [x] Index-free Adjacency
• [x] Native OAuth/OIDC Support & Single Sign On
• [x] Embedded SSO protected GraphQl Playground
• [x] Persistant(bbolt LMDB)
• [x] Identity-Aware PubSub with Channels & Message Filtering(gRPC & graphQL)
• [x] Change Streams
• [x] Extended Common Expression Language Query Filtering
• [x] Extended Common Expression Language Request Authorization
• [x] Extended Common Expression Language Constraints
• [x] Extended Common Expression Language Server Side Triggers
• [x] Loosely-Typed(mongo-esque)
• [x] Horizontal Scalability/HA via Raft Consensus Protocol
• [x] Prometheus Metrics
• [x] [Pprof Metrics](https: