What we need is an universal container at application level, and a suitable candidate can be found in a specification from the 90s called Unified Modelling Language (UML). UML was originally developed for compiled languages. It is a set of visual and data-agnostic guidelines for modelling objects, including their states, behaviors, and relationships over the lifetime of a distributed application.
Typically, developers use UML to model objects in a visual editor. Some tools can even generate codes from models, which are then compiled and deployed.
By following UML recommendation, over an architecture of plug-and-play micro-service providers, our platform redefines what a web object is, so that it gains flexibility in design and portability over web.
Have you ever wonder why application development is so hard. All you want to do is this and that, why do you have to learn all these concepts and jargons from middleware developers before you can even put together a prototype?
Traditionally, softwares are built from bottom-up to fulfill requirements from top-level problem description. Middleware developers design hierarchical, language-level objects and export a set of high-level APIs as end product. These APIs expose a very small part of underlyig Object-Oriented (OO) design. To use them correctly, end users must first learn the concept of these objects and relationships among them which may or may not pertain to the original problem. Also, most likely, end users would not unanimously agree on the overall design. No two minds think alike. Don't expect a band of like-minded developers can solve all the problems with one fixed Object-Oriented design, and in a way preferable by everybody. The most important thing in understanding their API while reading their documents is to discover its limitations by design, either explicit or implicit.
A preferred methodology is to put the power of design in the hand of application developers at the very top of programming totem pole, while still allow them to extend the framework by adding plug-and-play micro-service providers from below (see Figure-1). The line that separates droplets from service providers hides all unnecessary complexity from application development.
The arrows in the figure indicate roughly where major "concepts" are defined and their direction of flow. Notice also that object semantics are now imposed from the top-down by the application developers.
Our platform includes an UML-like web client called Condenser. In it, developers build a software object by drag-and-dropping different micro-service providers called molecules into an universal container called droplet. Several droplets make up a formation which is, in fact, an HTML web page.
Droplets and Formations can be published to a central repository and each assigned an unique HTTPS URL. Through these URLs, objects in repository can be imported into Condenser to be used as templates for building different set of objects. For example, this page demonstrates how to import a droplet from repository during edit time. Similarly and more importantly, an end application can import these objects at run time to dynamically supplement an object's behavior.
Each molecule comes with a set of properties. A property editor for configuring service provide can be opened during edit time by double-clicking on the molecule's icon. The following video shows a typical editing session. At run time, the same set of properties can be accessed via scripting.
In practice, molecules are developed by subject experts and once published, any novice can include them in his/her own objects to solve his/her own particular high-level tasks.
By now you must be wondering where does WebAssembly come in? Using droplet as a container and a transport vessel, WebAssembly can be embedded directly, or indirectly as a molecule. Video tutorials below demonstrate how each is done.