REST vs. gRPC – The Battle Over Service Orientation

Rest Vs. gRPC

Services are a common talk between developers and companies that are in the process of implementing software; they are an important piece in any project architecture as they separate layers of functionality and offer the flexibility of implementing different levels of security in between layers. Their implementation can vary from serving data from the database servers, sending messages to other servers, and much more.

In .NET technologies there used to exist an entire framework dedicated to services and Windows Communication Foundation, this collection of tools would help set up services in a variety of protocols. On the downside, they were closely coupled with .NET, making the configuration of services more complex than some of the most popular options of its time.

Then came REST, a new portable way of communicating clients and servers via TCP, making them accessible over the internet. Most of the big web sites implement REST APIs to provide information to the outside world (such as Google, Twitter, LinkedIn, etc.). This model is based on Request-Response model that will return a text-based response (JSON, XML, HTML), currently the standard is JSON (JavaScript Object Notation). This is a flexible way to work with objects without depending on the platform.

The Problem…

The problem with JSON comes when you have a high demand application (server or client) that will make a large amount of request/responses. If you have to serialize/deserialize the objects to your native types, it will add an extra conversion overhead. If you are not having a outword facing application, you mostly have the same technologies applied in both sides of the communication, meaning that the service will have to take the response object from C#, serialize it to JSON and send it back to the client. Then the client will take the response JSON and deserialize back to your C# object. This is by no means hard to achieve, but the processing time may be impacted by the workload of your application.

There is a solution!

