mORMot 2 framework

Third Party
1

From Arnaud Bouchez on LinkedIn

I don’t like switching and pipeling protocols.
With our mORMot framework, we achieve the same goals, just staying with plain JSON.

  1. It can use WebSockets (in addition to regular REST/HTTP) and gather pending requests and responses into a JSON array, to reduce latency - and still be simple and standard.
  2. Both ends agree with a contract, which is defined as a modern object pascal “interface” type. No IDL, no separated file, no XML. Just code. Then its generates a JSON array of values instead of a JSON object of name:value pairs. The JSON array is sent as both requests and responses as standard WebSockets JSON frames. We could optionally use a WebSockets binary frame (with this JSON array payload but optional compression and encryption), for even smaller TCP packets, without the complexity of HTTP/2. And our JSON parser/emitter works at 1GB/s per core so with very high performance. Network is the bottleneck.
  3. Type safety is built from the object pascal language, and its “interface” type definition.
  4. It is still plain JSON, so it is much more standard that your “polyglot” solution. Try to implement gRPC and IDL with plain JavaScript. You need a library. JSON is embedded to the browser.
  5. WebSockets frames are by definition bi-directional. If you define an “interface” method with no result parameter, it could be identified as “non-blocking sending with no wait”. Just awesome for event-based systems.
  6. You can generate client code for any language or system, using a mustache template system (e.g. into C# or into a Swagger template). It uses a standard WebSockets stream, so you can share the same proxy/load balancer system already used for your HTTP requests.
  7. It is not “more complex”. It is just a simple but clever solution leveraging plain JSON and WebSockets.
  8. It is perfectly human readable, as JSON is still used for the values.
  9. WebSockets and JSON are still part of the browser support. So you can use this scheme with front-end applications.

This is mORMot 1 documentation but it stays the same with current mORMot 2 version (documentation is a work in progress)

1 Like
2

Hi Paul

I use mORMot 1 and have yet to update to version 2.

My system uses interfaces as well as asynchronous callbacks.

With respect to using interfaces the system is quite easy to code:

Interface coding:
define (or add) to the interface

Server coding:
write the server code class for the interface
register the server class and interface to the server (one line of code)

Client coding:
register the interface in the client
use the interface (an anonymous method in a single procedure call)

My callback server handles both short and long (minutes+) transactions. The caller (client but not always) is informed (with a result) when the transaction has completed.

That’s about it.

I have even developed a base server and base client applications that contain all the my mormot code for my system.

By using interfaces the compiler ensures that my client calls correspond to expected server code.

I do find mormot easy to use although I am not using all of its features.

Regards
Graeme

1 Like
3

(btw Arnaud was replying to a post about how gRPC works. )