EasyRPC – Be proud of your APIs ūü§ďūüöÄ [First part]

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 


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¬ģ


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: Jose Manuel Nieto, part of Idiwork’s team

Stay up to date!

1 comment

Leave a comment