3

I'm moving from REST APIs to gRpc but having a hard time figuring out how to structure my logic.

The basic layout of my solution is having a business layer/API and a few different front-ends (Windows app, console app, Web app, etc).

I would like to have each of my front-ends simply be able to connect to my network using API calls so each of them don't have to understand and recreate the logic for connecting, sending messages, etc. but I feel like I shouldn't be tightly coupling gRpc into my business logic layer.

Is there a best practice or design pattern I should follow here?

user3953989
  • 218
  • 1
  • 7
  • 1
    `Is there a best practice or design pattern I should follow here?` Have your read Clean Architecture of R.C Martin? It might help you to understand why we never should bind the business with technical details. The more agnostic to these, the easier to adopt one or another architectural style, IPC protocol, devices, etc. – Laiv Mar 03 '19 at 22:36

2 Answers2

3

Use gRPC.

Systems are supposed to be specialised. Use what works for you and your system components.

  • Don't plan for a future that might never come - Many thought it would be important to have an ORM that can be switched between databases, but complicates things unnecessarily. In this case
  • Systems are easier to change than many people let on.
  • Systems are rebuilt every 10 years anyway. You might have a text-book beautiful "decoupled" business-layer, only to find that no one wants to code in node.js anymore but want Golang.
  • Popular General-purpose systems/tools/protocols are not "coupling". Using HTTP is not really "coupling" it's the thing that gives you a wide range of interoperatibility. gRPC is the same, if you believe in it. HTTP will become obsolete eventually (replaced by HTTP3), gRPC will be obsolete eventually. That's not your problem today.

Many others are using gRPC in their systems with success (like the Firebase DB protocol).

(I also assume you have worked with gRPC, or have at least prototyped with it before choosing it across your system architecture. Can your team debug with it? If not, that might be a reason to use something totally different instead and not have gRPC at all)

Kind Contributor
  • 802
  • 4
  • 12
0

What we've ended up doing is maintain a thin wrapper layer that makes gRPC look more like a conventional "invisible" RPC layer. gRPC does not do its own marshalling/demarshalling for function calls, it sends and receives messages.

Ours is done by hand, but if you have a lot of API it might be best to do it by code generation.

pjc50
  • 10,595
  • 1
  • 26
  • 29