You will rarely hear a blockchain argument that does not talk about trust. People use it in different contexts which confuses others who are still trying to understand what blockchain is. I have also been asked to exactly define what I mean by trust. I will try to explain that in this article through the trust models that we live in

A lot of times we build an API to meet a specific need, publish those APIs and then expect the consumers to use the API for that specific purpose. This may work when both API producers and consumers are the same team. But the moment API consumption goes outside of the team, it becomes difficult to dictate how the consumers must use the API. It is best not to make any assumptions around that.

One of the challenges of building any public API is that you do not know who will use your API, or how they will use it. That also means you cannot make assumptions about some aspects of the API. One such aspect is size of the payload. A number of factors specific to the business domain and API implementation will decide the size of the payload. However, it will be wrong to say that the consumers have no role to play in this. API consumers would want to be able to fetch just the enough data from any API. This saves them network bandwidth and processing of unnecessary payload.

This is a series of blog posts on my random thoughts on load testing. I have seen that some of the very useful and interesting load testing ideas do not get much talked about and practised. If you may have come across these before, or you may these intimately. But if you have not, hope you find these posts useful

Transaction mix let's you mimic how the real users will use different features of your website. A right transaction mix let's us project the right website performance with the right server capacity needed.

It's impossible to come up with an estimate that is close to reality, specifically when the reality itself is not constant which is usually the case. If you, as a product manager, fail to realise this and keep holding the team for their estimates, then they will learn to work around your behaviour by inflating the estimates or by cutting corners. Both are harmful to your product. So how do you deal with such situation without blowing your budget through the roof?

One of the characteristics of a good REST API is that it uses the standard HTTP methods in a way they are supposed to be used. We hear this all the time and this is the most fundamental guideline of REST.But beyond the basics, why is it like that?

Standard HTTP status codes are a good starting point to indicate error condition but they are not enough. Especially if you are developing APIs that are consumed by a large number of developers or are open to access by anyone then you may want to return well-formed error responses that provide more details about the error.

AI, use of voice or guide UI does not make a chatbot great. It is the personality of the bot that makes it great. But what does "personality of the bot" even mean?

A lot of people find it difficult to understand how bitcoin (and consequently the blockchain) works. One of the reasons for this could be that the most explanations on the internet either take away a lot of important technical details or keep a lot of details in. Both results in confusion. Complex topics like bitcoin and blockchain can best be explained by using an everyday analogy. So here is one for you.