Davide, I've cloned your yew-deven as a template and am now trying to modify it by adding a module I've created in rust to access a database with odbc. I got the db program to work independent from yew-deven and am now dropping it into yew-deven. After making all of the needed changes to incorporate it, I run it and get two warnings: Unresolved dependencies and Missing global variable name. Since the yew-deven ran without any Warnings or Errors prior to adding the new odbc module I suspect the problem lies somewhere with my new rust module. Any thoughts?
Can you show me your Cargo.toml and the actual error?
The first thing it comes to mind is to check whether the odbc driver interface crate you are using is compatible with webassembly and to which degree
error msgs:
Serving "./index.html"
Listening on 0.0.0.0:8080/
main.js → pkg/bundle.js...
LiveReload enabled
(!) Unresolved dependencies rollupjs.org/guide/en/#warning-tre...
env (imported by pkg/yew_template.js)
(!) Missing global variable name
Use output.globals to specify browser global variable names corresponding to external modules
env (guessing '__wbg_star0')
created pkg/bundle.js in 190ms
In reality this is a rollup.js error. It is searching for 'env'.
Did you install rollup-plugin-inject-env?
In case the command is:
npm i rollup-plugin-inject-env
At any rate, are you using odbc and odbc-crate compiled for wasm or as a serverside API? Since odbc wraps around a C driver I do not think it will compile to wasm. In case you succeed let me know 😃
Hi Davide, Thanks for all your help. This is looking pretty hopeless so far. What I'm looking to do is have a browser based app that accesses a local SQL Server running inside a Docker image on a Mac.I was hoping to access the db directly with out going through an API. I have one I created in React but was hoping for more efficiency by accessing the db directly.
Well something can be done... Warning: it is a method prone to malicious attacks if exposed.
Here's the gist of it: you are going to access a local db with a local webpage, right? So there's less concern for protection (less in not none)
Anyways, odbc has got a SOAP interface:
You might access it with the soap crate in Rust or with javascript (better solution).
It is a hacky trick, but it should work. But it takes a lot of effort. An API wrapper can be hardened for security, and you could interface it with JSON which is more universal and simple than SOAP...
Another way, which is useful if all the structure is in the same machine, is a wrapper to odbc that saves data to Redis, then to use the Redis server to exchange data with the webpage... Also lot of work, but you can prefetch and manipulate data before storing it to Redis. The advantage of having an API is that all the pieces are there, plus if tomorrow you want to interface other databases, local or remote, it's much easier to add. Also, I do not know your needs, but once you provide an interface, needs always arises to make some manipulation of data serverside before presenting it to the final user's interface...
Davide, thanks for your reply and all of your effort. I think since I already have an api built in React that connects to MS SQL db, I'll just continue to use it and get Rust to communicate with it and then send the data needed by the React frontend. Again, thanks for your efforts and knowledge.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Davide, I've cloned your yew-deven as a template and am now trying to modify it by adding a module I've created in rust to access a database with odbc. I got the db program to work independent from yew-deven and am now dropping it into yew-deven. After making all of the needed changes to incorporate it, I run it and get two warnings: Unresolved dependencies and Missing global variable name. Since the yew-deven ran without any Warnings or Errors prior to adding the new odbc module I suspect the problem lies somewhere with my new rust module. Any thoughts?
Can you show me your Cargo.toml and the actual error?
The first thing it comes to mind is to check whether the odbc driver interface crate you are using is compatible with webassembly and to which degree
Cargo.toml (dependencies)
[dependencies]
wasm-bindgen = "^0.2"
yew = { git = "github.com/yewstack/yew", features = ["web_sys"] }
yewtil = { git = "github.com/yewstack/yew", features = ["fetch", "pure"] }
odbc = "0.17.0"
odbc-safe = "0.5.0"
env_logger = "0.7.1"
log = "0.4.0"
[dependencies.web-sys]
version = "0.3.4"
features = [
'Document',
'Element',
'HtmlElement',
'HtmlCollection',
'Node',
'Window',
]
error msgs:
Serving "./index.html"
Listening on 0.0.0.0:8080/
main.js → pkg/bundle.js...
LiveReload enabled
(!) Unresolved dependencies
rollupjs.org/guide/en/#warning-tre...
env (imported by pkg/yew_template.js)
(!) Missing global variable name
Use output.globals to specify browser global variable names corresponding to external modules
env (guessing '__wbg_star0')
created pkg/bundle.js in 190ms
thanks
In reality this is a rollup.js error. It is searching for 'env'.
Did you install rollup-plugin-inject-env?
In case the command is:
npm i rollup-plugin-inject-env
At any rate, are you using odbc and odbc-crate compiled for wasm or as a serverside API? Since odbc wraps around a C driver I do not think it will compile to wasm. In case you succeed let me know 😃
Hi Davide, Thanks for all your help. This is looking pretty hopeless so far. What I'm looking to do is have a browser based app that accesses a local SQL Server running inside a Docker image on a Mac.I was hoping to access the db directly with out going through an API. I have one I created in React but was hoping for more efficiency by accessing the db directly.
Well something can be done... Warning: it is a method prone to malicious attacks if exposed.
Here's the gist of it: you are going to access a local db with a local webpage, right? So there's less concern for protection (less in not none)
Anyways, odbc has got a SOAP interface:
docs.microsoft.com/en-us/previous-...
You might access it with the soap crate in Rust or with javascript (better solution).
It is a hacky trick, but it should work. But it takes a lot of effort. An API wrapper can be hardened for security, and you could interface it with JSON which is more universal and simple than SOAP...
Another way, which is useful if all the structure is in the same machine, is a wrapper to odbc that saves data to Redis, then to use the Redis server to exchange data with the webpage... Also lot of work, but you can prefetch and manipulate data before storing it to Redis. The advantage of having an API is that all the pieces are there, plus if tomorrow you want to interface other databases, local or remote, it's much easier to add. Also, I do not know your needs, but once you provide an interface, needs always arises to make some manipulation of data serverside before presenting it to the final user's interface...
Davide, thanks for your reply and all of your effort. I think since I already have an api built in React that connects to MS SQL db, I'll just continue to use it and get Rust to communicate with it and then send the data needed by the React frontend. Again, thanks for your efforts and knowledge.