I create an application for ordering and delivering products from supermarkets. After making an order and processing it by the store, it is necessary that this order be taken by the nearest driver. In this case, the customer must see in real time the status of his order and the location of the driver.

I plan to divide the logic into a real-time server (RTS) and a business logic server. (WLAN)

  • The tasks of the WLAN will include: authorization of users and drivers (JWT tokens), receiving and processing orders, the payment system.
  • RTS will be used to monitor the locations of all drivers and create a connection on web sockets. The driver will have to constantly send his location from the GPS to be online

Communication RTS-BLS will occur using Redis pub / sub. In this case, part of the order data and driver information will be copied from MongoDB and stored in Redis. Thus, the information will be publicly available for all RTS servers (if I expand horizontally the architecture). The search for the nearest driver to the order was originally planned through MongoDB Geosearch, but then we would have to constantly write down driver locations in MongoDB - which means a lot of calls to the database. Therefore, I want to implement a search for the nearest entity through Redis.

  • WLAN uses Node.js + Express + Mongo

  • RTS uses Socket.io

    Question:

    1. Did I design the application architecture correctly?
    2. How to implement driver authorization on the RTS, if all the logic for obtaining and creating tokens on the WLAN.
    3. Access tokens may become obsolete with time, but the driver may still be connected to the RTS server, do I need to disconnect the connection and ask the driver to login again on the WLAN and send me a new token?
    4. Which geo search will be faster using MongoDB or Redis?
  • one
    1. the architecture of the application is not chosen, but the design is 2. everything is correct, authorization is via your WLAN, then you can store the key (token) value (user object) in a radish or memokesh (I advise memokesh, the performance is better, single-flow radishes), and send a token header via RTS (for example, in socket.io there is an extraHeaders parameter) 3. no need, just to refresh the token 4. rephrase the question - overthesanity
  • @overthesanity my radish survey showed that it is not possible to create separate collections (by analogy with Mongo) for different entities (separate token - driver and single orderId - driverId), there is support only for a predetermined number of databases. Should this not be an obstacle in choosing radishes as a repository for drivers on the RTS and using Mongo for this purpose? - ZulusK
  • nobody will answer the first question (which you paraphrase here), besides, what you have described, for example, communication with RTS-bls will occur through radishes - this is not a design, but a solution to a specific problem. Regarding a geo-search, if you have a lot of relations (relations) between tables - mongodb is not very suitable for this (like radishes, of course), use some kind of relational database, the same postgresql - overthesanity

0