Gather/Save/Export Metadata

[swfsql]

The sdk already has some metadata-related information generation ([1], [2]), and this library intends to design this area further.

Checks

There might be ways to use specifications and/or generate metadata and check against wasm files.

So this library should get metadata about the trait and implementations, such as how many method do they have, those method's names, iterators throughout the methods metadata, etc.

Those values can be checked against later on.
For example, when implementing a trait which have default implementations for a state, the missing (but still valid) default implemented methods will not be accessible to the proc macro, and so it should error to enforce that all methods must be present.
An attribute on the trait impl allowing skipping of missing default-implemented methods could be useful on this.

UI

Another type of metadata is structure information for generating client/testing interfaces. This type of metadata is not to be pub in the source code, but for generating artifacts external to the code and to the wasm binary.

If possible, it would be awesome to export some openapi-like file definition based on all externed functions, as if the contract being built were a server that will be hosted on Near. okapi appears to be based on serde/rocket, but could be a starting point. schemars which is serde-friendly and is from the same author, as well.

On the schema itself, if there is a middleware https server that could forward calls into a Near RPC while exposing a REST interface for clients, then openapi schema could possibly be used directly. For creating a specific middleware server that exposes an openapi-compatible interface (which would still need to forward calls into a Near rpc), poem-openapi might be useful.
On openapi itself, if (unlikely) required, it's still possible to generate rust definitions based on the schema as well with openapi-generator (where swagger has utilities to use the generated rust code.

The standard library that can call Near rpcs is near-api-js, it has many other features besides calling contract functions.
This library should probably be used by all projects and it's functionality should not replicated anywhere else.

API Documentation

Having a pure API documentation generated based on the exported functions helps development and testing. okapi and rweb seems capable of hosting the documentation based on the src code, and paperclip from the schema. openapi-eller seems to be a node version of this, and @openapitools/openapi-generator-cli node app itself as well.

CLI App

Then from that definition, use tools similar to paperclip to be able to generate a client-side CLI app directly from that definition, which would show all methods (and their arguments, and their documentation) that are expected to be hosted by the contract "server".
And finally, when passed a contract hosting address (aka. the AccountId where it's hosted on Near), that CLI could forward calls into some near-cli app (or extend a near-cli library and directly make the call).
Another possibility, if extending the near-cli (js/rs) project itself, is to directly add the scheme functionality into it, so it could automatically show that information inside the near-cli itself, basically incorporating that paperclip functionality.

Native App

Just like a CLI app, GUI apps can also be an option. Although specific for clap cli apps and based on the rust src code, klask is able to expose something that was supposed to be a CLI into a GUI.

Web App

The natural evolution of this would be to automatically generate a admin-like web app based on the specification, that could ask for contracts and schemas, connect to wallets and offer the client interfaces, where the app is focused on invoking the contract's methods while also giving some GUI guidance on the arguments, such as using proper html elements.
Mozilla's React JSON Schema Form looks amazing (which can crate react forms based on jsonschema). React/Vue/Angular compatible alternative. Vue alternative. jQuery alternative. Angular alternative.

Testing

This could facilitate testing, besides being a possible automated starting point for web apps, to be generated automatically from the contracts src code themselves.
Advanced features could also be present by default, like allowing multiple accounts to be connected (allowing calls from different users) or maybe even allowing calls to be prepared, organized into groups, sequences of calls, etc.

For testing purposes, always having an option to directly set a contract's state would be good as well, but this would need to affect the wasm generation step. Besides state setting, visualization of it would be cool too. If the rpcs allow this, perhaps a binary to json-schema translation would be possible, and the state could be visualized (and locally saved, locally loaded, updated) from a web form as well? (unlikely)
Note: just setting the state could be misleading as there could be in-flight callbacks and whatnot already placed by the contract itself). To mitigate those effect interferences, maybe every method call should contain a "state version id" that it would expect the contract to have, that would be incremented on every forced-state update, where this "state version id" argument and method logistic could be always automatically added if the contract is being built for testing purposes (similarly on how payable/private automatically adds conditions on the method).
Incidentally, one way of just stopping those registered callbacks would be to increment that counter, even without changing the state

Web Library

It could also define a web app library with components only, as they could come with some documentation and requirements for free, that could be used or adapted by actual web apps as well.
The documentation would likely be improper as it would be Rust-focused, but the Rust source code could allow specific attributes for client-focused documentation as well, which could be used for CLI, GUI and Web clients, including web libraries.