Figuring out client/server stuff for my offchain-content tool

(image from Unsplash)

I've been working on learning and proof-of-concepting the various parts for the offchain content stub post tool I'm working on. Over the past few weeks I've been focusing on figuring out how to do client/server stuff in Node.js. The basic structure of the tool is that I'll have a server process running which interfaces to the chain to post stuff via the @offchaincontent account, and users will interface with that server via a web UI. The basic functionality will have a two-stage procedure: First, the user sends a URL to the server, the server queries the URL to find the <meta> tags that describe the content, the server then sends that info back to the user to confirm that's what they want posted. Second, the user confirms that's the post they want and the server posts the stub post with the social media preview to the blockchain for them.

So at first I thought I'd just need to respond to the basic web requests: first the user needs to see the UI page, then they send the intial query, then the followup confirmation post. The information from the server would just go back to the client with the responses. But then I remembered that there's a once-every-five-minutes limit on posting new posts to the blockchain, so it's not inconceivable that there might be a several minute wait before the confirmed result gets posted to the chain, and it didn't seem right to me to leave a request potentially hanging for several minutes. So I think I will need to have a queue in the server to manage the posts getting to the chain in an orderly way, but since the request confirmation will go when the request gets into the queue I need a different way to communicate back to the user about where their requests are in the queue. For that I'll maintain a socket connection so the UI page will just always display the current state of the queue as long as it's connected to the server.

Since I'm still learning how to do client/server stuff with Node.js I started with the socket stuff. I'm using Socket.io for that. For a while I got kind of annoyed at the documentation since the "Getting started" guide says it will show you how to use it by creating a "chat application" -- I grumbled and grumbled about how I didn't want to have to make a chat application, I wanted the most basic thing: a browser communicating with a web server! Once I stopped complaining and admitted I would just need to read through the docs provided rather than complaining about them writing the docs in a way I didn't like, I found the docs were just fine since what they meant by "a chat application" was "a website that lets users post messages into a group chat", which is just the sort of minimal thing I wanted to see. I figured out how to get messages going back and forth between javascript running in my browser and the Node.js server running on my local machine, so that ought to be fine for the queue display.

For responding to the web requests I had to decide whether I wanted to use the Express framework or not. A lot of online guides that teach Node.js stuff urge you to use Express since that's apparently the way the vast majority of Node.js web apps are done, but on the other hand I don't want to have to learn too many things simultaneously. Also, the last time I tried to figure out Node.js client/server stuff I followed a tutorial that used Express and barely any of it stuck in my head so I have some negative emotional associations. I decided that for right now it would make more sense to keep the number of variables to a minimum and not try to learn Express while I'm also trying to figure out other things, and just implement the web serving functionality without extra middleware. For what this tool needs I think that will be fine, I just need to deliver the HTML, CSS, and JS files for the client-side UI, and handle the two types of POST requests (the initial query and the confirmation). I've got that working in a proof-of-concept page, where the UI sends a URL to the server, the server looks up the meta tags, and responds back to the client with the info that will go into the blockchain stub post.

So I'm getting closer to having something that actually combines all the parts. My next step will be to implement data structures to track past and pending requests, and then actually process them and get the posts posted to the blockchain. I'll also need to figure out how to confirm the user is who they say they are (get the client to sign a transaction with the user's private key), and make sure to only post for people who have big enough votes that it makes sense to post something for them to vote on.