EasyRPC. Be proud of your APIs (Second Part) ??
Welcome to the second part of the series dedicated to EasyRPC.
In the last post, we set the motivations for a new way to develop our APIs and presented EasyRPC as a very interesting way to improve them.
Now, we’re ready to dig in and start building our first Web API using EasyRPC.
Let’s get down to business!
NOTE: This post contains a lot of images and animations. If you find them difficult to read, right-click on the given image and open it in a new Tab.
Our first application
EasyRPC is baked with top-notch ASP.NET Core 3 support, so our first step will be to create an ASP.NET Core Web Application with Visual Studio.
Just click Next
Type the project name if you want and accept the defaults. Click Create.
In the next page we’ll select ASP.NET Core 3.0 and Empty as the template. Press Create.
After a while, the solution is created, and you’ll be ready to go. Your Solutions Explorer should like like this:
The first things we’ll do is to install EasyRPC from NuGet.
To do it, right-click on the project and select “Manage NuGet Packages…”
Type “easyrpc” in the search box and inside the results you should see one titled EasyRpc.AspNetCore. Install it.
Important: Don’t forget to tick on the “Include prerelease” option. Support for ASP.NET 3.0 requires EasyRPC 4.x that is still in beta.
After it’s installed, we need to configure the ASP.NET Startup class to use it. Open Startup.cs and edit it ?
In this step, we’ve configured EasyRPC to handle our requests to the server.
Now, we’re going to create a service. For simplicity sake, we’re going to create a very basic CalculatorService, that only performs an operation with primitive types.
Let’s implement the Add operation. Easy enough, isn’t it? ?
We’re going to make our service implement an interface, ICalculatorService. This is usually a very good practice in terms of design and testability and will also enable service location via interface.
As easy as that.
We can already run our application and test it.
- So fast?
- Yes! FASTER THAT FAST ?
Run the application with F5 and a website will open. You’ll see your service on the sidebar with all the available methods.
Let’s try our Add method!
You may have noticed that not only the CalculatorService is shown, but also the Startup class is exposed. How can we do it?
Well, we told EasyRPC to expose the whole assembly. Let’s fix it.
That means “expose the types that in the same namespace as CalculatorService”. You can use a lot of combinations of extensions methods to expose whatever types you want.
Run the application with F5 and you’ll see that Startup no longer shows ?
Creating the client
Invoking our service with the API explorer is fun, but we want to have our very own client invoking our service.
Let’s create one. It will be console-based to stick to simplicity.
In order to consume our API, we need to use the client package for EasyRPC. It will allow use to consume any EasyRPC service with ease.
Important: Don’t forget to tick on the “Include prerelease” option. Support for ASP.NET 3.0 requires EasyRPC 4.x that is still in beta.
In the search results, select the package titled EasyRpc.DynamicClient.Grace (the second one in the screenshot)
Now go ahead to Program.cs and type the following code
For your convenience, the code is included as screenshot and as text, so you just need to copy&paste it ?
class Program
{
static void Main(string[] args)
{
var container = new DependencyInjectionContainer();
container.Configure(c => c.Export<InterfaceNamingConvention>().As<INamingConventionService>());
container.ProxyNamespace("https://localhost:44307/", namespaces: typeof(ICalculatorService).Namespace);
var service = container.Locate<ICalculatorService>();
var result = service.Add(2, 2);
Console.WriteLine($"The result is {result}");
Console.ReadLine();
}
internal class InterfaceNamingConvention : INamingConventionService
{
public string GetNameForType(Type type)
{
return type.Name.Substring(1);
}
public string GetMethodName(MethodInfo method)
{
return method.Name;
}
}
}
OK, let’s explain what we’re doing here:
- We’re creating a DI IoC container (Grace). It will be the facility that will provide instances our services (although we only have one now).
- We’re configuring the container to follow a naming convention in order to locate types (it skips the first character of the type name, so when we’re looking for ISomeService, SomeService is looked up.
- We’re configuring the container to create a dynamic proxy for any interface that is requested from the specified namespace.
The rest is quite straightforward
var service = container.Locate<ICalculatorService>();
We’re asking the container for our service via interface.
var result = service.Add(2, 2);
Console.WriteLine($"The result is {result}");
Console.ReadLine();
In the part we are just invoking the Add method and showing the results on the console.
Finally, don’t forget to use the correct URL in the ProxyNamespace part. You can get the URL you should use in the Properties page of the server project (SampleWebApp). See the screenshot.
Do you want to test our client? Of course. We’ll do it right away, but first, we should configure our 2 apps (both server and client) to launch correctly. We will do it configuring our solution to have multiple project startup.
This is how it’s done.
Now we can go ahead. Press F5 and the client will run, communicating with the server and printing the result ?
Wonderful, isn’t it?
We love EasyRPC and we’re sure you’ll love it, too.
Stay tuned, because this is only the beginning. We’ll explorer more of the features and use cases in future posts.
Written by: José Manuel Nieto, part of Idiwork’s team