DEV Community: Razan Fawwaz

Cross-Repository Development with Antigravity

Razan Fawwaz — Thu, 02 Apr 2026 02:26:20 +0000

If you've been sleeping on Antigravity, now's the time to wake up. Google's latest IDE isn't just another code editor — it comes with a built-in AI Agent Manager, meaning you can write code, run unit tests, spin up files, and execute everything directly, all while an AI assistant handles the heavy lifting alongside you. You can even plug in MCP Servers to pass richer context to the Agent.

Honestly? With Antigravity, you can kick off a task and go fishing. I'm not even joking.

The Problem with Scaling

Out of the box, Antigravity tends to scaffold projects using fullstack frameworks like Next.js or Vite + React. For smaller projects, that's totally fine — convenient, even.

But once you start scaling, a single monorepo starts to feel like a liability. The codebase bloats, separation of concerns gets blurry, and things that should be independent start bleeding into each other. Personally, I much prefer keeping frontend and backend as separate repositories. Shoutout to Kak Ishfa for pushing me to think about this more seriously.

Here's the catch though — Antigravity doesn't have a native Linked Workspace feature. There's no built-in way to point a single Agent at two separate repositories and have it work across both seamlessly.

But there's a workaround, and it's cleaner than you'd expect.

The Workaround: Agent Rules

The trick is using Agent Rules — a feature that lets you define behavior the Agent always follows, regardless of what you're asking it to do.

The idea is simple: open your frontend repository in Antigravity, then write a rule that tells the Agent about your backend repository's directory path. From that point on, whenever a frontend change requires a corresponding backend update, the Agent knows exactly where to go and what to touch.

Here's how I set it up: I have two repos, frontend and backend. In the frontend project, I added a rule that says — in plain language — "if any feature change requires backend work, update the backend repository too." The key detail is setting the activation mode to always on, so the Agent checks the rules on every single interaction, not just when you explicitly tell it to.

Here's a rough idea of what the rule content looks like:

You are working on a frontend project located at /path/to/frontend.
There is a paired backend project located at /path/to/backend (Go, net/http, SQLite).
Whenever a frontend change requires an API or backend change, apply those changes
to the backend project as well. Always keep both repositories in sync.

Simple, readable, and it works.

Putting It to the Test

To try this out, I built a todo app — login, full CRUD, connected to a Go + net/http + SQLite backend. Both directories started completely empty.

Once I submitted the prompt, Antigravity picked up the rules immediately and asked for approval before touching anything. After confirming, it installed the necessary packages and kicked off development — starting with the backend.

With the backend done, it seamlessly transitioned to the frontend and set up Vite + React.

When the chat stopped and the "accept all" button appeared, both projects were fully scaffolded and in sync — exactly as intended.

Wrapping Up

Is this the most elegant solution? Not really — ideally Antigravity would ship a proper Linked Workspace feature. But as a workaround, Agent Rules gets the job done surprisingly well. It's flexible, easy to set up, and once it's in place you barely have to think about it.

If you're working with separate repositories in Antigravity, give this a shot. It might just change how you build.

#Antigravity

Managing Secret For Your Golang Apps With The GCP Secret Manager

Razan Fawwaz — Wed, 01 Apr 2026 05:02:19 +0000

While developing a serverless application and having a secret key in JSON format, I always looked at how we store that file securely. We can’t save the JSON file in our public repository, right? ☠️

Since I plan to deploy the application using Google Cloud Run, I’ve found that Google Cloud has a Secret Manager service!

Store API keys, passwords, certificates, and sensitive data

Secret Manager is a secure and convenient storage system for API keys, passwords, certificates, and other sensitive data

Google Cloud

With Secret Manager, we can store the credentials to the Secret Manager and integrate our application to “take” the credentials from the Secret Manager.

There are two ways to store the secret, we can use the console or CLI, for this time I will use the CLI.

For example, I have a simple Golang app that has a file called secret-key.json for authentication to database services. I want to deploy the application using Cloud Run and using the secret key that is provided so the service can communicated to the database.

