How we got here, from SOAP to REST to GraphQL to gRPC to MCP

Before we dive into the details of the MCP, let’s take a step back and look at how we got here.

One of my early memories of using web requests involved using XML to send and receive data. This was back in the days of Simple Object Access Protocol (SOAP), which was a protocol for exchanging structured information in the implementation of web services. It was great, but it was also very complex and felt heavy.

Then came Representational State Transfer (REST), which was a simpler way to build web services. It used HTTP and JSON, which made it easier to work with. REST was, and is, great.

There’s nothing inherently wrong with REST, but you could argue that if you had a backend team and a frontend team, the frontend team would often be waiting for the backend team to finish their work before they could start building the frontend. This is where GraphQL came in, which allowed you to query only the data you needed and made it easier to work with APIs. Of course, that creates other problems, such as over-fetching and under-fetching data and what’s known as the N+1 problem. The N+1 problem is a common performance issue in GraphQL APIs where multiple requests are made to fetch related data, leading to inefficiencies and increased latency.

There’s also Google Remote Procedure Call (gRPC), which is a high-performance RPC framework that uses HTTP/2 and Protocol Buffers. gRPC is great for microservices and allows you to define your APIs in a more structured way, but it can be complex to set up and use.