#realy #devstr #progressreport
not really a big thing, just been busy refactoring the HTTP API so that it's not tightly coupled with the relay server library, separating the websocket stuff from the http stuff
now at v1.14.0 to signify that it's been refactored, i unified the huma API registration into a single operations type which means i don't have to touch the server code to add new http methods
also in other news, i have found that i can't get more than one more year of realy.lol so i've migrated the repository to refer to https://realy.mleku.dev , set up the vanity redirect for the new, the old code will still find its actual hosting on github just fine but once you have it and check out the latest on the `dev` branch it will be all pointed to https://realy.mleku.dev
same name, different DNS... and i've extended the mleku.dev, which i also use for my email and some general things, to expire in 2029 so i won't have to think about that for some time
now, not sure what i should do next, i just had wanted to make the http api more tidy so making an interface and popping all the http methods into one registration makes things a lot neater
ah yes, i need to start building a test rig for this thing, and probably it will be much like mikedilger's thing but will also test the http API
so, back to the fiat mine i guess... the project i'm working on is getting close to MVP, practically there, just a bit of fighting with the openapi client code generator for new methods that are needed for the spider's efficient fetching of updated data
the refactoring i did, it would be nice if an AI could do it for me, it was fairly tedious, a lot of careful reading, building up an abstraction to isolate the HTTP API from the server so it could use services of the server without creating a circular dependency, and then simply changing all of the http methods to be based on the root type
it's stuff that could probably be automated in a general tool quite easily but then at the same time, i just kinda bumbled through as i was still learning how to use https://huma.rocks and made lots of separate types that needed separate registration
now the http api is fully separated, it makes me think that probably at some point i can refactor the websocket API also to be isolated from the main relay implementation, but there's a lot of moving parts to deal with, the reason for wanting to do this is to enable a deployment that is HTTP only, where currently at best it would be possible to merely disable the HTTP API
honestly, i consider nip-01 style websocket API to be legacy, and will eventually be deprecated, and i know a lot of the smarter guys in nostr dev will think that's impossible but they don't have a full client and middleware stack building up that has a big benefit in simplification by switching over to a modular API stack instead of the mess that it is right now, and not only that, once there is a few realys out in the wild serving stuff that can optionally have http API service, the reduction of application complexity by being able to just leave out the whole nip-01 websockets lunacy will facilitate faster ramping up to building new application types, which currently means quite a burden of complexity
imo, nip-01 websocket API is the biggest obstacle to wide nostr deployment and adoption
the harder it is, and the more unstable parts are required, the less quickly new devs will be able to come and join the party, that's my key goal
Showing page 1 of
1 pages