To solve this, we have RPC (Remote Procedure Call). This communication is based on Protocol Buffers, a mechanism to serialize data (the data is serialized in raw format). It offers all the main functionalities that REST does, with the added option for bidirectional streams that allow the client and server to communicate asynchronously that result in faster times. The configuration steps to get a gRPC service may seem a little more complex and limited than REST (Protocol Buffers currently supports generated code in C++, Go, Java, Phyton, Ruby and C#), but the benefit of faster performance may compensate.

In conclusion.

Current implementation of services using gRPC came with the adoption of Cloud computing and microservices with high performance demand. So, if you are planning create or enhance a service take a look at the past first, then present technologies and the future of your implementation in order to make the correct call. In conclusion, REST is still the most simple and portable solution if you don’t have an issue with communication performance.

If you want to know more about gRPC go to

Choosing between .NET Core and .NET Framework for server apps

There are two supported implementations for building server-side applications with .NET: .NET Framework and .NET Core. Both share many of the same components and you can share code across the two. However, there are fundamental differences between the two and your choice depends on what you want to accomplish.

Use .NET Core for your server application when:
• You have cross-platform needs.
• You are targeting microservices.
• You are using Docker containers.
• You need high-performance and scalable systems.
• You need side-by-side .NET versions per application.

Use .NET Framework for your server application when:
• Your app currently uses .NET Framework (recommendation is to extend instead of migrating).
• Your app uses third-party .NET libraries or NuGet packages not available for .NET Core.
• Your app uses .NET technologies that aren’t available for .NET Core.
• Your app uses a platform that doesn’t support .NET Core.

Top reasons to choose .NET Core

Cross-platform Needs
If your application needs to run on multiple platforms like Windows, Linux, and macOS, use .NET Core; it supports the previously mentioned operating systems as your development workstation. Visual Studio provides an Integrated Development Environment (IDE) for Windows and macOS. You can also use Visual Studio Code, which runs on macOS, Linux, and Windows. Visual Studio Code supports .NET Core, including IntelliSense and debugging. Most third-party editors, such as Sublime, Emacs, and VI, work with .NET Core. These third-party editors get editor IntelliSense using Omnisharp. You can also avoid any code editor and directly use the .NET Core CLI tools, available for all supported platforms.

Need for High-performance and Scalable systems
When your system needs the best possible performance and scalability, .NET Core and ASP.NET Core are your best options. High-performance server runtime for Windows Server and Linux makes .NET a top performing web framework on TechEmpower benchmarks.Performance and scalability are especially relevant for microservices architectures, where hundreds of microservices may be running. With ASP.NET Core, systems run with a much lower number of servers/Virtual Machines (VM). The reduced servers/VMs save costs in infrastructure and hosting.

Microservices Architecture
Micro services architecture allows a mix of technologies across a service boundary. This technology mix enables a gradual embrace of .NET Core for new microservices that work with other microservices or services. For example, you can mix microservices or services developed with .NET Framework, Java, Ruby, or other monolithic technologies Need for side by side of .NET versions per application level To install applications with dependencies on different versions of .NET, we recommend .NET Core. .NET Core offers side-by-side installation of different versions of the .NET Core runtime on the same machine. This side-by-side installation allows multiple services on the same server, each of them on its own version of .NET Core. It also lowers risks and saves money in application upgrades and IT operations.

Need to use .NET Technologies Not Available for .NET Core
Some .NET Framework technologies aren’t available in .NET Core. Some of them might be available in later .NET Core releases. Others don’t apply to the new application patterns targeted by .NET Core and may never be available.

The following list shows the most common technologies not found in .NET Core:

ASP.NET Web Forms applications:
• ASP.NET Web Forms are only available in the .NET Framework.
• ASP.NET Core cannot be used for ASP.NET Web Forms.
• There are no plans to bring ASP.NET Web Forms to .NET Core.

ASP.NET Web Pages applications:
• ASP.NET Web Pages aren’t included in ASP.NET Core.

WCF services implementation:
Even when there’s a WCF-Client library to consume WCF services from .NET Core, WCF server implementation is currently only available in the .NET Framework. This scenario is not part of the current plan for .NET Core but it’s being considered for the future.

Workflow-related services:
Windows Workflow Foundation (WF), Workflow Services (WCF + WF in a single service) and WCF Data Services (formerly known as “ADO.NET Data Services”) are only available in the .NET Framework. There are no plans to bring WF/WCF+WF/WCF Data Services to .NET Core.

Language support:
Visual Basic and C# are currently supported in .NET Core, but not for all project types. For a list of supported project templates, see Template options for dot net new.

In addition to the official roadmap, there are other frameworks to be ported to .NET Core. For a full list, see the CoreFX issues marked as port-to-core. This list doesn’t represent a commitment from Microsoft to bring those components to .NET Core. They’re simply capturing the desire from the community to do so. If you care about any of the components marked as port-to-core, participate in the discussions on GitHub. And if you think something is missing, file a new issue in the CoreFX repository (Some References are taken from MSDN).

ASP.NET Core with EF Core and RESTful API
ASP.NET Core is an open source, cross-platform framework for building modern internet connected applications, and ASP.NET Core MVC is a middleware which provides a framework for building the APIs and web application using MVC pattern. (Click here to learn more about ASP.NET Core)

Create an ASP.NET CORE application
Open Visual Studio, File -> New ->Project, select ASP.NET Core web application template and click OK

Choose an API template as shown below

By clicking on OK, it will create a new ASP.NET Core project with some pre-defined configuration files and controller.

The program.cs class which contains the main method with a method called Createwebhostbuilder(), is responsible for running and configuring the application. The host for the application is set up with the startup type as startup class.

The startup.cs class contains two important methods:

ConfigureServices() – it is used to add service to build dependency injection containers and configure those services,
Configure() – it is used to configure how the ASP.NET Core application will response to an individual HTTP request.

Configure the Entity Framework Core

Create a folder called Entities to organize the entity model classes. Let’s create an entity model class.

Creating a Context File

Let’s create a context file, add a new class file, and name it as LibraryContext.cs.

Define the database connection in appsettings.json file and let’s register our context in Startup.cs.

Generate Database from Code-first Approach
Run the following command in the Package Manager console.
-Add-Migration MyCoreAPIDemo.Entities.LibraryContext

This will create a class for migration. Run the following command to update the database.

This will update the database based on our models.

Adding Data
Let’s add some data to the Author table. For this, we need to override a method OnModelCreating in the LibraryContext class.


Let’s run the migration and update command once again.

Creating a Repository
Let’s add a repository folder to implement the repository pattern to access the context method.

Create two more folders – Contract and Implementation – under the repository folder.

Create an interface ILibraryRepository.cs under Contract folder.


Let’s create a class under implementation folder to implement the function.


The above method GetAllAuthor() will return the complete list of records from Author table.

Let’s configure the repository using dependency injection. Open Startup.cs file, add the below code in Configuration Services method.

Create API Controller

Right-click on controller and go to Add->Controller. Choose an empty API template and name the controller. I named the controller as LibrariesController.

We have created a WEB API with an endpoint api/Libraries/GetAllAuthor to get an author list from the database.

Let’s test the API using Postman tool.

We got an author list as a response.


CREATE using Entity Framework with ASP.Net Core

Open the LibraryRepository.cs file from the application and write the below code.

_libraryContext is our database context, the Add method is used to add the records in the entity, and the SaveChanges method is used to save the changes in the database.

Open LibrariesController.cs file from the application and write this code.

The AddAuthor action will fetch the data from the body of request. Once the modelstate is validated, the data will be added to the database by calling the PostAuthor method in repository.

Let’s test the API in POSTMAN.


From the above image, you can notice that the data is successfully added and returned

Changes in the database

We already discussed about GetAllAuthor() read method in my last article. Now, I’m giving a demo of the method which is used to read the data from the database based on Id.

Open the LibraryReporsitory.cs file from the application and write the following code into it.

Open the LibrariesController.cs file from the application to add the below code.

Let’s test the API in POSTMAN.


From the above image, you can notice the author data is returned based on the author id.

Open LibraryRepository.cs file and update it with the given code.

_libraryContext is our database context, the Update method is used to update the records in the entity, and the SaveChanges method is used to save the changes in the database.

Open LibrariesController.cs file from the application and write the below code.

The UpdateAuthor action will fetch the data from the body of request. Once the modelstate is validated, the data will be updated in database by calling the UpdateAuthor method in the repository.

Let’s test the API in POSTMAN.


From the above image, you can notice that the author data is updated based on the request.

Changes in the Database


Open the LibraryRepository.cs file from the application and add the following code.

The Remove method is used to remove the records in the entity, the SaveChanges method is used to save the changes in the database based on update done in data entity.

Open LibrariesController.cs file from the application and write this code.

The DeleteAuthor method will delete the record by calling the DeleterAuthor method in the repository based on the author id passed through the request.

Let’s test the API in POSTMAN.


From the above image, you can notice that we got a response as 1 which means the data is deleted successfully based on the request.


We saw how to create a ASP.NET Core with EF Core and RESTful API .
We will see more about ASP.NET Core in future articles.

Various Types of Action Results in WEB API 2

WEB API 2 is a framework for building HTTP services that can be accessed from any client including browsers and mobile devices. It is an ideal platform for building RESTful applications on the .NET Framework.

HTTP is not just for serving up web pages. HTTP is also a powerful platform for building APIs that expose services and data. HTTP is simple, flexible, and ubiquitous. Almost any platform that you can think of has an HTTP library, so HTTP services can reach a broad range of clients, including browsers, mobile devices, and traditional desktop applications. ASP.NET Web API is a framework for building web APIs on top of the .NET Framework. The following are the return types for Web API action methods.

Read More Various Types of Action Results in WEB API 2

An Introduction to Low-Code Development Platforms


Software Development can be a long and costly process which can be extremely risky at times. Many companies have tried to combat the risks associated with developing software that does not function in a way that is intended or is unable to properly execute all of its tasks.


One of the major ways to combat these issues is using Low Code Platforms, which have gained a lot in popularity. These platforms are designed for people with different backgrounds and levels of expertise to be able to build functional platforms for their organizations.

While developed software is usually easier to use and can be catered perfectly to the specific operations of the organization, they are notoriously hard to maintain in house. These software’s usually require regular maintenance, upgrading and constant oversight to operate at full capacity, this creates cost and worry for the sources of such software.


On the other hand, Low Code software are very hard to cater specifically to an organization’s specific needs and often impossible to add on, migrate or change. This has driven many experienced software developers away from these platforms.


Big Technology companies have not been a stranger to these issues; organizations like Out Systems have revolutionized the way Low Code platforms work by allowing them to have flexibility in their build and properly managing their data. However, Low Code platforms still have a way to go before they are fully accepted as a viable solution for Enterprise Software Development. Read More An Introduction to Low-Code Development Platforms

Microsoft Azure: Service levels to accommodate your needs

Azure is a cloud computing environment that has grown in size and demand over the time, it was first released in 2010 under the name Windows Azure. Later, in 2014, it was renamed to Microsoft Azure. It has a robust, web browser based dashboard that will let you administer all of your cloud resources as well as an extension of PowerShell cmdlets (command line executables) to facilitate resource management and DevOps tasks. It offers multi-platform solutions and different service levels that will accommodate the needs of most companies in a pay-as-you-go schema, moving from Capital Expenditure (CapEx) to Operation Expenditure (OpEx). Read More Microsoft Azure: Service levels to accommodate your needs