I already downloaded the key and am ready to put it on Secret Manager. First of all, make sure your devices are already authenticated with your Google Cloud account.

You can log in to your account by using this command

gcloud auth login

After that, set to using your project

gcloud config set project <PROJECT_ID>

The next step is we should enable the API of the Secret Manager service. You can use this command to enable it.

gcloud services enable secretmanager.googleapis.com

If the message returns “Operation …….. finished successfully” now we’re ready to go 🚀

Now, we’re heading to the directory where we store the secret key, or you can use any directory and set it the path on the command, here is the command that we will use

gcloud secrets create <SECRET_NAME> --data-file=<SECRET_FILE_PATH>

The image below shows the results if we already created the secret in Secret Manager.

Or you can check it from the Google Cloud Console and go to the Secret Manager page.

Now this is the Go code looks alike, since we just need to read the data, the process on this code is just to retrieve the secret. You should fill out the GOOGLE_CLOUD_PROJECT_NUMBER you can hardcode it or use OS Env.

package main
import (
 "context"
 "log"
 secretsmanager "cloud.google.com/go/secretmanager/apiv1"
 "cloud.google.com/go/secretmanager/apiv1/secretmanagerpb"
)
func main() {
 projectNumber := os.Getenv("GOOGLE_CLOUD_PROJECT_NUMBER")
 secretName := os.Getenv("SECRET_NAME")
 ctx := context.Background()
 client, err := secretsmanager.NewClient(ctx)
 if err != nil {
  log.Fatalf("failed to setup client: %v", err)
 }
 defer client.Close()
 accessRequest := &secretmanagerpb.AccessSecretVersionRequest{
  Name: "projects/" + projectNumber + "/secrets/" + secretName + "/versions/latest",
 }
 result, err := client.AccessSecretVersion(ctx, accessRequest)
 if err != nil {
  log.Fatalf("failed to access secret version: %v", err)
 }
 secret := string(result.Payload.Data)
 log.Printf("secret: %s", secret)
}

While running it locally, don’t forget to authenticate the program with the Google Cloud Project by using this command. For more reference, you can check this out.

gcloud auth application-default login

Then, you can run the program using go run main.go and here we go, this is the secret that we stored it before!

If you want to deploy it to Cloud Run, you can try this code

package main
import (
 "context"
 "fmt"
 "log"
 "net/http"
 "os"
 secretsmanager "cloud.google.com/go/secretmanager/apiv1"
 "cloud.google.com/go/secretmanager/apiv1/secretmanagerpb"
)
func main() {
 projectNumber := os.Getenv("GOOGLE_CLOUD_PROJECT_NUMBER")
 secretName := os.Getenv("SECRET_NAME")
 ctx := context.Background()
 client, err := secretsmanager.NewClient(ctx)
 if err != nil {
  log.Fatalf("failed to setup client: %v", err)
 }
 defer client.Close()
 accessRequest := &secretmanagerpb.AccessSecretVersionRequest{
  Name: "projects/" + projectNumber + "/secrets/" + secretName + "/versions/latest",
 }
 result, err := client.AccessSecretVersion(ctx, accessRequest)
 if err != nil {
  log.Fatalf("failed to access secret version: %v", err)
 }
 secret := string(result.Payload.Data)
 http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
  fmt.Fprintf(w, "Your secret is: %s", secret)
 })
 log.Fatal(http.ListenAndServe(":8080", nil))
}

razanfawwaz / go-gcp-secret

Go Apps using Secret Manager

go-gcp-secret

View on GitHub

Don’t forget to put the Env Variables while setting up the Cloud Run deployment.

If the deployment succeeds, you can try to call the “/” endpoint, and it will return the secret key that we need.

Additionally, if the Cloud Run needs access to the Secret Manager, you can go to the Secret Manager and give access to your Cloud Run Service Account by clicking Add Principal.

That’s all! 🚀 Thanks for reading!