A little chit-chat

It's been a while since I posted anything so  I thought I'd write an article on the pros and cons of chatty interfaces...

When you're hosting a sleep-over for the kids and struggling to get them all to sleep you'll no doubt hear that plaintiff cry "I'm thirsty!", usually following in quick succession by 20 other "Me too!"'s...

What you don't do is walk down the stairs, fetch a glass from the cupboard, fill it with milk from the fridge and take it back upstairs... then repeat 20 more times - you may achieve your steps-goal for the day but it'll take far too long. Instead you collect all the orders, go downstairs once, fill 21 glasses and take them all back upstairs on a tray (or more likely just give them the bottle and let them fight it out).

And so it is with a client-server interface. If you've a collection of objects on a client (say customer records) and you wanted to get some more info on each one (such as the address) you'd be better off asking the server the question "can you give me the addresses for customers x, y and z?" in one go rather than doing it three times. The repeated latency, transit time and processing by the server may appear fine for a few records but will very quickly deteriorate as the number of records rises. And if you've many clients doing this sort of thing you can get contention for resources server side which breaks things for all users - even those not having a wee natter...

Is chatty always bad?

It comes down to the atomicity of requests, responsibility and feedback.

Atomicity...

If it's meaningful to ask a question like "can you give me the address for customer x, account-balance for customer y and shoe-size for customer z?" then by all means do so, but most likely that's really three separate questions and you'll get better reuse and maintainability if you split them out. Define services to address meaningful questions at the appropriate granularity - what is "appropriate" is for you work out...

Responsibility...

You could break the requests out server side and have a single request which collects lots of data and returns this at once rather than having lots of small requests go back-and-forth. This model is common for web-pages which contain data from multiple sources - one requests for the page, server collects data from sources and combines this in one response back to the user. Problem is, if any one of the the sources is performing badly (or down) the whole page suffers and your server chokes in sympathy as part of a cascading failure. So is it the responsibility of the server to collate the data and provide a unified view (often it is) or can that responsibility be pushed to the client (equally often it can be)? If it can be pushed to the client then you can actually improve performance and reliability through more chatty round-trips. Be lazy, do-one-thing-well, and delegate responsibility as much as possible...

Feedback...

Your end-user is a grumpy and impatient piece of wetware incapable of acting repetitiously who seeks instant gratification with minimal effort and is liable to throwing the tantrums of a two year old when asked to "Please wait...". God help us all if you send them an actual error... To improve usability you can trigger little round-trip requests to validate data asynchronously as they go and keep the user informed. This feedback is often enough to keep the user happy - all children like attention - and avoids wasted effort. Filling in a 20 page form only to have it rejected because of some cryptic checkbox on page 3 isn't going to win you any friends. And yet it is still o' so common... I generally work server-side and it's important to remember why we're here - computers exist for the benefit of mankind. User interface development is so much more complicated than server-side and yet simplicity for the user has to be the goal.

So chatty is generally bad for performance and reliability though it can though be good for UX and depending on where the responsibility sits, can improve things overall.

However, as we move towards a micro-services based environment the chatter is going to get louder and more disruptive. Understanding the nature and volumetrics of the questions that are asked of services and ensuring they are designed to address these at the correct granularity will help keep the chatter down whilst making the code more maintainable and reusable. As always, it's never black-and-white...