Esee How does it work?
Esee Esee is an extremely easy way to communicate with people nearby you. You can have video chats with people nearby, but first you have 10 seconds to prove yourself worthy!
How does it work? So you open the app and you are into action right away:
The moment you open the app you are already being matched with people nearby you. If the system finds somebody then you have ten seconds to impress that person. If you don’t accept that person or that person doesn’t accept you then you get back into matching. The time is shown by a circular clock.
Architecture: Frontend: 1. iOS app built natively on swift. a. Obtaining location from the device and sending it to the server through a socket channel.
b. Sending video through Twilio’s Webrtc Swift library. Backend: 1. Python process: a. Using a protocol implementation of the library ‘twisted’ in order to establish a duplex socket channel. b. Using persistent storage through redis. c. Using geolocation libraries in order to obtain distances. d. Connecting to Twilio in order to obtain tokens and identities for the webrtc channel. 2. Redis: a. Used in order to store information about the users. b. Running as a daemon on the server. Notes: 1. A reimplementation of the server using Node’s nonblocking architecture may be more convenient for the nature of this problem. 2. Swift handling of asynchronous events is really messy because it’s hard to debug in which thread an instruction is executing. Sometimes some events are not called in the right order. I have some ideas about using futures but I didn’t implement them. Scalability: 1. The current system could be made scalable by a more proper implementation of the server using node instead of python, and a future/premise system in Swift. Both are feasible tasks for me.
How does it work? So you open the app and you are into action right away:
The moment you open the app you are already being matched with people nearby you. If the system finds somebody then you have ten seconds to impress that person. If you don’t accept that person or that person doesn’t accept you then you get back into matching. The time is shown by a circular clock.
Architecture: Frontend: 1. iOS app built natively on swift. a. Obtaining location from the device and sending it to the server through a socket channel.
b. Sending video through Twilio’s Webrtc Swift library. Backend: 1. Python process: a. Using a protocol implementation of the library ‘twisted’ in order to establish a duplex socket channel. b. Using persistent storage through redis. c. Using geolocation libraries in order to obtain distances. d. Connecting to Twilio in order to obtain tokens and identities for the webrtc channel. 2. Redis: a. Used in order to store information about the users. b. Running as a daemon on the server. Notes: 1. A reimplementation of the server using Node’s nonblocking architecture may be more convenient for the nature of this problem. 2. Swift handling of asynchronous events is really messy because it’s hard to debug in which thread an instruction is executing. Sometimes some events are not called in the right order. I have some ideas about using futures but I didn’t implement them. Scalability: 1. The current system could be made scalable by a more proper implementation of the server using node instead of python, and a future/premise system in Swift. Both are feasible tasks for me.
