Forem: Sanket Naik

Trying To Solve The Confusion of Choice Between gRPC vs REST🕵

Sanket Naik — Sat, 22 Jul 2023 13:19:28 +0000

Introduction:

Recently I came across the discussion of choosing between gRPC or REST Service. So thought to summarize my research and opinion in a form of blog post, so that it will be helpful for one who are interested in this topic.

I saw there is some confusion among us as a Developer to choose one over another. So, let's get some dive into this topic. Hope this will give you some insights to give a fresh thought.

There is a lot to discuss about this topic. However, I have tried to keep this blog as concise as possible.

RPC vs REST:📢

Yes, it's not a spell mistake!
Before diving into the comparison, I think it is important to go through some fundamental difference between RPC and REST.

RPC:
I think RPC was there even before REST. REST came into picture in after evolving era of internet over HTTP protocol.
PC APIs allows developers to call remote functions in external servers as if they were local to their software.(action oriented in short)

Examples of RPC:
A client app “calling a remote API method” to perform “actions” like processing payment, sending messages, or retrieving data.

REST:
Where in “REpresentational State Transfer” is an architectural style that focuses on CRUD(Get/Post/Put/Delete) “specifically for the Resource” (e.g., books, users) (Resource oriented in short)

Example of REST:
A mobile app fetching product information by making an HTTP GET request to a RESTful API endpoint, enabling CRUD operations (Create, Read, Update, Delete) on resources like user profiles, posts, or photos.

Then Why REST replaced RPC?

REST didn’t replace RPC, but it grown as a popular alternative for building web services and APIs for various reasons. Both REST and RPC are different architectural styles with their own strengths and use cases.

gRPC:📢

Originally, the motivation for Google behind gRPC was to connect the large number of microservices running on same or different data centers.
As the payload size of gRPC vs REST is much optimized in size, it is somewhere 5 to 8 times faster than REST data transferred over network.
So they just picked the power of HTTP/2 and protobuff on top of RPC. ref

One of the key feature of gRPC is protobuf .proto file(nothing but just a contract for me between two communicator code components)
This file and protobuff compiler is so mature, then it generates a direct client implementation using protoccompiler. ref

gRPC weaknesses:

Every technology comes with their own power and downside; hence it is important to focus on their use and Use cases.

Limited browser support: since gRPC uses HTTP/2 protocol, not all modern browsers support very well.
Not human-readable format of message: I read some articles heilighting this as weakness. But in my openion, why should we care about this ? as far as sender and reciver understands it very well, I dont see any problem with this.
Limited number of error codes: gRPC has less number of error codes if we compare with REST. ref

Challenge and Considerations When Using gRPC in Microservices

I think, it makes sense to use gRPC in microservice(internal layer) of architecture but carefully!
Why am I emphasizing on ‘carefully’? First let's see the problem referring below scenario,

Client (referring to a service caller) calls for an action to gRPC_service_1.
gRPC_service_1 service internally “maybe”(we don’t know as a caller) calling gRPC_service_2, and gRPC_service_2 might call other services internally.

But there is one challenge with this design!
What if, there is a strong business workflow involved/associated in this hole cycle and somehow gRPC_service_3 fails? As a result, it will cause some inconsistency within services, and gRPC_service_1 does not know which of the components failed in the chain (rather I would say failure in business workflow).

My Thoughts of using gRPC effectively in web API development✍

I am proposing above high-level architecture of where I think gRPC makes more sense, and why.
I considered below points while proposing this high-level architecture.

Most of the browsers doesn’t support HTTP/2 hence gRPC very well.
Architecture should be workable with both the scenario: a) if having strong business workflow, and hence better to decouple the modules b) if do not have strong business workflow and flow ok with failure in chain.
Architecture should be flexible enough for shifting to gRPC seamlessly from REST, without any change in internal modules.
Should be scalable over time.

Let's Architect,

Okay, some developers may be having some diabetes over these components. Be flexible enough to change any of the above modules based on your needs or Use case.

Web Interface Layer:
🔹Gateway Service:
If you are using this layer as your REST gateway service and your internal services are hidden from the external user, it's a big win to tackle the browser compatibility problem for WebUI clients.
Most of the Gateway services supports to configure Upstream as REST protocol and Downstream as gRPC and vice versa. By this way you do not need to worry about switching from gRPC to REST for your external clients without changing your internal structure. Isn’t it Great!!!

🔹BFF Service:
This is one of another Usecase where you make your view composition by using underlying core services.
Aggregating your logic using gRPC and sending back data to your clients as per your choice or protocol (e.g. REST/WebSocket) makes your decision flexible enough.

🔹Aggregator Service:
This service is very much similar to the BFF, but the core difference is, BFF is built with frontend needs in mind, and responsibility of Aggregator service is to summarize the data by contacting two or more services behind the scenes.

“Business Workflow?” block:
I am not sure; what term this block we should call to. You can suggest a better name, but you get the point!
This block is little bit tricky while implementation and taking decisions.

If there is no business workflow involved, then I think it's okay to have direct call to another service to retrieve data. You can use any resiliency framework internally though to deal with temporary service down delay.

But if, there is business workflow involved then you can consider messaging queue to make your flows/system decoupled and flexible enough in nature. Using messaging queue brings up its own power and strength though.

Okay, then shall I ‘move’ from REST to gRPC now?

The answer I would suggest: If you are starting a project/service newly (newly, I meant the reference is not exists yet anywhere), you can give a thought to have service as gRPC.
But there is no concrete reason that you must have it until and unless there is any need.

References for more detail📗

