The way WebAssembly interfaces with the external world is quite elegant and secure. Adding a function interface is easy, but not yet standardized.
Have calling conventions been established already for Javascript environments (mostly for accessing the DOM in the Browser or the filesystem in Node)?
Conventions for manipulating DOM nodes or using external APIs have not been created yet, but a couple of the WebAssembly proposals / future features will support this.
The first is the reference types proposal, which allows extends the type system, adding a new anyref type that allows modules to hold references to objects provided by the host environment, i.e. you can pass a JS object to your wasm module.
The second is the host bindings proposal that allows WebAssembly modules to create, pass around, call, and manipulate JavaScript / DOM objects. It adds a number host bindings section that includes annotations that describes binding mechanism / interface that should be constructed.
Rust already has a tool, wasm-bindgen, that is very similar in purpose and closely aligns with this proposal. With wasm-bindgen you can pass objects such as strings across the wasm / JS boundary with ease. The tool adds the binding metadata to the wasm module, and generates the required JS glue code.
Related
I'm looking for best practice defining a project structure in Rust. Let's say I have a project that consists of a client and a server component, and they share some functionality I'd like to move to a separate common library. So all in all, like this:
my_awesome_project
- common [library]
- client [binary] - uses common
- server [binary] - uses common
Obviously, all methods in the common crate used in either client or server must be public. However, I would like to avoid anyone who has the client binary (not the code) being able to call methods from common. Is that possible somehow?
I come from C# background, where common would be a DLL exposing public methods, easily callable. I've read that Rust uses static linking by default, but in my understanding, that does not provide what I am looking for.
And yes, I could double the common code in a private module for both server and client, but that's not optimal either.
To the extent that you have any control over what someone does with your code, Rust's static linking will sufficiently obfuscate the library boundary that you need not worry about the methods being callable.
You will not deliver the library to the user. You will deliver a single binary, hopefully stripped of debug information, which contains the code of client and all the code from common it needs, bundled together.
Unlike C#, there is no separate DLL file, and no metadata that makes it easy to discover and use library functions.
Global class?
I'd like to use a module in 2 other modules. And use defaults.
Then update the module after application is initialized (and connected to DB).
How this can be achieved?
Example use case:
Logger module is started with default configuration. It will fetch custom one from the database after database is connected.
Database module is using same logger (using default configuration until it gets configuration from that same database).
In many other languages I could create a class, then use instances of it and finally update class (not the instance) with new configuration. Updated values will be shared across the instances.
Some ideas that came into my mind:
Maybe I am thinking about it wrong way?
Can I use global variables?
I can use a local shared resource (file for example) to trigger change after startup is completed and connections are established/configuration fetched.
Another problem: How to avoid strong coupling between the modules?
Maybe I am thinking about it wrong way?
Right or wrong isn't really black and white here. It's more about benefits of modularity.
Can I use global variables?
You can, but you probably shouldn't.
Modularity in nodejs offers all sorts of benefits. Using a global variable creates a global environment dependency that breaks some of the fundamental tenets of modularity.
Instead, it generally makes more sense to create a single module that encapsulates the shared instance that you wish to use. When that module is initialized, it creates the shared instance and stores it locally in its own module level variable. Then, when other modules require() or import this module, it exports that shared instance. In this way you both retain the modularity and all the benefits of it and you get a common, shared instance that everyone who wants to can use.
The only downside? One line of code is required in any module that wants to use the shared resource to import that shared resource. That one line of code helps you retain all the benefits of modularity while still getting access to a shared resource.
I can use a local shared resource (file for example) to trigger change after startup is completed and connections are established/configuration fetched.
It isn't clear what you mean by this. Any modular, shared resource (without
globals) as described above can capture a configuration and preserve that configuration change.
How to avoid strong coupling between the modules?
This is indeed one of the reasons to avoid globals as it creates strong coupling. Any module that exports or shares (in any way) some shared resource creates some level of coupling. The code using the shared resource has to know what the interface is to the shared resource and that cannot be avoided in order to use it. You can often take advantage of existing interfaces (like eventEmitters) in order to avoid reinventing a lot of new interface, but the caller still needs to know what common interface is being used and how.
I am using nestjs to build several small applications, in doing so I would quite like a class library in which all projects can reference to pass the classes from one project to another if they'd like to, or at least standardise the objects to a contract they must adhere to.
Is there a way to approach this where I have a single standalone collection of simplistic domain classes not bound to a specific nestjs project, without specific domain logic involved, moreover the structure of how something should look as opposed to what it does?
Sounds like a perfect use case for using a NestJS Monorepo with a library, or to use something like Nx and use a library from there. In both cases, you're creating a reusable set of code (usually interfaces or classes) to be used throughout different parts of your servers/applications.
For remote attestation using a TPM, on the server-side I need the TPM2_MakeCredential function. Note that this function is implemented in the TPM but it is a bit off because it doesn't depend on any TPM state, it's completely stateless (unlike the TPM2_ActivateCredential function - to be run on the client-side - which critically depends on TPM keys). According to the documentation, it's provided as a convenience. That's OK but the problem is the server doesn't have (nor requires) a TPM. But I still want to use the TPM2_MakeCredential function.
Unfortunately, I haven't been able to find a library implementation of this function. There's a full-blown TPM2.0 emulator provided by Microsoft that the TPM.MSR libraries can interface to. This works, but it requires starting and managing the simulator process which sets up sockets etc. which I would rather avoid. I am wondering if there's a pure C/C++/C# implementation provided as a library? I have been working with various solutions but the function is not trivial to re-implement, and it's also not trivial to extract from the simulator.
It turns out the TPM.MSR library itself exposes this functionality (implemented purely in the library itself, not relying on a TPM) via the CreateActivationCredentials() function on TpmPublic.
I learned Java programming before learning any other programming languages. As I learn Node.js, I'm getting all the terminology confused. I have always thought API as a library of methods, classes, etc. that someone has built to make our lives easier. Then I learned about module, which I basically assume to be the same thing as an API(list of methods already built by someone). THEN, I learned about the Express Framework, which again, is a list of methods just like a module and an API. Moreover, the way we incorporate these features into our program is all by doing something like
Var http = require('http');
Therefore, can someone who understands the distinctions between these terms put these terms in context(examples) that could address my question.
Thanks a lot for the help.
A library is just a collection of numerous modules, classes, functions, etc. that are related to each other.
A framework is either a type of or a part of a library that is setup for you to build on top of rather than just call upon. And the distinction between Library and Framework can sometimes be a bit blurred.
With Express, you build upon the Application and its Router which handles incoming requests and determines when to call your code.
app.get('/', function (req, res) {
// ...
});
Though, frameworks can also span beyond code into tools. compound.js' executable is a good example of this.
A module is an individual piece of a library or framework. With Node, it's a single script file and the Object that is exported from the script.
An API is the summary/description of how you interact with the library, framework, or module.
It's usually what you'll find in documentation and is the accessible members, their name, their type, what arguments they accept, etc.
Express' API is:
express
Type: function
Named Arguments: (none)
Returns: Application
Members
listen
Type: function
Named Arguments:
name: port
Type: Number
etc.
This is largely an opinionated question. But I will attempt to provide the some terms commonly used by the Node community, and roughly the factual differences between them.
Module as it pertains to Node is very similar to what you would associate with a Java Library. It provides a wrapper around things that Node users find they do a lot. Frequently providing wrappers around node library functions for doing things everyone wants to do. A simple example would be a recursive file system reader, like wrench. Modules also extend to files you use to modularize your code. For example, modules aren't only installed via NPM, but separate javascript files you write as part of your code base to separate code functionality, under standard OOP practices.
require('someNPMINStalledModule')
require('./someFileInYourCodeBase.js')
both are modules. One is installed via NPM and located in node_modules directory, in the directory you launched node from. The latter example is a javascript file located in the directory you launched node from.
Then there are frameworks. At the core these do the same thing as modules, however, they are meant to be more wide spread, and really change the way you use node. In the java world frameworks like Express would be similar to things like Grails. You can still include and do everything you can do in Java, but grails wraps some things for you, and provides convenient powerful method calls for doing batches of work in a less verbose way. In the end you end up with functionally equivalent code, but Grails has allowed you to accomplish more in fewer lines of code, by generalizing the language a little more. But it still, as I said, allows you to use native code, when Grails doesn't provide the functionality you need. At the cost of this 'few lines of code' gain, you have added a layer of abstraction, additional function calls, etc. This distinction is unimportant, unless you are one who cares deeply about style. A hardcore ExpressJS developer likely wouldn't like it if you included a plain node http server in your code. Not so much because it is invalid Node, or from a perforamnce view any different, it wrecks the style of your code. If your code uses a framework, you should stick to using the coding conventions as used in this framework. But if you use a module like wrench to recursively search a directory, it is still perfectly stylistically acceptable to use fs.readFile, to read a single file.
Then there are mini applications which is a module that allow you to quickly launch simple things like serving a file. For example: http-server will server a directory of files to any port you wish, with a simple command line. You wouldn't use them in your own code with 'require' but this type of module can honestly be some of the most useful thing node provides, I highly recommend using some. (Nodemon, http-server, and grunt are a few highly useful examples of modules that can help make your development life easier)
Finally there are Native Extensions. The concurrency that Node provides comes from the V8 backend. Replicating this in pure Javscript is impossible, and the only way to write truly asyncrhonous code is to take advantage of asynchronous operations provided by the Node API, do some really wonky logic with process.nextTick, fork child processes, or write native extensions. Native Extensions provide truly concurrent operations that Node does not provide. Database communication is the most obvious example, but anyone can develope a C++ extension that will spawn threads to do work. There is also a very handy module that launches threads to handle bits of Javascript called "threads a gogo". It simplifies the launching of truly concurrent work, though if you're in a position where such things are necessary, you may find that you're using the wrong language for your use case. Ultimately these are no different from Modules in the way that you use them, but being aware of the fact that they can provide additional concurrent method for I/O type of operations not provided by NodeJS APIs is a unique and very important distinction.