The State of Writing Services for the Web

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.)

SOAP
REST
GraphQL
WebSockets IO
gRPC
Message Bus/Queues

Let’s talk about each of these briefly as where I see them used:

SOAP

Often when I talk about services and mention SOAP, I get a handful of giggles. It’s interesting as it brings to the surface a common problem in software; belittling legacy software - no matter how good. This is where SOAP has come in. SOAP still has a lot of benefits, mostly of the ecosystem. The wrappers around SOAP that support the WS-* technologies mean that it still meets needs at the enterprise level that isn’t necessarily matches with REST-ful services. But it has drawbacks. If you’re still living in the WCF world (or corresponding Java technologies), you don’t need to change just to keep up with the cool kids. Configuration and complexity certainly have made a lot of SOAP implementations hard to swallow.

I think SOAP should mostly be relegated to existing code or places where it fits specific needs to adhere to standards (e.g. WS-Security).

REST

At this point, we can call REST vernerable. It’s solid. We know what it does and the reasons it does what it does. Though probably too many just use the thin veil of REST without considering some of the important constraints (e.g. cachability and idempotency). On the other side of the field are dogmatic REST users that believe if you’re not implementing HATEOAS services, you’re not doing it right.

I continue to think that REST’s simplicity means it will continue to make up the majority of services created for apps and web sites.

WebSockets

In the beginning, WebSockets seemed to solve many of the problems with HTTP-based services. It promised to provide a socket-based technology that worked in the browser. Now that modern browsers are mostly all compliant with WebSockets, it should be exploding. But it’s not. I think WebSockets was hurt by the lack of early support. Anyone that wanted to use it widely realized that they needed to have a backup strategy. With that, some developers went back to REST or SOAP as that worked better in most of the browsers.

Now that it’s widely available, I think WebSockets are a completely viable technology. But think of WebSockets like Socket programming. If you’re building something that isn’t really about long-lived connections, there isn’t much reason to try WebSockets. It’s become an underlying technology that other web tech (e.g. SignalR, et al.) use to implement something that most enterprise developers will use.

GraphQL

GraphQL is one of the new kids on the block. It defined a query language for querying data across a network connection. This is a laudable goal. While I’ve said, “This is the second coming of OData”…it has learned from the mistakes of OData and is an admirable stab at the problem of simplifying CRUD over a service.

But GraphQL is complex. To setup a server with your data model (and secure that data model) isn’t trivial. To query the service isn’t simple either. But it really does allow for a set of use-cases that are important. GitHub has extended their API by using GraphQL to allow people to get at the extended data that they have inside the vaults.

GitHub using it has made some people believe it’s the new successor to REST, but I still think that it’s use should be limited to situations where you need to expose your complex data to a large set of diverse users. Using it instead of REST for most apps and web sites I think it overkill right now, but I think there is a lot going on here. Most web developers should keep their eyes on GraphQL. It’s a great technology.

gRPC

If you’re confused by this inclusion on the list, keep reading. This isn’t just an old-school RPC framework. It’s something different. gRPC came out of Google’s work with Protocol Buffers. The idea behind protocol buffers is to allow for different patterns of message passing where it isn’t always from client to server. gRPC are not quite as easy to build as REST, but it isn’t that difficult either.

One of the things that makes gRPC interesting is the idea of using protocol buffer files to define contracts between client and server. In many ways it’s similar to what SOAP or DCOM were trying to do. But of course, gRPC is really cross-platform so it has a wider acceptance factor (even for a new technology).

I think gRPC will open some interesting avenues for developing RPC-style APIs when that is necessary. Typically gRPC requires many fewer resources for clients. The side effect of this is that I think gRPC will be big in IoT more than necessarily web development. But don’t sleep on gRPC, it could be a big deal soon.

Message Buses/Queues

Last one is one of the biggest and oldest technologies but don’t get much interest from everyday developers. Message Buses and Queues are similar technologies that allow for scaling, distributed, and asynchronous services work. They aren’t going away in any way.

For web developers, you should also keep these technologies in mind…but they’re not really made for typical CRUD-like scenarios. You should be looking at these when you’re building scale-out systems and service-oriented architectures.

How Am I Wrong?

This is where you come in. I’m reading, experimenting, and thinking about these problems. Most of you are building these systems. Where do you feel they belong? Did I say something wrong about your favorite tech? Tell me below. I’d rather be wrong now; then spouting the wrong thing for years to come.

Thanks!