DEV Community: Corey O'Connor

Request Per Second is probably not it

Corey O'Connor — Mon, 30 Mar 2020 19:09:43 +0000

Let's start with a question: When you loaded this page did you experience the value the server's requests per second provided?

The web browser sent a request to the domain. Which, for a standard stack, will look something like:

domain name lookup to one or more addresses
one of these addresses is selected
request is sent to the selected address
arrives at load balancer
dispatched to one or more nodes
that specific node(s) processes the request and replies
load balancer replies with a selected request

Where in that did the user experience "requests per second?".

They didn't directly experience this for a (single) request. The user experience was of the latency. They did not directly experience maximum throughput or even per-node throughput.

The service provider does receive value from per node throughput: Typically the higher throughput the more value per node in the system. Which, being dependent on value, depends on the customer. If the value per request warrants the cost then the throughput can be scaled.

The service provider also receives value from the max throughput of the system: A higher max throughput the more customers can be supported without queueing.

Imagine two scenarios:

A service that provides a security alarm system at 10k requests/sec. For one customer. With a latency of 20 days per request.

That would probably not provide the experience the customer expects from a security system :) Even if each request is high value; with that latency the value is unlikely to be realized.

A service that provides bank transactions at a latency of 1 second. With a per-node throughput of 1 request per second; the entire node processes only a single request at a time.

That might be entirely fine. Suppose each node cost 10$ for the duration of the request... but the request provided the company a value of 100$. I'd happily take that per-node throughput! The customer still experiences a fast transaction and the company can afford to horizontally scale and still profit.

Certainly don't forget throughput when decided the value of an implementation. Good performance engineering practice would be to record this performance data. Even if not explicitly optimizing for this. Designing systems to provide value to customers is always the priority. Which likely means a focus on latency first and throughput second.

"GraphQL vs REST" is ill-typed

Corey O'Connor — Fri, 25 Oct 2019 23:26:26 +0000

What?

"Wait just a minute.. What do you mean 'ill-typed'?"

We see a lot of talk about "GraphQL vs REST". In fact, a quick search of DuckDuckGo shows pages of results on this exact subject. Yet, pedantically speaking, the statement is a false comparison.

To be clear, those posts are typically discussing a specific class of REST server. And there are huge advantages in using GraphQL. Let's dig into the details to understand what's actually going on. Which will inform us to better understand when to use each one.

Quick Review

What is REST?

According to wikipedia, is a software architectural style for web services.

What is GraphQL?

According to wikipedia: a data query and manipulation language and runtime for APIs.

The Types

Right from the start we should notice that these definitions are different: One is referring to an architectural style. Which is, at most, a logical design. The other is referring to a language and runtime. Which is not a style but a physical design.

Rather like comparing a Toyota against wheeled vehicles. "Toyota vs wheeled vehicles". Sounds kinda silly huh? "Toyota is a high quality implementation of wheeled vehicles" sounds better no?

Indeed, GraphQL is a high quality (but narrow!) REST interface. :)

GraphQL <: REST ?

Neither GraphQL or REST are limited to HTTP. That said, if we focus on HTTP we will find that GraphQL over HTTP adheres to the REST architectural style! The caveat is that the range of data (the resource) from the single /graphql endpoint is large. Fortunately, how that endpoint behaves, the structure of the requests and response is precise. This precision is ensured to a degree REST cannot provide in general.

So what is it?

GraphQL is an Interface Description Language :)

Pretty much what the wikipedia definition was! Still, it's not fair to assume it's "just another IDL". Unlike many other IDLs: GraphQL contains request composition and a clear specification of interpreter semantics. GraphQL also supports a high quality, REST compatible, transport. These are valuable innovations!

Here we also find a start for describing where GraphQL is best applied: When a precise interface description is possible and required; When the domain of client requests requires composition. This is not always the case, but covers (in my experience) a large spectrum of services development.

Antipatterns

To continue with attempting the comparison of "GraphQL and REST" without considering the application is risky. Naively assuming, from this false comparison, "GraphQL is better than REST" can result in a variety of issues

Take a few situations where using GraphQL is questionable:

Serving binary data resources. GraphQL only has a single representation. Any data that is to be provided must be serialized in this representation. If there is a requirement to serve, for example, large images of various formats a GraphQL server would be costly and, frankly, re-implement a lot of REST.
Requirement for non-compositional requests. The composition aspect of GraphQL has a cost: The request must be interpreted accordingly. This is non trivial in general and can result in an unacceptable decrease in request cost bounds precision. As well as an increase in attack surface area.
Client complexity. Asymptotically, a minimal REST solution for certain applications is simpler than the equivalent GraphQL. This is an extreme comparisons tho. For most applications: reliable high quality client/server is a better choice than attempting to achieve the absolute optimal.

Concluding the Pedantry

I hope you found this pedantic adventure interesting! In the end, GraphQL is another excellent and useful tool for our toolbox. However, let's not forget the real goal:

To develop high quality services for our customers.

Always keep that in mind. Never settle no matter the hype. You'll do great! :D

Questions to ask for CQRS

Corey O'Connor — Wed, 16 Oct 2019 19:11:19 +0000

CQRS stands for "Command Query Responsibility Segregation". The idea is an extension of the single responsibility principle applied to services:

Command and Query are responsibilities of a system. By single responsibility principle, each of these responsibilities should be separate in the system.

"How tho?" As with all design principles: giving the definition does not teach how to apply the principle. :)

There are a lot of technologies that enable CQRS and these are worth an overview. I want to focus on the conceptual and logical first. The critical aspect of segregating command and query is useful even in design.

For instance, a useful question: "Does this change the state of the system?". This likely resembles asking about purity to functional programmers. Yep, same idea :) Just applied early and often in the design. We should aim for a clear answer: Yes or no. If there isn't a clear answer then that likely indicates a poor separation of command and query.

Is this an interesting topic for anybody else?