@trilom this is an excellent example project, I was searching allot for some example showing nested resource paths and this is the only example I found. I wonder if this is not as common scenario as I thought it would be...
I'm trying to better understand the notation around this section (in the user service):
Outputs: ApiRootUser: Value: Ref: ApiGatewayResourceUser Export: Name: ${self:custom.${self:provider.stage}.Stack}-ApiRootUser-${self:provider.stage}
So - you are exporting a ApiRootUser key with a value of Ref:ApiGatewayResourceUser but what is exactly this Ref? I search the entire code base and there is no definition of ApiGatewayResourceUser pointing to some gateway resource... - is this some kind of convention? how does serverless "knows" to bind it to the /user path?
Also - I don't see anywhere in the code that some other service is consuming this specific value. What am I missing?
Same goes for ApiGatewayResourceUserUseridVar - I just can't understand how this Refs are bound to a specific aws api gateway path and how does the framework "knows" to interprets them.
Also - inside user/order folder the serverless defintion "consumes" the ApiGatewayResourceUserUseridVar attribute like so:
restApiResources: /user/{userid}: 'Fn::ImportValue': ${self:custom.${self:provider.stage}.Stack}-ApiRootUserUseridVar-${self:provider.stage}
so - can you please elaborate on the key that you use here: /usr/{userid} - how it actually works? especially - in my case, I have a more complex nesting. for example, let's assume that each order can have one or more product_group and each product_group might have one or more product_family and product_variant and so on... so the path could look something like this (4 levels depth, I actually have 8 levels depth! ):
what happens in this case? should I have multiple imports (one per each parent path)?
this definitions can become really complex. Do you have some advice on how to manage a more complex nested object graph like I described? maybe the nesting should stop right after orders? so .. for example per order id - it will start from the top : /orders/{order_id}/products_families (which list all product families belonging to a certain order) and then (again from the root) -
/product_family/{family_id}/variants
and
/variants/{variant_id} ?
the drawback I see with this design is that I loose some information when calling the API - so a certain user might have a certain order with a specific list of product families etc, but this is not captured all together in one API call... so I don't really like this design.
any advice on how to set it up with low complexity and without compromising modularity while preserving the RESTful convention/best practices. Again thank you for this example!!
chargingate
commented
4 years ago
@trilom this is an excellent example project, I was searching allot for some example showing nested resource paths and this is the only example I found. I wonder if this is not as common scenario as I thought it would be...
I'm trying to better understand the notation around this section (in the user service):
Outputs: ApiRootUser: Value: Ref: ApiGatewayResourceUser Export: Name: ${self:custom.${self:provider.stage}.Stack}-ApiRootUser-${self:provider.stage}So - you are exporting a ApiRootUser key with a value of Ref:ApiGatewayResourceUser but what is exactly this Ref? I search the entire code base and there is no definition of ApiGatewayResourceUser pointing to some gateway resource... - is this some kind of convention? how does serverless "knows" to bind it to the /user path?
Also - I don't see anywhere in the code that some other service is consuming this specific value. What am I missing?
Same goes for ApiGatewayResourceUserUseridVar - I just can't understand how this Refs are bound to a specific aws api gateway path and how does the framework "knows" to interprets them.
Also - inside user/order folder the serverless defintion "consumes" the ApiGatewayResourceUserUseridVar attribute like so:
restApiResources: /user/{userid}: 'Fn::ImportValue': ${self:custom.${self:provider.stage}.Stack}-ApiRootUserUseridVar-${self:provider.stage}so - can you please elaborate on the key that you use here: /usr/{userid} - how it actually works? especially - in my case, I have a more complex nesting. for example, let's assume that each order can have one or more product_group and each product_group might have one or more product_family and product_variant and so on... so the path could look something like this (4 levels depth, I actually have 8 levels depth! ):
/usr/{userid}/orders/{order_id}/product_family/{family_id}/variants/{variant_id}
what happens in this case? should I have multiple imports (one per each parent path)?
this definitions can become really complex. Do you have some advice on how to manage a more complex nested object graph like I described? maybe the nesting should stop right after orders? so .. for example per order id - it will start from the top : /orders/{order_id}/products_families (which list all product families belonging to a certain order) and then (again from the root) -
/product_family/{family_id}/variants
and
/variants/{variant_id} ?
the drawback I see with this design is that I loose some information when calling the API - so a certain user might have a certain order with a specific list of product families etc, but this is not captured all together in one API call... so I don't really like this design.
any advice on how to set it up with low complexity and without compromising modularity while preserving the RESTful convention/best practices. Again thank you for this example!!