What to do for nested API calls?

[meeple142]

I am wondering if there is a better solution for making nested API calls than the one that I have figured out. I would love some help on finding a good pattern. Here is a simplified working example of my current code structure https://dotnetfiddle.net/nqGftc

Explanation of code and what I am trying to accomplish:
Lets say I have a person class and the person class has a list of pets . Then I have a list of people and they all have pets that need to get sent to the server. There is an API class that makes the API calls to the server. It has two methods one to make new people and one to make new pets. The way the API works is that, in order to make a pet I need to make the Person on the server first, in order to have the Id of the person in order to make the pet. That is a pretty standard kind of thing from my experience. (If it was my server I would make a bulk add endpoint.) To try a make a clean solution, I chose to use Bind, Select and Combine and made some of the delegates into methods instead of inline lambdas. In this example the methods AddNewPerson and AddNewPets are simple but in my real code they have more calls like Ensure and Tap and maybe Map. So I thought that it made more sense to pop them out to their own methods in my code. Here I kept it simple but also try to preserve the real code's structure.

I don't love it. I wish it was easier to understand what the code is doing from a glance. I think it would help if the code could be changed to use more of the fluent nature of this library. The problem seems to come from needing the semantic "for each" functionally that LINQ methods offer. This isn't the first time I have struggled to make clean looking code that uses LINQ methods that have lambdas that return a Result. If I could make jumping between LINQ and Result methods less verbose, the code would be more declarative and communicate the intent of the code quickly. Perhaps there are more overloads in this library that work with IEnumerable<Result> that I overlooked. I saw the SelectMany but it doesn't have the "for each" baked in. You still have to do that in the delegate yourself. Is there an overload that is something like:
async Result<IEnumerable<K>> BindSelect( this IEnumerable<T>, Func<T, Task<Result<K>>>)
Of course that opens the door for questions like "What about all the other LINQ methods?", and "What if I wanted the returning result to have two lists.? A list of T that were successful and a separate list of T that failed so I can retry only the unsuccessful ones?"

Maybe I need to un-nest the Api calls/for loops and make it two separate loops? Perhaps that would be more functional?

Another thought I had was that I am using too many Results. Maybe I should just have one function that does the nested for loop (with or with out LINQ) and then call that method with Result.Try . That might be cleaner, but then I miss out on all the other nice methods Result has. It also brings back to mind the use case of wanting two lists returned back. But let's just start with a good pattern for nested loops with results and all I want returned is if if they all worked or not.

Anyway, I am guessing I am not the only one that has needed LINQ for nested for loops and wanted to use Results too, I am looking for a good pattern I can use in the future. I welcome any help or feed back from the community. Thank you in advance!

[vkhorikov]

There aren't that many methods in the library that work with collections, so adding additional ones is probably the best way forward. The BindSelect you proposed looks good, but, since the library takes naming conventions from F#, it should be BindMap (or MapBind) instead.

Regarding retries. I wouldn't do those retries separately and instead would do them inside the same method that adds a person/pet. This way, you can control the # of retries and it's just cleaner this way because you aren't stopping working on an object until you are completely done with it. This means that you would still need to introduce wrapper methods, so maybe your current approach is the best one after all.