Yes:
> distributed architecture. For more details check out the Fleet product page [link].
> [Fleet product page:] Distributed for flexibility
> Fleet’s architecture is designed to support a range of configurations and workflows. You can simply run Fleet just on your machine, or move some of the processes elsewhere – for example by locating the code processing in the cloud.
But then they say "distributed" so that would mean many backend machines, not just one. What on earth is the backend doing where one instance is not enough for one client? How could one client UI possibly need more than one backing instance? Sounds horribly inefficient.
Being able to develop on a huge beefy cloud instance, with managed background services, possibly with different architectures, from your laptop is huge.
> But then they say "distributed" so that would mean many backend machines, not just one.
‘Distributed’ doesn’t mean ‘many’ - it’s distributed over two.
> ‘Distributed’ doesn’t mean ‘many’ - it’s distributed over two.
A client<>server architecture is generally not considered "distributed" unless there is multiple servers involved, at least how the terminology have been understood until today, if it changed suddenly.
Usually when it comes to these kind of architectures, you'd refer to them as "thin clients", and the architecture has been around since mainframes if not longer.
Ok? What's that got to do if it's useful or not.
> Usually when it comes to these kind of architectures, you'd refer to them as "thin clients"
Ah well the difference here is the client does a lot more work - it's running the editor, the editing and the editor state, it's not just transmitting input and receiving drawing commands.