search

lorenzodonini / ocpp-go

Open Charge Point Protocol implementation in Go
MIT License
262 stars 125 forks source link

scalabillity suggestion question #59

Open meriororen opened 3 years ago

meriororen commented 3 years ago

Hi,

Thanks for developing this library, it's been very useful! I have a question or rather asking for suggestion. Right now I'm using this library directly with backend server that serves REST API requests, So for example, we just call "RemoteStartTransaction" request in this library directly when a call to a REST API come. The problem with this approach is it's not scalable, since the websocket connection will be cached inside the memory in one executable, so if we want to scale the server to become multiple instances, some charge points will not be available to every instsance of the server.

The solution to this could be many:

  1. To separate REST API server and websocket (this library's) server, one big websocket server will serve all websocket chargepoint connection, and then the REST API server can be replicated, the communication between websocket server and REST API server will be a pubsub broker like RabbitMQ.
  2. To cache OCPP command request queues separately in another in-memory cache such as redis, this request queue will be common to all server instances. So regardless which instance of server a CP is connected to, a request will still be there in memory when the server is down, and goes back up.

I wonder which approach is more suitable and simpler to implement. And I wonder if this is a problem to any of you implementers out there.

xBlaz3kx commented 2 years ago

@meriororen I've used the first approach, since it makes more sense for our use case. You can separately scale both the REST API and the OCPP service based on the traffic on each service. However, you just wrap/forward OCPP messages to the REST API, which is rather time consuming and pointless, but at the same time allows for appending custom data.