EasyRPC. Be proud of your APIs (First Part) 🤓🚀

• • Frameworks

• 15/11/2019

Whether you are a front or a back developer, it’s quite likely that you already know about Web APIs. You may be consuming them, providing data with them… or both. Web APIs are a key part on most projects, and they have been with us for long time. Their evolution has been quite interesting, passing from complex and intricate architectures that boiled our brains to their current state. Over time, it seems that the development community came to an agreement on how Web APIs should work, and now almost everybody has a sense of what they are and how deal with them. They tend to be “RESTful”, that is, stateless, and exchanging JSON messages over the HTTP protocol.  

Our mission as developers 

As developers we always should do things right, but not only right, but better than it. 

We’re always should try to do more with less, while trying to keep everything as simple as possible. We’ll talk about programming principles in another post. 

That’s why we shouldn’t just adopt everything blindly. There may be a better way to do our stuff, and that’s what we call continuous improvement. 

And here is where I wanted to go:  

Current Web APIs are rigid and constricting.  

They clearly leave room for improvement. A lot. They are outlandish, inappropriate artifacts. They are aliens inside our code. 

Our Web APIs don’t shine 

It’s exactly that. We are introducing an unnecessary layer that essentially forces HTTP to adapt to a programming paradigm it wasn’t designed for.  

Adapt, improve 

• Why do we still write suboptimal Web APIs?  

• Why are we always implementing them in the same way without much criticism?  
• Aren’t you tired of exposing and consuming services through yet another useless layer?  
• Are you still forcing your API to fit into an outdated set of HTTP verbs that obscure your services?  
• Why do you use Controllers for that?

 

Pain points

Calling a Web API is boring and sometimes painful because interfaces tend to be unclear, operations aren’t clear enough or they don’t fit well into the HTTP way of thinking.

Calling Web APIs often require clients that need to be configured. Regarding the code, the server part is ugly, and the client side is, too.

1. You need to figure out how your methods fit with the GET, POST, UPDATE, DELETE methods.
2. If it’s GET you will have to plan where in the URL are your parameters. Having to do it on your web layer is inconvenient.
3. You will spend too much time having to deal with URL routes a mapping.
4. Most methods are just entry points that do nothing but delegating the real actions to a service.
5. Testing controllers can be a nightmare.

Services should be called with zero pain.

A new approach. Here we go!

Let’s do things differently. Let’s do things more naturally, fluent and terse.

We need something to fill the gap, to ease the pain, to communicate more elegantly among application boundaries.

What if you just had to call a web API service like you call any other class? What if you could stop creating Controllers to deliver our stuff?

EasyRPC is here to heal your soul. It makes your service work like if it was just another local service of your application.

var result = mathService.Add(1, 3);

Pretty conventional, isn’t it? Except for the fact that the service is a remote service.

The client side is beautiful, but the server side is pure goodness.

public class MathService : IMathService 
{
	public decimal Add(decimal a, decimal b) 
	{
		return a + b;	
	}	
}

Nothing more, nothing less.

EasyRPC = Easy + RPC

EasyRPC lives up to its name. For those wondering, RPC stands for “Remote Procedure Call”, a technology that enables calling service methods like they were local services.

The interesting thing is that you can just ignore anything you had in-between. As soon as you write a service, it’s ready to be used. Zero boilerplate. No waste.

Application boundaries are way less of a concern because you don’t ever have to think in all the extra code that conventional Web APIs require, that always end up having sharp edges across layers.

EasyRPC does all the heavy lifting. It just works®

Benefits

Pay close attention, because using it you will automatically get all of these benefits:

1. EasyRPC removes the need to think about URL construction, parameter passing, or choosing which HTTP verbs to use, allowing the developer to focus on business logic.
2. It integrates with smoothly with ASP.NET Core authentication framework so that authorization attributes are honored as well as other authentication primitives.
3. It has built in documentation similar to Swagger, but with no external dependencies 😊
4. Filters, that provide cross-cutting support for things like transaction commit/rollback, logging, etc. Very similar to MVC filters.
5. Clients are generated at run time based on interfaces, allowing the developer to access services without having to write any HTTP code. This is simply awesome.
6. Supports inbound and outbound compression (Gzip, Brotly)
7. Can be expanded to support encodings other than JSON to things like MessagePack or ProtoBuf

We believe that this way a coding feels so natural that, once you have created your first service, you won’t want to go back 😉

But that will be part of our next post, where we will show you the real working code.

Stay tuned!

Written by: José Manuel Nieto, part of Idiwork’s team