Search the relationships, then explain the match.
The graph model and query boundaries behind DevGraph's developer discovery experience.
Problem
Searching for a developer by a technology name misses the context around that skill: which project used it, which domain the project served, and who worked together. A single record contains only part of the answer.
Context
DevGraph is a graph-backed discovery application built with React, Fastify, and CognoDB. Its search accepts natural-looking text and resolves recognized graph entities into structured filters. This is a walkthrough of that design, not a comparison proving graph databases faster than relational databases.
Approach
Represent the connections that the product needs to explore. Developers have skills and work on projects; projects use technologies and connect to companies and domains. Traversing those relationships can answer a question about experience rather than merely matching a word.
Implementation
The HTTP route delegates to a search service. An entity resolver turns recognized terms into filter values. A repository owns fixed Cypher queries, and the Neo4j JavaScript driver sends those queries and separate parameters to CognoDB over Bolt.
For example, the conceptual path for domain experience is:
Developer → WORKED_ON → Project → IN_DOMAIN → Domain
That path explains why a developer matches. A shared-project connection can likewise be derived by traversing from one developer to a project and back to another developer, rather than maintaining a separate connection record.
User input supplies parameter values; it does not become executable Cypher text. The entity resolver still has a limited vocabulary. Natural-looking input should not be presented as unrestricted natural-language understanding.
Results
The repository includes seed data, a search test script, product screenshots, and a recorded walkthrough. These demonstrate the intended discovery flow and make the model inspectable.
The project does not establish search quality across an open-ended dataset, a commercial directory's coverage, or a latency advantage over an alternative database design.
Lessons learned
- Start with the relationships visitors need to explore, then choose a data model.
- Explain the path behind a result when the relationship is part of the product's value.
- Keep input interpretation separate from query construction.
- A next evaluation should include ambiguous terms, combined filters, empty matches, and growing graphs, with a declared dataset and workload.
Sources
Continue with the DevGraph case study.