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.
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:
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.