There isn't a universal one. A fun fact is that Activity pub, the protocol that lets these applications communicate on the backend, also has a front-end spec for this exact purpose, but no one has implemented it.
I actually disagree, because I've both seen it everywhere and I also work mainly in dotnet, and when I've talked to people about option and result types, the first inclination is to have a .Value, but that defeats the purpose. I've done quite a few code reviews where I was essentially saying "you know this will throw, right? Use .Match or .Map instead".
I think the imperative programming backgrounds encourage this line of thinking, since one of the first questions I've gotten is "how do I get the value out of an Option? I'm 100% sure it's there." And often, surprise, it wasn't.
I feel like I've seen an insane number of error messages in various apps and websites around the unwrap method.
But this is on a result type, right? I'd figure the point would be that you would match on it and that the unwrap itself, which if my assumptions are correct, is more like get value or throw, should either not exist or take a default value. You shouldn't be able to directly get the value of a monad.
Based on old memories since I've been working in mongo lately, after making the UDT on the db side, you make a data table that has the same name, namespace (ie dbo/public), and the same schema as the UDT (better if that could be generated) and populate it in code. Then you execute the db query with the UDT type as a parameter.
This is better for a few reasons, including not building up a string, but also having the same text means that each query didn't need to be re-parsed and can reuse execution plans. If the query text isn't an exact match, it gets that whole pipeline each time.
It sounds like you're diving right in. If you go that route, one thing I found was that Ceph wants to work with while drives only, not partitions. I switched to using longhorn so I could take advantage of all of my storage without throwing any away
Id say don't go down the distributed software route just yet. An option is to keep the NAS and set up a new computer with your router or whatever handling dns to it for services. You should be able to use NAS storage over the network. It'll be slower, but let's say you put your database on the big one, then it shouldn't be so bad since you'll just make database calls to it.
There are a lot of options. I'm currently learning kubernetes and all that stuff is a big learning curve, so avoid that stuff.
My thoughts: you can do some simple dns load balancing between the two servers at whatever level is handling that. Set up a database on the storage server and let the new computer communicate to it over the network.
Those are the built in templates, what you add is your markdown for your post. You're not actually adding that. It isn't quite click to save, but it's similar. Write freely may be the closest bet for free
There isn't a universal one. A fun fact is that Activity pub, the protocol that lets these applications communicate on the backend, also has a front-end spec for this exact purpose, but no one has implemented it.