Despite the fact that I abandon projects the way gamers abandon their “vote with your wallet” stances on controversies, I do maintain a high level of interest in the themes of my projects across the span of years. I occasionally return to my space-trading game in one form or another, and I frequently return to my TTRPG “not-a-VTT” content management platform affectionately known as “Adventure Outliner”.

If you are looking for a way to kill time and to avoid work, check out my original posts on this project here and here. Both are technically oriented and you won’t learn a damn thing worth knowing, but when you wake up you’ll have lost about 10 minutes of your time and will be worse off for it.

This time, I’m in a totally different space regarding how AO is going to work. Gone is Firebase and Firestore. I am a bit sad because I had forgotten how much work I had done to get those two platforms integrated. I’m also not sad because I was always fearful that should I get this project completed, I’d be enticed to release it to the public, which would hopefully result in traffic, which in turn would start the meter running on my Fire[x] bandwidth leading up to an actual bill in my inbox.

Instead, I have taken a new approach: The home-grown API method.

Oh Node. Not Again

I still like React, despite some sentiment on the Internet that I’ve seen from the self-styled Gatekeepers of Why Your Opinions Are Shit. One shortcoming, though, is that, as a front-end-centric platform, React has no native way of getting data. I used to use C# for a lot of projects, and that platform has various data-access systems built that allow the front end to get data from a store through the C# middle layer, all in one package. React can’t do that; it needs to “call out” to somewhere, somehow, to request data, receive data, and cache that data in some way. Because of this, I have started leaning heavily on Node, the Javascript-powered server.

Node is a weird beast. It’s not a “server” in what a layman might understand a server to be, either a physical machine, or a perpetually accessible bit of software laying around in the background until something contacts it. Node is only active when it has source-code to run which, in this case, is usually a Javascript file or files. While this process is running, the server becomes available to “do stuff” like process data or listen for connections.

One such package available for Node is called ExpressJS. This creates an app that functions as a not-quite-entirely-bare-metal web server. It can accept HTTP/S connections on a specified port, read request payloads and return responses. In between, it can make decisions based on inbound parameters (query-string, headers, form bodies, etc.) or access back-end data stores. With additional tinkering or some other off-the-shelf packages, it can serve entire websites to provide an almost all-in-one solution for your web presence needs.

For me, though, Express and Node will be acting as an API server. An API server exposes “endpoints” which can be called just like normal web addresses — https://my.server.com/some/path/to/endpoint — but rather than returning HTML text intended to be rendered in a browser window, the endpoint returns a data structure, usually JSON. I use custom routers and middleware to do things like process JWT authentication, accept user registration data, and return lists of records stored in a back-end data store like MSSQL, MySQL, PostgreSQL, or other.

Using functions such as fetch or libraries like Axios, React can call an API endpoint and receive data in response. The Node/Express server will apply business rules, accept parameters, and transform results before returning that data to the React front-end. While this set-up results in three independent parts (UI, Server, Data Store), it makes the system very flexible as I could swap out the data store, replace the API server, or change the front end without too much revision to the other parts of the pipeline.

Working Smarter AND Harder

Right now, I’m focused entirely on the API aspect of the project. I’ve been down the Adventure Outliner road several times at this point, and kind of know what I want it to do. The how to do it is changing, starting with the most basic stuff I need to make it work — not necessarily work well.

This means I have plans for scenes, modules, and campaigns, the three levels of organization I plan on using. The Node/MSSQL system uses a series of stored procedures, data processors, and web traffic routers to add, edit, and return the data that makes up these organizational groups. Whereas before I would probably have tried to flawlessly model the entire system, I have learned that such a task leads to madness and a shelving of the project. With smaller, leaner, more targeted tasks and implementations that are expanded over time, I can actually see myself make progress which if you know me is super critical to maintaining an interest in a project.

Based on all of this, you can expect another series of technically minded posts covering some of the approaches I’m taking. While I realize that my development/project posts probably don’t get a lot of traction, they’re an excuse to post more frequently, so neeeehhh.