Context : I am currently task with building a software to support operators in a manufacturing plant. Due to the nature of the plant, the computers all have fairly weak processing power (given that they can't have any fans and the environment is already hot to begin with). The current "client" is in WinForms and there's really no way that's changing, so that already takes a toll on the performances. Therefore, as it is right now, most of the backend logic is done directly in the database, mainly through stored procedures. That used to be fine and dandy, but now the requirements have increased quite steeply and I have been asked to implement many features which, at least to the best of my knowledge, require a fair bit more processing power and interdepencency between the workstations. Amongst these features, there is :
- keeping track in real time of the manufacturing process
- allocate time spent on different task using a particular logic for each
- keeping track of products as well as their locations
- dynamically generate fabrication plans
Also, the heavy reliance on stored procedures to do everything makes for terrible DX and maintainability. With all this in mind, I think implementing a "local server API" of sort could be a great idea and could help in both maintaining the client application light as well as significantly improve the DX. Now, I have experience with WebAPIs (ReST mainly) but none with something of this sort (as in a purely local server, design mainly to offload the processing needs).
Question: Is the use of a local server API in this context appropriate ? And, if so, what are the most suited approach both in terms of protocols (HTTP, gRPC, WCF, etc.) as well as "general structure" (i.e. should the client keep communicating directly with the DB for simple requests ? I think that doing so would needlessly complicate the system but at the same time I worry that having all requests serialize and then deserialize through the server could cause performance issues) ?
