Still a bit confused how sidecar and the various patterns work for Django python webapp

[simkimsia]

I saw this #1645 (reply in thread) but still unsure.

I saw a bunch of patterns such as cloudbridge https://tauri.studio/en/docs/guides/patterns/cloudbridge#diagram

and i did see bundler pattern such as sidecar.

Suppose I have a Django webapp, i understand i need to choose sidecar, but what pattern do I choose?

is it cloudbridge? is the django webapp in the server part of the diagram?

also is it possible to communicate with servers on the internet? which part communicates with the internet API? is it the django webserver?

my ultimate goal is to create offline first desktop app that can sync with an internet server but i am more comfortable with django webapp, so i am unsure how to do this with minimum efforts in learning new patterns.

I don't mind learning, but i want to as much as possible reuse what i already know.

thank you

[FabianLars]

The patterns aren't really up-to-date right now, most of them are still from alpha versions and tauri changed a lot since then (for example you could chose between the custom-protocol and an embedded server (that's the server mentioned in the diagrams). So don't waste your time trying to fit sidecars in them too.
Also currently the best practice (in the context of patterns) is to disable the whole allowlist and enable only the things you need when you need them. But with a django server you probably don't need anything from the allowlist anyway, other than the stuff used to spawn the sidecar.

also is it possible to communicate with servers on the internet? which part communicates with the internet API? is it the django webserver?

Yes it is possible. And which part does it doesn't reallyyy matter, but the javascript frontend definitively should be the last resort. I'd say letting the django webserver do that might be the way to go here, but that completely depends on your actual app/context.

[simkimsia]

Thanks for your reply @FabianLars

I have a few follow up questions in descending order of importance (i think):

1. so in my context of "create offline first desktop app that can sync with an internet server" let say i use "django webserver on desktop" then the django webserver on desktop <==> django server on internet to do the sync and based on your response "letting the django webserver do that might be the way to go here, but that completely depends on your actual app/context."

   1.1 supposed it's todo app and i want to use figma's syncing object properties method in https://www.figma.com/blog/how-figmas-multiplayer-technology-works/#syncing-object-properties

    i.e. 
    if change different property then last-writer-wins without need for timestamp of property changes
    if change same property, then last-writer-wins while dropping at the desktop app any conflicts for unack changes
   
   and only these two CRDT operation patterns
   

Is this all right? or overkill?

2. if i were to choose django webserver in the desktop app, what pattern do i use exactly? based on your line "But with a django server you probably don't need anything from the allowlist anyway, other than the stuff used to spawn the sidecar." I just use sidecar is enough?

[FabianLars]

Is this all right? or overkill?

Well i guess that's kinda subjective. If it's a todo app or something with similar complexity levels than imo it's overkill and nothing a few lines of rust code can't do. But again that's subjective and especially if you have big plans for your app doing it your way early on is completely fine. But honestly it's fine either way, just do it the way you want.

what pattern do i use exactly?
I just use sidecar is enough?

Again, don't force yourself on the patterns at the moment until they get updated.
Also, the patterns (in their current form) aren't reallyyy relevant for you here anyway, because the allowlist's main use is to lock down @tauri-apps/api (js) (it also affects tauri::api (rust) in a similar way). Plus you already know you want to use a sidecar 🤷
So disable the whole allowlist and only enable shell -> execute because that's needed to start your sidecar:

"allowlist": {
  "all": false,
  "shell": {
    "execute": true
  }
},

Depending on how you want to communicate with the sidecar you might want to enable the http endpoints too.

[simkimsia]

Thank you @FabianLars I am now looking at this example

https://github.com/tauri-apps/tauri/tree/dev/examples/sidecar

so i suspect this sidecar example uses node.js pkg for the backend. I'm not familiar with node, so i suppose scripts and src are the node.js backend portion yes?

Btw, i am building a tauri-app using vanillajs as the frontend using the tauri cli wizard to create a new app

[simkimsia]

So disable the whole allowlist and only enable shell -> execute because that's needed to start your sidecar:

yes i just did that.

simkimsia/tauri-app@725ad5c

I'm now a bit unsure how to proceed next. Would be great if can point me in the right direction

[FabianLars]

@simkimsia
The scripts folder (or rather the file inside) is used at build time to rename the pkg-packaged binary according to the target triple.
You don't necessarily need this file if you have another way to rename your sidecar binary (you can do this manually too 🤷 )

And yes, in this example the src folder is the nodejs "project", in all other examples the src folder is the frontend folder.

I'm now a bit unsure how to proceed next. Would be great if can point me in the right direction

Honestly, i don't know that either. That pretty much depends on you. The example shows how to start the sidecar: https://github.com/tauri-apps/tauri/blob/dev/examples/sidecar/src-tauri/src/main.rs#L20-L23. Everything else completely depends on your frontend and sidecar (especially the communication)...