Gravity announcement

[oscard0m]

Blog Post Link: https://deploy-preview-2643--objective-northcutt-37494c.netlify.app/blog/2025/03/19/gravity/

Tasks

• approved.png: add proper screenshot (do we want it with light theme? some Mainmatter or Gravity border color?)
• approval-page.mp4: To capture a better example where we can see new files, deleted files, modified file with increase, modified file with decrease.
• automatically-approved.png: add proper screenshot (do we want it with light theme? some Mainmatter or Gravity border color?)
• needs-approval.png: add proper screenshot (do we want it with light theme? some Mainmatter or Gravity border color?)
• add proper og image
• add proper cover image

[KevinBongart]

So my initial recommendation of focusing on the product and reserving technical details for later was wrong 😅 We'll write a case study that's product-focused, so there could be an additional section to cover more technical details: front-end, back-end, the main libraries we used (I believe you patched Octokit for it?)… doesn't have to be a huge section but more details would be appreciated. Maybe rename "How Does It Work?" to "What Does It Do?" and reuse "How Does It Work?" for some technical details?

[marcoow]

Currently, this sounds quite a bit like a sales pitch but I think we want it to be interesting to the average programmer so we need to:

• start with what problem we're fixing
• explain how this works (CLI tool, server, background job for analysis, build artifacts stored on S3, GitHub app etc.)

[KevinBongart]

This could use a specific example or two, for instance:

Suggested change

	Build artifact sizes might not be the first thing you think about during code reviews, but keeping them in check can make a big difference. A minor update can easily lead to an unexpected size increase, and if it goes unnoticed, it could cause issues down the line.
	At [Mainmatter](https://mainmatter.com), we've seen firsthand how even small changes can lead to surprising performance regressions. That's why we built [Gravity](https://gravity.ci), a tool that helps developers manage build artifact sizes directly within their CI/CD pipeline. Today, we're excited to share it with the world.
	Build artifact sizes might not be the first thing you think about during code reviews, but keeping them in check can make a big difference. A minor update such as an uncompressed image or a bloated dependency can easily lead to an unexpected size increase and cause performance issues down the line.
	At [Mainmatter](https://mainmatter.com), we've seen firsthand how even small changes can lead to surprising performance regressions. That's why we built [Gravity](https://gravity.ci), a tool that helps developers manage build artifact sizes directly within their CI/CD pipeline. Today, we're excited to share it with the world.

[KevinBongart]

Reposting Marco's comment, I think actually describing specific but common dev problems could be useful in the opener:

• it's easy to add a JS dependency for a tiny feature that adds megabytes to the JS bundle without noticing – most common example I know of is https://github.com/dropbox/zxcvbn
• adding a huge 16MB 8000x8000 pixel JPEG to a website
• add a dependency to a Rust crate that results in a huge increase of the released binary

For instance, "adding a huge 16MB 8000x8000 pixel JPEG to a website" is more interesting to read than what I suggested, "an uncompressed image"

[KevinBongart]

Here as well I'd use specific engineering examples, e.g. "Someone added an image but forgot to compress it? A new dependency but the library is bloated? Some CSS isn't properly minimized? Learn about it before merging a PR"

[KevinBongart]

• I'd mention that the script needs to build artifacts before uploading them (then up to you to mention specific examples, like bundling dependencies, minimizing/compressing assets, or compiling binaries)
• Is it worth mentioning that the S3 bucket is secure? Is it even secure? I guess for open-source repos it's not really needed, though we don't want to expose the build artifacts otherwise people could just serve them from there :D
• I'd rephrase "our server" into "the Gravity server". Generally, let's be careful about "we", "us", "our". Let's use Mainmatter or Gravity where appropriate

Suggested change

	When there are changes in a pull request, Gravity's CLI tool collects the build artifacts and uploads them to [S3](https://aws.amazon.com/s3/), and calls our server to schedule an analysis, adding you to a queue ([Redis](https://redis.io/)).
	When there are changes in a pull request, Gravity's CLI tool running in a GitHub Action builds your app then uploads the build artifacts to a secure [S3 bucket](https://aws.amazon.com/s3/). The CLI tool then calls the Gravity server to schedule an analysis, using a ([Redis](https://redis.io/)) queue.

[KevinBongart]

• Here as well, "your turn in the queue" vs. "the PR's turn", although I wouldn't mention it as it implies wait time.
• I think I commented this before but I don't see much value in adding a link about default branches. The PR is against a branch, the developers know that, and Gravity should probably compare the PR vs. its base branch (not always the default branch). Too many links can be distracting
• Since the content of the files is not inspected, why do we even upload them? Couldn't the CLI build that report about the build (files, paths and sizes) and upload that to S3? It's already reading everything since it's uploading them, so it would be faster, lighter and more secure

[KevinBongart]

Also this section, I'd mention some tech we use on the backend, some interesting constraints (Rust, in-memory instead of unzipping to the file system etc.)

[KevinBongart]

I think there's a slight nuance between the check status and whether the PR can be merged. Up to you to get into the details in this post, but in my opinion:

• green check: the developer can merge the PR with peace of mind, knowing that artifact sizes didn't grow
• red check: the developer can still choose to merge the PR (either manually overriding GH, or setting up GH so that the check isn't required), after checking Gravity or not at all. The developer can also set up GH to require a green check and get the peace of mind that someone has to manually confirm that file size increases are acceptable

[KevinBongart]

This sentence doesn't need capitalization, feels very ChatGPT