Suggestions

[kajoseph]

In server.js:

• You don't need socket.io or http.
  • You can just do app.listen instead of server.listen. You may want to use the http.createServer() if you're wanting to add on some certificate stuff, but obviously you're not doing that here.
  • I would put all of your server data APIs behind it's own route, like /api and then serve those routes using express instead of socket.io and then from the front end just use fetch to call the endpoints.
• Serving a node module is...one way to do it ;) Definitely not conventional. Regardless, you don't need socket.io anyway, as I mentioned above.
• It's common to have the starting file be something very broad like index.js or index.html. server.js is a good file name for the backend, but for the frontend it's not very apparent which html page I should start with.
• Oops! I accidentally committed the connection string to a mongodb instance being hosted in Atlas. That's a good reason to move that sort of data to a config file that's gitignore'd or environment variables :)

[MicahMaphet]

That makes since for sending data from the client to the server. But it appears that using app has a loss of functionality. The advantage socket.io has is it can send data to all of the clients at once without refreshing or creating some kind of loop for listening to requests. The client does not have app.listen (unless I send a node module...) so it can get the data whenever the server gives it. I need to get a message from client to server and send it back to all of the clients, which requires some kind of arbitrary data receiving (such as app.listen or socket.on) on the client side. The only way I know to get data on client side without socket.on is fetch which only can get the data once, unless I do some kind of loop... How do I do that without socket.io?

[kajoseph]

ah ok, I was thinking you were just wanting to post messages to the server. If you're wanting to have 2 clients that are messaging each other through the server (or otherwise expecting to receive messages from the server), there are main ways of doing it:

1. Websockets (I believe the npm package for it is just called websocket or maybe ws)
2. As you alluded to, having a loop that polls for new messages. In fact, this is the way facebook does their notifications (or at least used to). They do/did what's called a long poll where there's a forever loop that calls an API and the API just doesn't respond until there's a notification. The request times out after 30s or so and the loop continues.