I started working on a Channels service that’s going to be used for location reporting. This is a secondary service to a main backend (working with websockets in Java is horrible). I’ve written the business logic of the service but I’m having trouble deciding how to structure my channel(s?). The business logic is as follows:
I have a Location struct which contains the driver_id, restaurant_id, coordinates and timestamp. Only coordinates and restaurant_id can be updated (rest_id changes for every order). This is being used with a GenServer with ets, so every driver gets his own process. The GS is spawned by his Supervisor. I then wrote some helper functions that basically list the state of all the children of the Supervisor and then the same but filtering by restaurant_id. The main idea is that admins can see ALL drivers, but restaurants can only see drivers currently assigned to them.
This is where I get confused and I worry that the friction I’m experiencing while implementing this may not be (only) because of my inexperience with Channels but that the web part of the service is incorrectly designed. What first ocurred to me is having 3 sockets and their respective endpoints, and 3 channels. One for each driver, restaurant and admins.
When a driver connects to “drivers:#{driver_id}”, it creates a supervised GS and then starts to send its location data. The admin connects to “admin:locations” and subscribes(?) to all the driver ids so it can push updates to the clients. The restaurant part was supposed to be similar but the data send would be filtered based on the id.
I’ve only implemented the driver channel. The admin channel is partially “done” and I haven’t even started the third one.
I have a strong feeling that I’m overcomplicating things or at least doing something wrong somewhere because I’m having a harder time than usual implementing it. Should I only have one topic and then have the client subscribe to one (driver) or many (admin and restaurant)? Is there some other option I’m not considering?
