Webda v4 Ideas

[loopingz]

Webda v4

The motivation behind v4 is to provide more documentation, a new Eventing system based on cloudevents, a new Cache system.

The number of breaking changes should mostly concerns the events and execution context

Core

• Application: define the services, models
• Core: create and manage the services it is available as a singleton in the application Core.get()

Core services:

• ConfigurationService
• CryptoService
• Registry
• EventService
• SessionManager
• Logger?

Core services are always available in the application. If not defined a default one is assigned

Entrypoints

Once the application is created, you can expose it through

REST API
GraphQL
Websocket
GRPC

EventService

We are not using the NodeJS event anymore as events through your application can flow between different micro-services, instances of the application, etc.

The EventService is based on the CloudEvents specification and is used to emit and listen to events.

To emit an event just do:

// To emit without waiting for the event to be processed
new MyEvent(...).emit(true);
// or if the event requires to be processed
await new MyEvent(...).emit();

To listen to an event, you create a CloudEvents subscription:

The subscription spec should allow to have a default mechanism to handle webhooks.

Events should be able to be broadcaster to the whole system with a pubsub

Documentation

While compiling the application we should extract the class hierarchy with their methods, variables and jsdocs. Rendering of typedoc is too cumbersome in my opinion.

Client genration

We can reuse the JSON schemas to generate the client libraries, with some mechanism to implement the requests.
A CoreModel with a method with the @Frontend annotation should be copied along.
When generating client for other languages theses methods could be defined with the generator to simplify the generation

Execution context

We can now leverage Async Context from node: https://nodejs.org/api/async_context.html.
It allows us to by know in every method which user is logged. With some utils function like runAsSystem to allow code to sudo its permission when needed.
Stores should implement a new parameter: securityContext: "STRICT" | "WARN" | "LEGACY" in legacy mode, unless you use the external endpoints you can select any objects, in strict mode all store operations are tied to the current execution process and you do not have to worry about leaking data the user cannot access. Warn mode keeps the legacy behavior but display a warning everytime you access an object that would be refused in strict

BinaryLoader

We should have an implementation to read binaries with some abstraction BinaryLoader.load("fs:///my/path")
With modules like gcp or aws bringing the s3:// or gs:// to the available protocols. A context permission filtering can be added to allow disabling all or parts of url based on the current user or other consideration

Cache

We need a better cache system than the current one.
@Cache annotation can be added

We need to define 4 types of cache:

• per context: attached to the current execution context
• per session: attached to the user session and kept over requests for the same session
• global: attached to the execution of the application
• init: cache that is passed to the application when deployed, so it does not have to do additional starting computes

WebdaQL

We should add some basics aggregate functions.
Extract it to a standalone package to be able to be used independently

Benchmarking to compare to acorn execution would be good too

Binary distribution

Webda shell should have a deployer that compile the application as a binary for distribution
https://nodejs.org/api/single-executable-applications.html

React

We could have a default library providing the hooks for authentication, subscription, query and hawk implementation

Queue

Add utils like @Consume to auto register methods