6

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:

CREATE TABLE accounts
(
  id int,
  last_name varchar,
  first_name varchar
);

CREATE TABLE files
(
  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.

Martin Schröder
  • 354
  • 1
  • 4
  • 19
TylerAndFriends
  • 203
  • 1
  • 5
  • How would you give access to those attributes on the link if not by exposing the link in your API? – Doc Brown Dec 24 '16 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. – TylerAndFriends Dec 25 '16 at 02:36

2 Answers2

7

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.

Ian
  • 4,594
  • 18
  • 28
0

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

Lloyd Moore
  • 164
  • 4