If a function has too many conditionals, it means that this function is trying to do too much. Instead refactor into separate functions with more specific names to handle the use cases. This has the side effect of giving us more domain rich function names.
If one function gets too big and handles too much logic, the logic could likely be extracted to a function with a more specific job. This is similar to above, just a different way of looking at it.
Don't think in terms of grouping via infrastructure layers (api, services, user interfaces), but instead use cases. A use case could contain code that modifies services, update, & call API all together in the same function.
A function should do what is says, with as little side effect as possible.
If a use case requires 2 API's calls to accomplish, create a 3rd function that calls the 2.
"You aren't gonna need it", so don't create this fancy architecture in advance.
Don't make this re-useable unless it's needed, doing so may pollute the class you're using and expose un-needed API.
Names like el, svc, fn, etc are not readable and don't have any benefits, long descriptive & readable name are preferred.