I will need a GUI of sorts for the user to begin using bluetooth input for something.

Wails allows you to build a desktop app using modern frontend web technologies including, but not limited to React. Wails also uses Vite under the hood, which is exciting for someone who has historically used create-react-app. It hardly matters to me in this case if somewhere far abstracted from me is: webpack, rollup, or esbuild, but using a cutting edge tool like this is too exciting to pass up.

Well, it's not pretty (yet), and it's not robust (yet), but we've the beginnings of a GUI to work with. To this point, I've used the Wails tool to spin up a Vite-React project, and for no particular reason I am styling using Tailwind. Ultimately, I'll just need a few neat tables, a diagram or two, and a menu of sorts. Using the Bluetooth Assigned Numbers documentation, I should be able to infer the names of the non-custom services and characteristics as well.

I've opted for a Vite-React project, so the frontend updates are lightning fast. When updating Go files, it does have to perform a full rebuild as it creates JS bindings for your Go functions and builds a new binary. The creator of this tool seems reasonably dedicated to keeping the single file binary dream alive, and from what I've seen, v3 will not disappoint.

The Go functions are called in JS exactly as they are "exported". In JS, the Go function's return shows up as a promise - easy enough. I've opted to wrap all of my Go functions on the JS side so I can add some JS logic and clean up the bigger files.

An interesting roadblock..

The official Bluetooth documentation is written well enough.. however, there are so many different types of data, it quickly becomes clear this would require an unreasonable amount of time and effort to support all devices. In the current build, I have borrowed the bluetooth-numbers-database data from Nordic Semiconductor's github. I have this list hard-coded in my project as follows, and it is great for displaying service/characteristic names of common devices.

This proves only so useful, as each and every characteristic has a unique number of bits it sends, representing something specific, as defined in the bluetooth documents. While I plan to allow users to perceive the data in their own way and map it accordingly, there must still be a solid foundation within the software on which to provide the user some options.

As much as I would love to map the frequency at which you ignore Jeff Bezos' phone calls to some mechanic in a game, it just is not going to happen, not dynamically anyway.

The solution

--This project currently on the back-burner. Left off in the early stages of writing the Windows driver--