@zrob We don't have any concrete plans as of yet - we are tracking V3 in this issue - #1543.

I'd be interested in the deprecation plans, so we can plan when we need to have V3 support.

@zrob When handling apps, and other entities, we make heavy use of relationships. For instance when we list apps we fetch each app's space, the space's organisation and the app's routes all in one call. When we then drill down into an app we validate the app has routes, space, stack, service binding and the route has domain and space has organisation. If any are missing we then use the _url from the app entity to fetch them. When looking at the v3 apps doc (http://v3-apidocs.cloudfoundry.org/version/3.56.0/index.html#the-app-object) it looks like some of the app relations are available as links. Is there a way to fetch them inline? Also are there any plans to expand the app relations to cover all v2 app relations?
It would be quite tricky having to support both v3 and v2 api's together, so would also be interested in the timeline for expanding v3 to cover all v2 resources

Hey @richard-cox

TLDR; we are looking at ways to have similar functionality to inline-relations-depth, but it will be somewhat more restrictive

We ended up with lots of operating experience in environments that had clients using inline-relations-depth. That feature ended up causing a very large issue with API performance in most cases, especially when using a depth of 2. It turns out most of the relationships in CC are fairly shallow, so a depth of 2 was enough to pull a large amount of the CC database for users with broad permissions. A value of 1 has been less bad, but has still shown some performance issues. Part of the problem is that it was a generic "get all related things" rather than allowing clients to target the relations they need.

So that being said, the feature still has some obvious value in limiting the number of requests necessary. Its worth mentioning that we do have a client that is fully V3 for apps and are finding their performance to be better by just paging through each resource they want and using the relationship data to stitch them together. But that still has some complication, so we have recently introduced what we hope can replace inline-relations-depth in V3. This is the include parameter here. It currently only allows including spaces for apps. We're trying to get some validation from clients before selectively expanding it to other resources. There will be some limits to the resources we end up supporting as an include, but organization seems like an obvious inclusion. Routes are a possibility. The docs aren't super clear on how to use the include property right now, but it is heavily inspired by the JSON API spec for including resources

@zrob Sorry for the incredibly slow response. We've been beavering away getting a release out.

I've created a doc that covers the parts of v2 we use and how they're utilised in Stratos, along with some examples of the requests we make as the user navigates around. I've tried to include a succinct summary too. Myself and @nwmac will both be at Basel in October, heard through the grapevine you're also there? Would it be possible to grab you for an hour and run through our v2 usage, state of v3, deprecation timelines etc? We'd also be interested to understand the use cases that the client on v3 is running with, particularly if they've already solved some of our v2-->v3 challenges.

@zrob @richard-cox and myself will be at the CF Summit - hoping to find some time to say hi and discuss this topic.

Hi @nwmac @richard-cox

I am at summit and would love to catch up. Not sure how best to coordinate. We can try with comments or on slack you can find me ‘@zach’

@zrob great - I’ve pinged you on slack.