用于Netty和socket.io的图像服务器

Question

I'm looking for a solution for the following problem in my architecture:

I have a rich front-end application (React, RxJS, socket.io etc) and a web service layer written on top of netty-socketio, which I currently run just as Netty app. The idea is that the server acts as an API layer that any client implementing socket.io protocol could consume, my front-end application being one of them. I could host it anywhere really, probably a cdn.

The problem I've ran into is file, more specifically image handling. The classic use-case is uploading user avatars. My plain socket.io protocol doesn't support it, so I've come up with a couple of theoretical solutions:

1. Upload images as binary through the socket.io API, store images on the server's file system, access them as binaries as well. My problem with this one is the serialization/deserialization I'd have to do, and it seems error prone with different file extensions and such.

2. Implement an HTTP parser in Netty, like this example , run it in the same instance on a different port. I've tested this and it works, but it's really low level and I'm no expert in Netty.

3. Create a separate HTTP file server, maybe using servlets and use it to store and reference images, have the front-end upload to this directly and just send a reference to the socket.io API to persist in the DB. The thing I'm not sure on is the fact that this way the API basically expects the UI-s to handle their own image storage and just report references, and that seems unsafe and uncontrollable.

4. Use a CDN instead for the behavior described in (3). This would be a nice production-ready solution but maybe overkill in my non-production system.

Note, in cases (3) and (4) I could host the front-end in the same place, right now I'm using a local node.js http-server for that.

Any advice, opinion, solution I didn't consider?

Answer 1

For knowledge sharing purposes I'll answer my question. I went with option two because I didn't want to separate the image storing logic from the rest of the application. Image upload is now a 2-stage process: the user initiates a HTTP POST request with the image body, to the same ip, on a different port. A Netty handler catches the message, and parses the HTTP POST, much like the referenced example. The image is then stored in memory as a byte buffer (for a limited amount of time), and a unique UUID is returned in the HTTP response. After this, it's the client's responsability to call the relevant API through the websocket connection, send the relevant text data and include the aforementioned UUID as a reference to the uploaded data. The socket handler than validates this request, reads the byte buffer based on the hash from temporary store, writes it to disk. The nice thing about this is the temporary buffer, so requests can be properly validated before writing to disk.