I have built a webapp using weweb that is using an sql database as backend using the sql plugin. (My database is currently hosted online but only accessible by the weweb ip address.)
I now need to deploy my webapp for my customer in their own datacenter. I understand that the export code function is only for the static files, but how can I now linkup my static files with my backend that connects to their local sql database and that can handle the sql requests in my webapp ?
The exported web app should continue to works. It will send request to our SQL microservice, and this microservice will forward it to your linked database (the one you configured in the editor before deploying it)
So if I want to use a local db in their datacenter I should change the SQL server parameters in the editor (which will not connect since there is no way to connect from the outside to my customer’s server) and export the code ? There is no way to change the sql db settings inside the exported files ?
Thank you !
It setup a REST API on top of your database an. But it’s very technical. It also provide a simple web server to host your builded app, you just have to copy paste your files in the right place and it will serve it for you (not mandatory, you can still host them elsewhere)
Apologies for my late reply and thank you for you reply Alexis.
The provided solution (compose-postgrest-weweb) might not be usable as is in my case but setting up a REST API in front of my db is not a bad thing in itself.
But I have to admit that there is something that I do not fully understand here:
My understanding now is that using the sql plugin requires our sql statements to go through a weweb microservice, therefore requiring online access to the front end hosting and the db.
However, using a REST API does not require interaction with a weweb hosted microservice at all ?
That’s because we need to hide your SQL database credentials.
But for a REST API it’s not required as you can have a public API or a protected API with a mechanism to let the user authenticate and then attach the authorization token or login/password to the request dynamically, no common secret to hide.
But for some services like Airtable where you have a private API KEY it’s the same constraint, we have to hide it behind a microservice on our side. Because else it will be available in the front end and someone could steal it.
One last question (I hope :D) for you Alexis, I have now implemented my rest api and started working on implementing user login using a JWT Bearer Token for authentication & authorization.
If I use the weweb Token auth system, will I be able to export the static code and login without using any weweb service ? (meaning not needing any access to the weweb hosted servers)
Yes, but be aware once you export the code we are not able to secure the access to the page itself, so your page should not contain any hardcoded sensitive information inside.
But as your dynamic data are loaded dynamically with the user token, your data remain secure.
By self hosting the app, what you lose is the backend verification we do before returning the page, but it can be replaced by a simple workflow on page, checking if the user is authenticated or not, to redirect the user to the login page for example.