Wonder if anybody can help. I’m having trouble getting me head around how the mobile apps (capacitor) work with sever connect. I get that you need to separate projects one with the api actions in and then you have the mobile project.
I also get that you can pick the project and then API actions in the mobile project. What I can’t get my head around is how do you select which target (ie. may have a local, one on Digital Ocean etc…) it points at?
Any helps would be greatly appreciated.
Thanks,
For this reason, and because I white label the app and version my api’s, I use a dynamic url for all server connects and use a couple variables to build that dynamic url.
<dmx-serverconnect credentials id="current_tenant" url="http://localhost:8100/api/1/2/tenants/current_tenant" dmx-bind:url="base_url.value + api_path.value + '/tenants/current_tenant'" site="Meal Planner Pro" sockets="true"></dmx-serverconnect>
I have also gone with a system that sets the variables based on a initial check on a remote database. When the app loads, it runs a single server connect that checks with the main database, which returns the desired path for all server connects. Doing this allows you in realtime to change the target of mobile apps that are in the wild.
2 Likes
Thanks @mebeingken much appreciated.
That makes sense
Could I pick your brains a bit further. The bit I’m struggling with is how do you setup that first check on the remote database? Is this completely separate from all other parts of the app or just in the main app’s database?
Do you know if Wappler by default just goes to the first target in the list?
Thanks,
If you need to go with that method, then it looks something like this.
Your api project has an api that expects an app version as part of the request. This app version is just an arbitrary value you set in each build of the mobile app. The api then returns the desired host and path. I used a database query to retrieve that value based on the app version.
The mobile app then has a server connect that is set to auto load and has a static location (typically your production target). It calls the api mentioned above, sending its app version ( again, just a value you hard code for this build). Store the response in a variable (eg. base_url).
Now all the other server connects will have a dynamic url that uses the variable value along with the specific api path and name. These server connects get a dynamic attribute to only auto load when the base_url has a value.
This shows for you to have app builds in the wild using production data, and other versions using dev/staging data. And you can modify this in real-time by coming your db values.
As for which target Wappler uses to set the static url, I don’t actually know. I suspect it is either the development target, or the most recent active target, or even a combination of both. But it yes, could also be the first target in the list.
1 Like
Thanks so much for your help 
I have just been messing with the targets and it looks like it is the last one that was open it sets it to.
Thanks again