I'm new on nostr and have been reading some code on Github to find useful implementations, and also reached the Nostr Design Guide for enlightenment.
As a developer for a couple years, I'm used to the common scheme back+front, using frameworks for that, like Flask, Rails, Spring etc. And, what is called a "dumb" client just consuming data from a backend API, or gateway, or whatever you may call it.
Then, I've seen that most nostr clients are built just using JS with modern frameworks, and to be honest this looks like an obvious and straightforward approach. Although not much mature, some clients are being well structured and organized using recent tech stacks and this is good enough for a while, I guess.
My idea would be make something more focused on a backend, serving as the gateway/aggregator between the client and the nostr network. This would connect and pool the relays, and handle everything regarding logic and content aggregation. Also, it could serve for caching and queueing. I also have questions about storing the user keys in the backend, since I didn't think much in this case.
Is this approach "too much" or can it present any challenge beforehand? I'd like to know your ideas and opinions, sharing previous experiences if you have any. I appreciate your time for this!
Best, Tom
Hey Tom there are many clients that are beginning to take this approach and provide a kind of middleware without using relays on the client directly. Primal is such an example.
reply
Hey @k00b thanks for you reply, interesting that Primal uses something like that! I'll keep analyzing the possible solutions and see what I can do meanwhile, cheers!
reply