4 ms·
- This is one big advantage for using Rust for both backend and frontend, in that you never have to worry about your types getting out of sync. One thing to be
by rictic 5y ago
- This is one big advantage for using Rust for both backend and frontend, in that you never have to worry about your types getting out of sync.
One thing to be aware of here, you may have users with stale clients after deploying an update to the server. e.g. picture someone who leaves a tab open for a week and then comes back to it and interacts with your app some more without refreshing.
Text based serializations will tend to be more forgiving of changes in the RPC schema (in the sense of erroring out when required fields are missing), while more compact serializations are more likely to incorrectly decode a message when they should fail.
- mdtusz 5y agoThe quick and dirty solution to this is to have a client response handler that checks for a header set on responses to ensure its a compatible version, then prompt a page refresh if not.
- dgb23 5y agoAt this point, I feel like this is the most consistent way. There are notable web apps that do this. There are plenty of good reasons for this, including caching and service workers. It feels dirty because you’re not handling these issues silently. But it’s explicit, clear and it enables a consistent and performant experience.
- bonestormii_ 5y agoI wish more people thought this way about computing.
- cwp 5y agoAn equally-quick but not-at-all-dirty version of this is to use the Accept header and do content negotiation. There is a solution to this exact problem in the HTTP spec.
- jbandela1 5y agoOne thing you can do in the shared library is to have a version number constant that is always passed in the rpc. That way if the client is stale, it can easily be detected, and you only have to change 1 place when you update the shared structs.