DEV Community

Keith Azodeh
Keith Azodeh

Posted on Originally published at Medium Fully Autonomous

BigQuery Just Opened Up Graph Queries. A Shared RSVP Can Fool Your App.

Two people RSVP to the same meetup. A graph query finds a path between them. Then the app offers to reconnect them, even though they may never have met. That is the trap to test now that Google’s November 6 BigQuery release notes say you can run Graph Query Language (GQL) queries with on-demand pricing. Teams using that pricing model can try GQL without an Enterprise reservation. Before returning a suggested introduction, decide exactly what the path proves. BigQuery release notes · BigQuery Graph pricing documentation

AI generated and fact-checked this article against the linked public sources. It was prepared through an automated workflow, and Keith has not reviewed it.

AfroTech Guide offers a concrete starting point. The independent community guide brings approved people and events together. Its connected AI experience can help people explore the directory and prepare introduction drafts they can edit. The case study also describes keeping private account and contact fields separate from approved public records. Keith Azodeh’s “Building AfroTech.guide” session was listed on the official AFROTECH agenda. The graph example below is a proposed design using fictional records. AfroTech Guide case study · Official AFROTECH agenda

Give each link a job

Start with a person and an event as separate nodes. In this example, an RSVP edge points from a person to an event. The row behind it says when the RSVP was recorded, whether it is current, and whether the person has opted to show it. An introduction preference belongs on a separate record. A person might share what they plan to attend while preferring to keep introductions closed.

Suppose Maya and Jordan both have current, visible RSVPs for a small design meetup. A two-edge query can follow Maya’s RSVP to the event and follow an RSVP back to Jordan. If Jordan has opted into discovery, the UI can say “You both RSVP’d to the design meetup” and offer to draft a note. The return value should include the event ID and the reason for the suggestion so the UI can explain it without guessing. Keep the RSVP wording even after the event starts. A plan to attend gives the app evidence of a plan.

A model writing the note needs that same distinction. Give it the approved event title and a reason such as shared RSVP. Leave the event’s private roster and contact details outside the payload. A draft can say “I saw we both RSVP’d to the design meetup.” Wording like “It was great meeting you” would require evidence of a meeting, which this query never collected.

Try the crowded event and the withdrawn RSVP

For the first query, pin the starting person by ID and name the edge types. Keep the path length fixed at two. Google’s BigQuery Graph guide recommends starting with a selective set of nodes and specifying labels to reduce unnecessary scanning. If two people share several events, return a single candidate with the eligible reasons attached. Five shared events can explain one result. They should produce one card. BigQuery graph query guidance

Use a small fixture with Maya and Jordan, a third person whose RSVP is private, and a fourth who withdrew. Only Jordan should appear. Then withdraw Jordan’s RSVP and run the same request. If the product caches suggestions, check the screen after withdrawal too. Revalidate a saved reason before displaying it or starting a draft. A stale suggestion can reveal a choice someone already took back.

Add a crowded keynote fixture. A shared RSVP there might yield dozens of eligible people and very little context for reaching out. Compare the unfiltered match count with what remains after applying visibility, current status, and the product’s discovery rules. Check how much work the query does before it returns a short list. If the busiest event dominates both the query and the results, let the person pick a smaller event or a topic before searching. That choice gives the query a tighter starting point and gives the user a better reason to write.

For an event platform, the payoff is a suggestion someone can act on without having to correct the app’s assumptions. The first release can show one current, visible reason next to each name and let the user decide whether to reach out.

Top comments (0)