All Projects → JupiterOne → sdk

JupiterOne / sdk

Licence: MPL-2.0 license
Home of the JupiterOne SDK

Programming Languages

typescript
32286 projects
javascript
184084 projects - #8 most used programming language

Projects that are alternatives of or similar to sdk

OGMNeo
[No Maintenance] Neo4j nodeJS OGM(object-graph mapping) abstraction layer
Stars: ✭ 54 (+157.14%)
Mutual labels:  neo4j
nlm
Memory for Knowledge Graph, using Neo4j. 知识图谱存储与查询。
Stars: ✭ 43 (+104.76%)
Mutual labels:  neo4j
GCPEditorPro
Amazingly fast and simple ground control points interface. ◎
Stars: ✭ 33 (+57.14%)
Mutual labels:  gcp
plume
Plume is a code property graph analysis library with options to extract the CPG from Java bytecode and store the result in various graph databases.
Stars: ✭ 53 (+152.38%)
Mutual labels:  neo4j
gke-anthos-holistic-demo
This repository guides you through deploying a private GKE cluster and provides a base platform for hands-on exploration of several GKE related topics which leverage or integrate with that infrastructure. After completing the exercises in all topic areas, you will have a deeper understanding of several core components of GKE and GCP as configure…
Stars: ✭ 55 (+161.9%)
Mutual labels:  gcp
devrel
Common solutions and tools developed for Apigee
Stars: ✭ 121 (+476.19%)
Mutual labels:  gcp
bigtable-autoscaler-operator
Kubernetes operator to autoscale Google's Cloud Bigtable clusters
Stars: ✭ 22 (+4.76%)
Mutual labels:  gcp
cookbook
VueJS + NodeJS Evergreen Cookbook
Stars: ✭ 440 (+1995.24%)
Mutual labels:  gcp
jpa-unit
JUnit extension to test javax.persistence entities
Stars: ✭ 28 (+33.33%)
Mutual labels:  neo4j
gorm-neo4j
GORM for Neo4j
Stars: ✭ 16 (-23.81%)
Mutual labels:  neo4j
neo4j-migrations
Automated script runner aka "Migrations" for Neo4j. Inspired by Flyway.
Stars: ✭ 82 (+290.48%)
Mutual labels:  neo4j
paradise-papers-django
A simple Django web app for searching the Paradise Papers dataset backed by Neo4j
Stars: ✭ 63 (+200%)
Mutual labels:  neo4j
awesome-bigquery-views
Useful SQL queries for Blockchain ETL datasets in BigQuery.
Stars: ✭ 325 (+1447.62%)
Mutual labels:  gcp
elixir ravelry
Elixir API using Neo4j database for ElixirConf 2017 talk
Stars: ✭ 21 (+0%)
Mutual labels:  neo4j
hive-bigquery-storage-handler
Hive Storage Handler for interoperability between BigQuery and Apache Hive
Stars: ✭ 16 (-23.81%)
Mutual labels:  gcp
pubsub cli
super handy google cloud Pub/Sub CLI
Stars: ✭ 32 (+52.38%)
Mutual labels:  gcp
Public-Transport-SP-Graph-Database
Metropolitan Transport Network from São Paulo mapped in a NoSQL graph database.
Stars: ✭ 25 (+19.05%)
Mutual labels:  neo4j
gcp-serviceaccount-controller
This is a controller to automatically create gcp service accounts an save them into kubernetes secrets
Stars: ✭ 14 (-33.33%)
Mutual labels:  gcp
cytoscapeneo4j
Cytoscape plugin for neo4j
Stars: ✭ 18 (-14.29%)
Mutual labels:  neo4j
hush gcp secret manager
A Google Secret Manager Provider for Hush
Stars: ✭ 17 (-19.05%)
Mutual labels:  gcp

@jupiterone/sdk

A collection of packages supporting integrations with JupiterOne.

Development Resources

Introduction

Integrating with JupiterOne may take one of these paths:

  1. A structured integration leveraging this SDK to dramatically simplify the synchronization process, essential for any significant, ongoing integration effort
  2. A command line script (sh, bash, zsh, etc.) using the JupiterOne CLI tool to easily query/create/update/delete entities and relationships in bulk
  3. Any programming/scripting language making HTTP GraphQL requests to query/create/update/delete entities and relationships
  4. A JavaScript program using the JupiterOne Node.js client library to query/create/update/delete entities and relationships

The integration SDK structures an integration as a collection of simple, atomic steps, executed in a particular order. It submits generated entities and relationships, along with the raw data from the provider used to build the entities, to the JupiterOne synchronization system, which offloads complex graph update operations, provides integration progress information, and isolates failures to allow for as much ingestion as possible.

An integration built this way runs not only on your local machine; it can be deployed to JupiterOne's managed infrastructure. You can easily build the integration you need today and run it wherever you'd like. When you're ready, we can help you get that integration running within the JupiterOne infrastructure, lowering your operational costs and simplifying adoption of your integration within the security community!

Please reference the integration development documentation for details about how to develop integrations with this SDK.

Development

To get started with development:

  1. Install dependencies using yarn
  2. Run yarn build

This project utilizes TypeScript project references for incremental builds. To prepare all of the packages, run yarn build. If you are making a changes across multiple packages, it is recommended you run yarn build --watch to automatically compile changes as you work.

Linking packages

If you are making changes to the SDK and you want to test the changes in another project then it is recommended to automatically rebuild and link this project when changes are made.

Steps to automatically build and link:

  • Run yarn build or yarn build --watch in this project from a terminal and wait for initial build to complete.

  • Run yarn link in the package that you want to link.

  • In a separate terminal, run yarn link @jupiterone/<package to link> in the integration project. You can now use the integration SDK CLI in the other project and it will use the latest code on your filesystem.

Versioning this project

To version all packages in this project and tag the repo with a new version number, run the following (where major.minor.patch is the version you expect to move to). Don't forget to update the CHANGELOG.md file!

git checkout -b release-<major>.<minor>.<patch>
git push -u origin release-<major>.<minor>.<patch>
yarn lerna version {major, minor, patch}

Note the git checkout/git push is required because Lerna will expect that you've already created a remote branch before bumping, tagging, and pushing the local changes to remote.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].