Efficient Way of Writing Controlled Global Exceptions in .NET Core🕵

Sanket Naik — Mon, 17 Jul 2023 14:02:15 +0000

Introduction 📢
Hey folks!!!
How are you all!!! Here I am with the new blog “Efficient Way of Writing Controlled Global Exceptions in.NET Core”.

In this exciting blog titled “Efficient Way of Writing Controlled Global Exceptions in.NET Core” I’ll share valuable insights on effectively managing exceptions in a controlled manner, resulting in a positive impact on your application. This article offers unique perspectives that you won’t find elsewhere. So, get ready to dive into some interesting learnings!

Make sure to pay attention to the specific use case I’ll discuss later in the article below.

Why you need custom loggings🤔
There are numerous reasons why you may desire these features, but for the sake of this article’s focus and objective, I won’t delve into all of them here. However, I will provide a list of some common reasons:

Customizing logging behavior.
Tracking additional contextual information.
Logging to multiple destinations (e.g., displaying informational logs in the console while storing only failed requests in the LoggingDB).
Improving logging readability for future analysis.
Integrating and customizing behavior for multiple destinations (e.g., storing informational logs in different databases and error logs in separate databases).
Presenting a well-formatted error structure to API users or consumers.

Any other way to write global level logs other than Middleware way?
Yes, you can implement IExceptionFilter. However, it's essential to understand the fundamental difference between IExceptionFilter and CustomExceptionHandlerMiddlewarein terms of their execution within the request pipeline. Perhaps I will write another article that provides a detailed comparison and helps you choose between the two.

For now, the diagram below will give you a general understanding of when each component comes into play:

‘UseCase’ for the approach that I use✍:
I have multiple microservices as a part of my big codebase. These multiple web API services will have almost same code for GlobalExceptionHandlerMiddleware, which basically handles unhandled exceptions at the request level.

However, I need to be consistent in terms of standard HTTP response codes so that I don’t violate DRY principles.

For the most commonly encountered exceptions, the best practices follow the following HTTP codes.

Let's architect this scenario into code 🏹:
Yah! so, the idea is to abstract the most used exceptions along with their http code in a separate shared library.
Below, we have Three exception types in our shared library DomainException,ApplicationExceptionand InfrastructureException.

And the consumers will inherit from below Three base exceptions.

Write DomainException base

[Serializable]
public abstract class DomainException: Exception {
    protected DomainException() {}

    protected DomainException(string message)
        : base(message) {}

    protected DomainException(string message, Exception exception)
        : base(message, exception) {}
}

Write ApplicationException base

[Serializable]
public class ApplicationException: Exception {
    protected ApplicationException() {}

    protected ApplicationException(string message)
        : base(message) {}

    protected ApplicationException(string message, Exception exception)
        : base(message, exception) {}
}

Write InfrastructureExceptionbase

    [Serializable]
    public class InfrastructureException: Exception {
        protected InfrastructureException() {}

        protected InfrastructureException(string message)
            : base(message) {}

        protected InfrastructureException(
            string message, Exception exception)
                : base(message, exception) {}
    }

Write Middleware implementation

// GlobalExceptionHandlerMiddleware.cs

public class GlobalExceptionHandlerMiddleware {
    public async Task InvokeAsync(HttpContext context) {
        try {
            await _next(context).ConfigureAwait(false);
        } catch (DomainException ex) {
            await HandleException(context, ex, HttpStatusCode.BadRequest);
        } catch (ApplicationException ex) {
            await HandleException(context, ex, HttpStatusCode.InternalServerError);
        } catch (InfrastructureException ex) {
            await HandleException(context, ex, HttpStatusCode.ServiceUnavailable);
        } catch (ArgumentException ex) {
            await HandleException(context, ex, HttpStatusCode.BadRequest);
        } catch (Exception ex) {
            await HandleException(context, ex, HttpStatusCode.InternalServerError);
        }
    }

    private async Task HandleException(HttpContext httpContext, Exception exception, HttpStatusCode statusCode, bool logRequestBody = true) {
        // Log into Infra/Console/File etc
        WriteResponse(httpContext, statusCode);
    }

    //Modify and return request context
    private async Task WriteResponse(HttpContext httpContext, HttpStatusCode statusCode) {
        httpContext.Response.ContentType = "application/json";
        httpContext.Response.StatusCode = (int) statusCode;

        var responseModel = new {
            ..........
        };
        await httpContext.Response.WriteAsync(
            JsonSerializer.Serialize(responseModel, _seralizeSetting),
            Encoding.UTF8);
    }
}

    //Expose an extension method from your shared library
    public static IApplicationBuilder UseGlobalExceptionHandling(
        this IApplicationBuilder app) {
        app.UseMiddleware<GlobalExceptionHandlerMiddleware>();
        return app;
    }

*Finally, Make sure your code line app.UseGlobalExceptionHandeling() as your first middleware in request pipeline.

Enjoy using Exceptions from consumer code:

Summary📚
I’m excited to share this blog titled “Efficient Way of Writing Controlled Global Exceptions in .NET Core”! In this article, I’ll provide valuable insights on how you can effectively manage exceptions in a controlled manner, ensuring a positive impact on your application.

We saw below points:

We were onto mission on: valuable insights on how you can effectively manage exceptions in a controlled manner.
We saw the ‘why’ part of ‘need of custom logging’.
Then we saw the UseCase of above approach I had written.
We saw the HTTP codes for general types of exceptions.
Then we also went through the implementation idea and the actual hands-on code by making our hands dirty.
Above is just example in my perticular use case. You can have your own/different ExceptionsTypes that most suits in your context.🙌