Tagged with gRPC
Writing APIs have been a big part of my career. I've written COM, DCOM, XML based APIs, ISAPI Filters, SOAP, REST, gRPC, and others. A lot of this time a new technology in writing APIs has been chasing the new ‘cool’ technology that would fix everything.
The chase has always been lost cause. APIs, like most things in computer science, are a set of compromises. I think, for the first time in my career, we're entering a time when we don't need a ‘winner’ but need to stop thinking about APIs as a better hammer.
While Microsoft's announcement of embracing gRPC and GraphQL both came as surprises, I'm still flummoxed by some developer's insistence that some new technology is the one to rule them all. That's made me start thinking about how we can think of APIs in a different way.
I started writing services in websites back in the .NET 1.0 days. Originally I was doing just POX (Plain Old XML) services in a very crude way so we could get the job done for our internal systems back in the early 2000's.
This means I've been through the "new tech" crazy with services for a long time. I've spent much of the last year digging into different tech for services to interact with websites (though many of the same issues are for rich clients and IoT). I'm not done and don't know how right my assumptions are yet, but I thought I'd try to start a conversation.
While I've lived through POX, SOAP, and REST...I don't think this is another wave. I think this is a widening of options for services. But what does the service ecosystem look like right now? (Caveat: I'm going to miss your favorite idea, so feel free to add to the discussion below.)