My Internship with the JupiterOne Team

I had the opportunity to complete a 2 month summer internship working with the JupiterOne team at LifeOmic. During that stint, I got to jump feet-first into a project using the JupiterOne CLI, query language and monitor. Here is a summary of what I did.

Matt Guo, Student at UNC-Chapel Hill

Visualizing Your Repositories and their Dependencies

As a developer, your day to day involves creating code repositories for your application. These new repositories have dependencies on other repositories: your own as well as other contributors. It’s a web of relationships that compounds over time as you continue to create more repositories and add more dependencies.

The net (see what I did there?) result is visibility into the moving pieces becomes difficult and the list of a single repositories numerous degrees of dependencies becomes extremely tedious to review. Not only that, the list of what dependencies exist fails to give insight into how the repositories are connected to each other. That means you are spending more and more time trying to understand what is already happening and less time building new code.

Repository Relationship Generator from JupiterOne

With the JupiterOne Repository Dependency Relationship Mapper, you can automatically create a graphical visualization of your dependencies lists, a shortcut to understanding the dependencies between your repositories.

The Relationship Generator analyzes repositories from sources like GitHub and BitBucket and uses JupiterOne’s Graph to map entity relationships between a repository and its dependencies. The relationships show up in the graph as a “USES” arrow going from an entity representing the repository to another entity representing the dependencies. The resulting graph will display all repositories that you wanted to look at.

Benefits

  1. You no longer need to look at each repository individually. The graph view allows you to quickly scan through all of your repositories and look at their dependencies. The graph view also allows you to look at individual dependencies and see what repositories use it.
  2. You can run queries in JupiterOne to find specific information that you would not be able to see otherwise. An example of a query that you can run is below:
'jupiter-client-nodejs' that uses CodeRepo return tree
jupiterone-client-nodejs-that-uses-coderepo-screenshot

For now, the tool is limited to scanning through the dependencies list of a package.json file, a node.js file and the dependencies.yaml file of repositories with a deploy directory. Despite these limitations, by using this tool, you will be able to find out more about how your repositories are connected than if you were looking through each repositories individually.

Internship Takeaways

Creating this tool was an awesome learning experience for me. By this point in my internship, I had already gotten to work with a few different JupiterOne repositories and tools, such as the monitor and the CLI. However, I had not gotten to work with the JupiterOne query language, which was used in the example above.

It was a cool project, albeit the syntax was a bit confusing at times. Nonetheless, the team graciously helped me along, as they had during the two months that I was there, and eventually I got comfortable enough with the syntax to run the queries that I needed.

Project and Learning Snags

Probably the most difficult aspect of this was scanning through the list of repositories that the user provided as input. What made this tougher to implement was the possibility of subdirectories within the list. Other parts of this tool (such as checking for client credentials and, of course, creating the relationships between the repository and its dependencies) presented different challenges for me.

In the end, I figured out that recursively searching through the directories was the best way to handle these situations, even though I tried out several different approaches before reaching this solution. The general approach that I took was the check inside each directory for a package.json file, and if there were not one, I would check for a package.json in each of the within that directory and make a recursive call. This process repeated until the program found all the repositories from the given list.

Final Thoughts

My experience working with the JupiterOne team was awesome, but I have to say that the time that I spent working on this tool was the most beneficial because it allowed me to build something in its entirety from scratch – something I have never really had the chance to do.

While I received some direction, I believe that the extra freedom that I had to dive into the project headfirst allowed me to have more fun with this project. In the end, I felt a greater sense of pride because the product was something that I had built from the ground up.