I am experimenting with converting an API to GraphQL, and I have a database that has many-to-many relationships that are stored via link tables; something like this:

  id int,
  last_name varchar,
  first_name varchar

  id int,
  content varchar,
  name varchar

CREATE TABLE account_file_links
  id int,
  account_id varchar,
  file_id varchar,
  can_edit tinyint,
  FOREIGN KEY (account_id) REFERENCES accounts(id)
  FOREIGN KEY (file_id) REFERENCES files(id)

I am wondering if I should be exposing these links as they're own types in the GraphQL schema or not. When I think of my database as a graph, the nodes are the accounts and the reports, while the edges would be the account_file_links. There are attributes present on the link (in this example, the can_edit property) that need to be presented to the API consumers.

  • How would you give access to those attributes on the link if not by exposing the link in your API?
    – Doc Brown
    Dec 24, 2016 at 16:52
  • I was thinking that I could have two different types of files attached to each accounts: editable_file and regular_file or something like that. Dec 25, 2016 at 2:36

2 Answers 2


An API should be designed for the user of the API, not based on how the system "happens" to store the data at the time the API is designed. Therefore start with a set of examples of how your API will be used.

Just the table name "account_file_links" makes it clear that using the database as the bases of the API design is not a good opiton.


The links themselves are entities within their own right and there is no reason why you should not expose them as link objects.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.