3 ms·

Absolutely. Example: consider `country` and `city` are two tables and are related. City has a foreign key pointing to Country. In REST API framework : We auto

Absolutely. Example: consider `country` and `city` are two tables and are related. City has a foreign key pointing to Country. In REST API framework : We automatically generate /api/v1/country/:id/city for REST APIs. In GraphQL API framework : {Country {CityList} } graphql schema will be automatically generated with resolvers as well. So they work out of the box

bxparks 6y ago
Very impressive work, but I am not familiar with auto-API generators, so I have some basic questions: What if the foreign key reference was not an parent-child relationship, instead was a one-to-many relationship between 2 first class entities? For example, Company (1) related to Contacts (many), but they should be accessed as /v1/companies/:id and /v1/contacts/:id. What if there was a unique constraint on the foreign key reference, so that the relationship becomes a one-to-one relationship? What does the auto-generated REST endpoint look like? How does it handle join-tables which implement many-to-many relationships? Does it generate the REST end point for the join-table instead? How does it handle different subcollection semantics? In other words, sometimes we want to treat the entire subcollection as an atomic entity. Other times, we want to create, delete and update individual elements of the subcollection. How does it support SQL query optimizations?
- xgenecloud 6y ago
  Thank you for your input. Good & insightful questions. >> instead was a one-to-many relationship between 2 first class entities? This can be treated as virtual relationship between 2 entities and can be linked together in our models. This has to be done manually for now. May be we can do better with our UI tool. I've raised an issue to track this - https://github.com/xgenecloud/xgenecloud/issues/6 https://github.com/xgenecloud/xgenecloud/issues/6 one-to-one relationship returns a list instead of an object as of now. >> How does it handle join-tables which implement many-to-many relationships? Does it generate the REST end point for the join-table instead? In GraphQL : the schema is like a graph traversal so a join query is possible. In REST : no - this will have to be created manually. >> How does it handle different subcollection semantics? Subcollections can be handled individually i.e in their own routes or in nested routes in REST framework. CUD operations for subcollections in GraphQL i.e nested CUD operations (mutations) are not possible. >> SQL Query optimisation: N+1 query optimisations are done with data loaders. Please let us know of any other questions.
  - bxparks 6y ago
    Thanks for taking the time to respond. This is great information that points me in the right direction regarding the capabilities of the framework. I will probably need to actually use it to have more intelligent questions. I normally write my API endpoints by hand, and I am used to having complete control over the data shape and performance characteristics of the API, but I will keep this in mind in the future.

bxparks 6y ago

Very impressive work, but I am not familiar with auto-API generators, so I have some basic questions: What if the foreign key reference was not an parent-child relationship, instead was a one-to-many relationship between 2 first class entities? For example, Company (1) related to Contacts (many), but they should be accessed as /v1/companies/:id and /v1/contacts/:id. What if there was a unique constraint on the foreign key reference, so that the relationship becomes a one-to-one relationship? What does the auto-generated REST endpoint look like? How does it handle join-tables which implement many-to-many relationships? Does it generate the REST end point for the join-table instead? How does it handle different subcollection semantics? In other words, sometimes we want to treat the entire subcollection as an atomic entity. Other times, we want to create, delete and update individual elements of the subcollection. How does it support SQL query optimizations?

xgenecloud 6y ago
Thank you for your input. Good & insightful questions. >> instead was a one-to-many relationship between 2 first class entities? This can be treated as virtual relationship between 2 entities and can be linked together in our models. This has to be done manually for now. May be we can do better with our UI tool. I've raised an issue to track this - https://github.com/xgenecloud/xgenecloud/issues/6 https://github.com/xgenecloud/xgenecloud/issues/6 one-to-one relationship returns a list instead of an object as of now. >> How does it handle join-tables which implement many-to-many relationships? Does it generate the REST end point for the join-table instead? In GraphQL : the schema is like a graph traversal so a join query is possible. In REST : no - this will have to be created manually. >> How does it handle different subcollection semantics? Subcollections can be handled individually i.e in their own routes or in nested routes in REST framework. CUD operations for subcollections in GraphQL i.e nested CUD operations (mutations) are not possible. >> SQL Query optimisation: N+1 query optimisations are done with data loaders. Please let us know of any other questions.
- bxparks 6y ago
  Thanks for taking the time to respond. This is great information that points me in the right direction regarding the capabilities of the framework. I will probably need to actually use it to have more intelligent questions. I normally write my API endpoints by hand, and I am used to having complete control over the data shape and performance characteristics of the API, but I will keep this in mind in the future.