> Why don’t we see numerous both-side frameworks which make http (rest, ws, etc) completely transparent?
I think you want RPC. There are many solutions. Most popular are corporate-blessed. Not sure if anyone likes them. They were always kind of pain to use. But that might have been due to mismatch between actual network requests that are intrinsically asyc and can fail any time for whatever reason and function calls that are quick and always succeed (except for specific scenarios).
As more desktop programmers get familiar with async and that most async do not necessarily need to succeed maybe it's time to revisit the idea of RPC in open source setting.
I'm a bit afraid though that in current climate of every language getting 'await' keyword people come back to mindset of 'Yeah, I'll wait. Fail? What fail?'
Yeah, I omitted error handling for clarity - ofc, edit.upload and edit.save/cancel may throw from await (also invalidating the entire `edit` automagically if unhandled, thus leaving no garbage anywhere). HN comments are just not suitable to define everything in detail.
RPC is a known thing, but I find it too low-level, much like rest/post api. As at the end of the day all of our data is basically a consistent collection of linked objects, and it would be great to operate on objects in a transaction (‘edit’), not on function calls. When you’re in a network-wide transaction, time and errors are no big deal. Rollback, rinse, repeat.
My RPC right now is:
// front
try {
id = await rpc(‘save’, {obj})
}
// back
app.rpc(‘save’, async (task, p) => {
id = await do_save(p.obj) // may throw
task.ok(id)
})
It’s not very clever or ‘amazing’.
>in current climate of every language getting 'await' keyword people come back to mindset of 'Yeah, I'll wait. Fail? What fail?'
I don’t find it problematic, honestly. People will always misunderstand and misuse. It’s business, we need to build fast, not to care how good someone understands basic programming.
I think you want RPC. There are many solutions. Most popular are corporate-blessed. Not sure if anyone likes them. They were always kind of pain to use. But that might have been due to mismatch between actual network requests that are intrinsically asyc and can fail any time for whatever reason and function calls that are quick and always succeed (except for specific scenarios).
As more desktop programmers get familiar with async and that most async do not necessarily need to succeed maybe it's time to revisit the idea of RPC in open source setting.
I'm a bit afraid though that in current climate of every language getting 'await' keyword people come back to mindset of 'Yeah, I'll wait. Fail? What fail?'