Passing objects and attributes between client and server

Anvil Q&A
7

Thanks, @owen.campbell.

More generally, regarding application design, desktop vs. Anvil:
I’ve written desktop applications for literally decades. Anvil app architecture is different from desktop. Each starts from a different foundation, and has different constraints. Classes (and other code) that make sense in one context do not necessarily make sense in the other.

On the desktop,

  1. In compiled languages, code can’t be altered by users, so in-program data is relatively secure.
  2. Instances can live as long as the program is running, preserving state for as long as needed, and serving as a foundation for rich, intelligent, self-managed behavior.
  3. There’s no barrier between UI and application code. A class can (and frequently does) mix UI and application code, data, and objects, willy-nilly. (Not necessarily wise, but certainly expedient, therefore frequent.)
  4. Due to 3, UI-related code can directly call whatever libraries you have handy.

With Anvil,

  1. running parts of the app in the browser means that those parts of the app are (unfortunately) hackable, and visible to end-users (if they wish). For anything non-trivial, you must split logic between client and server.
  2. Server-side objects live only long enough to service a call from the client. To persist longer, an object must be reduced to data-values, and put into a session-level cache, or the database, and re-constructed later, into an object, on demand. (You can pay to have your server program stay running, one instance per browser-session. Other instances are transient, as described.)
  3. Client-side code generally can’t leverage regular third-party libraries directly. They have to be written specifically for Anvil.
  4. Differences like these can invalidate the very design of a desktop-based class, never mind an entire desktop application.

In short, one should not expect desktop-style application-level code to be usable, as-is, in Anvil. The underpinnings of such code – support libraries – may be usable on the Server, or in Uplink code. But it is an entirely different architecture, with significant ramifications for the design of the entire application. Very different design patterns come into play.

This does not make either architecture “wrong” or “right”. It just means that they don’t match up in a lot of places. The constraints are different. Taking that into account, the reasoning one applies in each case must also be different.

Coming from a long, long desktop perspective, this was a big surprise. I had to learn, and “unlearn”, a lot. And that’s still in progress. I’m still picking up new and better patterns for building. And Anvil itself continues to evolve, so new patterns keep turning up.

1 Like