A Review of Artifactory and CodeArtifact Repository Types

This post is a part of a series by JFrog Developer Advocates, comparing JFrog Artifactory to AWS CodeArtifact.

I’m the first to admit that I fit well into the developer stereotype of someone that gets easily distracted by the new, shiny thing. It’s just part of my nature, and I accept it. Plus, I absolutely enjoy exploring new implementations, technologies, or strategies that promise to elicit that “Ah, much better!” feeling. From my perspective, the end result of that activity is always a success, because my effort can only go one of two ways: I either find something new that improves some aspect of my life and I choose to make changes, or I confirm that I've already made the best choice.

AWS just dropped CodeArtifact into their vast array of services within the AWS ecosystem. Curious, I couldn’t stop myself from checking it out and comparing it with the user experience I have had with JFrog Artifactory — both from my previous development experience and in my current position at JFrog. Here are three questions that I went in with and the answers I came out with.

Will It Support My Go Modules?

As far as package type support goes, CodeArtifact hits the big ones — Maven, PyPI & npm. My first venture was to find a way to support my Go modules, but I was unsuccessful. Other notable misses include NuGet, Bower, and Docker.

CodeArtifact Documentation

"Each repository contains three unique endpoints, one for each package format: npm, pypi, and maven."

Create Repository Screen in Artifactory

Support for more package types may very well be on the roadmap for the future, but Artifactory is way ahead of the game here, currently supporting 26 different package types including a Generic type for any other currently unsupported or even custom package types. AWS has a separate Docker registry solution, Amazon Elastic Container Registry (ECR), but Artifactory includes support for multiple Docker registries and the ability to manage my Docker images along with all of the other artifact repositories.

Not to belabor the point, but I’ve gotten used to how nice it feels to have all of my artifacts managed in the same place. I liken it to having all of my clothes in my closet, right where I would expect them to be. In fact, this is actually a critical point! If I don't have my image management in the same tool, how can I correlate packages with the images they are contained in?

How Do I Resolve Dependencies?

Organizing repositories is quite a bit different in CodeArtifact than in Artifactory. In Artifactory, there is a clear delineation between local repositories, (places where your internally built artifacts go), remote repositories, (caches of artifacts obtained from 3rd parties), and virtual repositories, (aggregated repositories consisting of local and remote repositories of your choosing). Virtual repositories are especially nice because you can add any repositories you like and specify a priority order for resolution.

CodeArtifact appears to have a similar capability. When creating a repository in CodeArtifact, there is an option to add any number of "upstream" repositories, the order of which determines the order of resolution. However, I was immediately disappointed that I was limited to a relatively small number of public repositories. Artifactory is ahead of the game again, by allowing users to define any external repository they need.

CodeArtifact Available Public Upstream Repos

Artifactory Basic Remote Repo Configuration

What Statistics Can I Get From My Artifacts and Packages?

According to the documentation, CodeArtifact provides information about the artifacts stored in the repositories using CodeArtifact CLI and API commands. There's of course the basic stuff: name, version, license info, contents info, and some dependency information. I admit, at this point, I did not feel like going through the pains of actually getting an artifact uploaded to a CodeArtifact to see what the UI would look like. I spent a little time looking for an example screenshot in their documentation and didn't find any.

Part of my lackluster desire to pursue much further in CodeArtifact at this time is that in contrast, the Artifactory package detail screens are, hands down, beautiful. You can search for a specific package and then view information (in addition to the basics that CodeArtifact provides) about the activity, the number of downloads, the number of versions available, and which repositories include the package. On top of that, if you have CI/CD integrated, you can drill down into specific package information further and determine which builds in the system used this package. Artifactory is undoubtedly a mature, tracing solution that is invaluable in troubleshooting any build or dependency issues.

Artifactory Package Detail Screen

Final Thoughts

This investigation is over for now, but I know there will be more to come. My exploratory efforts have fallen into that second outcome — confirmation that JFrog Artifactory is a better choice. I can't wait to see what's next!

This post is a part of a series by JFrog Developer Advocates, comparing JFrog Artifactory to AWS CodeArtifact.