Home > Mobile >  What is the best architecture for a web-app communicating with a gRPC service?
What is the best architecture for a web-app communicating with a gRPC service?

Time:01-04

I have built a website with chess.js and java chess libraries that communicates with a custom c chess engine via gRPC with python. I am new to web dev and especially gRPC, so I am not sure on the architecture I should be going for when it comes to hosting.

My questions are below:

  • Do the website and gRPC service need to be hosted on separate server instances and connected via API?

    • Everything right now is hosted locally and I use two ports as it is right now (5000 for the website and 8080 for the server). If the site and server aren't separate, is this how they will communicate to each other on a single server (one local port)?
  • I am using this website just for a showcase of my portfolio for job searching, so I am looking for free/cheap hosting that also provides a decent RAM availability since the c chess engine is fairly computationally intense. Does anyone have any suggestions for what hosting service I should use for this?

    • I was considering a free hosting for the website and then a cheap dedicated server for the service (if the two should be separate). Is this a bad idea?

Taking all tips and tricks that anyone has to offer. Again, totally novice to web dev, hosting, servers, etc.

CodePudding user response:

NOTE This is an architecture rather than a programming question and discouraged on stack overflow.

The website and gRPC service may be hosted on the same server (as you're doing locally). You have the flexibility in running both processes (website and gRPC service) on a single more powerful host or separately on two hosts.

NOTE Although most often gRPC communicates over TCP sockets, it is possible to use UNIX sockets and even buffered memory too.

If you run both processes on a single host, you will want to consider connecting the website to the gRPC service via localhost (127.0.0.1 or the loopback device). Using localhost, network traffic doesn't leave the host.

If you run both processes on different hosts, traffic must travel across a network. This is slower and will likely incur charges when hosted.

You will want to decide whether the gRPC service should be exposed to any network traffic other than your website. In many cases, a gRPC service is used to provide an API to facilitate integration by 3rd-parties. If you definitely don't want the gRPC service accessed by other things, then you'll want to ensure either that it's bound to localhost (see above; and thereby inaccessible to anything other than other processes e.g. your website on the host) or firewalled such that only the website is permitted to send traffic to it.

You can find cheap hosting of virtual machines (VMs) and you'll likely want to consider hosting both processes on a single VM, ensure that you constrain the resources that you pay for and that you secure traffic (as above).

You may wish to consider containerizing the application. In this case, while it's possible to run both processes in a single container, this is considered not good practice. You should thus consider 2 containers (website and gRPC server). Many hosting|cloud platforms provide container hosting and this is generally easier than managing VMs (since you don't need to patch|update the OS and any dependencies). If you can find a platform that accepts a Docker Compose describing or a Kubernetes Deployment in which you describe both your services and how they interact such that the gRPC service is only accessible to the website, that could be ideal.

  •  Tags:  
  • Related