mORMot Open Source

FClient :=THttpClientWebSockets.WebSocketsConnect(....),
 

use such code to create a ws client , if connection was made , the "FClient.Settings^.OnClientConnected" callback will be called (if not nil)

BUT, FClient.Settings^.OnClientConnected is nil at this time, because there is noway to set this param before create ws client,

ok , i know we can do it in the focContinuation frame, but ... just not so perfect.

strange thing, THttpClientWebSockets randomly close, and very hard to detect/debug.
both with our mormot wsserver ,or third party wsserver,

already turn on the heartbeat by :
WSClient.Settings^.HeartbeatDelay :=10000;

localhost is only for test.
clients are few, just have to send realtime signal over Internet.
as you say, i should not use AsyncServer，i will try socket based server for this.
thanks a lot.

my finding is that latency happened in recv,
because i use other websocket server lib like “delphi-cross-socket”, client still use our mormot THttpClientWebSockets,
the latency is less then 1ms.
test is client send to server.

about "non-blocking-method",what and where should i change? i test this within mormot pattern,in chat protocol,
TOnWebSocketProtocolChatIncomingFrame,  it always get triggered with 30+ms delay.
so it may not about non-blocking-sending

TRestClientUri.ServerTimestampSynchronize will do

thanks a lot for the info

@ab
Maybe it should be described as distributed rather than microservices.

I really like mormot, from the perspectives of quality, scale, performance, modernization, and cross platform, mormot is undoubtedly the #1 in pascal world.

This is why I use it heavily, which makes life much much easier.

As a middle-aged man、 an ordinary programmer, a framework user, NOT an architect, boss, or infrastructure researcher,

Most of the time we can only do what is asked and make the best use of what we have.

Lately I've been thinking, what's the meaning of always writing CRUD? What is my goal?

So, I have project that I want to do for myself, i'd like to build it in the most ideal way to make a perfect product.

And once upon a time, in order to learn, I stayed up for several consecutive days to read the source code of mormot or other systems, in order to use them in the best way.

But, I found THAT, once i want to be perfect , my project could Never be completed.

In addition, there are pressures such as cost, marketing, competition, and living bills that we cannot afford to be perfect.

So for a independent developer or a mini-team (Delphi/Pascal current use situation) get something done and stay alive is much much important than tech it self .

So what i do is to choose the best framework such as Mormot, infrastructure components such as Redis\RabbitMQ etc..

Becasue they suit for many cases , can get the job done Reliable and Faster.

i offen promot Mormot to others , there are 2 types responses:
1、don't want to import to0 many dependency, they just uses little piece of mormot like http.sys httpserver or crypto
2、use mormot as infrastructure framework, from RawUTf8 to everything .

second type of users, says they need infrastructure framework abilities like java SpringBoot so they can focus on business logic.

As for Redis, *MQ, they are not just cache or a messagequeue. if it is only cache or queue, i rather use TSynCache ,TSynDictionary, or TSynQueue.
they are ecosystems much more than a simple cache or queue.

any news?

another problem, not sure is a bug :
unit mormot.net.async line 3323 ,when used as websocket server :

function THttpAsyncConnection.DoRequest: TPollAsyncSocketOnReadWrite;
var
  output: PRawByteStringBuffer;
  remoteID: THttpServerConnectionID;
  sent: integer;
  p: PByte;
  flags: THttpServerRequestFlags;
begin
  // check the status
  if nfHeadersParsed in fHttp.HeaderFlags then
    fServer.IncStat(grBodyReceived)
  else
    begin
      // content-length was 0, so hrsGetBody* and DoHeaders() were not called
      result := DoHeaders;
      if (result <> soContinue) or
         (fHttp.State = hrsUpgraded) then
        exit; // rejected or upgraded  <<<<<!!!
     <<<<--- if our server is behind a reverse  proxy . even we use the (fhttpServer).RemoteIPHeader :='X-Forwarded-For' 
       because we exit here ,following  fServer.ParseRemoteIPConnID(fHttp.Headers, fRemoteIP, remoteid); never get a chance to exec
    ---->>
    end;
  // optionaly uncompress content
  if fHttp.CompressContentEncoding >= 0 then
    fHttp.UncompressData;
  // prepare the HTTP/REST process reusing the THttpServerRequest instance
  result := soClose;
  remoteid := fHandle;
  fServer.ParseRemoteIPConnID(fHttp.Headers, fRemoteIP, remoteid);

     <<<<--- if our server is behind a reverse  proxy . even we use the (fhttpServer).RemoteIPHeader :='X-Forwarded-For'
       because we exit here ,following  fServer.ParseRemoteIPConnID(fHttp.Headers, fRemoteIP, remoteid); never get a chance to exec
    ---->>
when we need to get the Real RemoteIP from header ,
those code works fine when it handle regular http rest request ,but not work in websocket mode.

and with this AS_UNIQUE , when use the ctxt.Returns(const NameValuePairs: array of const;....) to return some Torm data, those filed are all missing

answer excepted , the problem js my orm record contain a nested TSQLRecord field, witch did not filled by the TSQLRecord.create

still get me wrong.
i mean TMVCApplication  alreay have this feture , but any regular class registerd by RestServer.ServiceMethodRegisterPublishedMethods('some') dose not .
eg:

type 
    TMyDemoClass = class
    published 
        procedure list(Ctxt:TSQLRestServerURIContext);
    end;
var
  _demo:TMyDemoClass ;

begin
... rest root eg :root
RestServer.ServiceMethodRegisterPublishedMethods('demo', _demo);
end;

then i need to access the list method by http://domain/root/demo/list
but with current mormot implemention , it only can be accessed by http://domain/root/demolist

why TMVCApplication can register a prefix like "blog" and then can access it with "root/blog/default" ?  i mean, why this feture can not be used in ServiceMethodRegisterPublishedMethods ? any class with its published methods registed with ServiceMethodRegisterPublishedMethods with prefix ,eg "test" ,why we can not access it use "root/test/*" but "root/test*"?

thanks for the quick reply .
so , if i DONT need to reuse the json, there is no need to call UniqueRawUtf8,
just
vObj :=TMyObject(JSONToNewObject(Pointor(vJson),vObjValid,[j2oIgnoreUnknownProperty]));
will be ok ? am i right?

Well, got it now, we should disable the Authentication on RestServer Creation first..

you mean process Cookie head(Read/Write) in the Ctxt Context within the method based service or in the ServiceContext within the interface based service?

this can do it , and i know it , reason i post this thread is hope mORMot MVC will be more powerful and do not rely on other parts of the framework:

lets say :

mORMotMVC is more suitable to deal with cookie\Session ,while Rest Service is not so direct . and also , it is not in the MVC subRoot

again within the mORMotMVC , if we can use the Service ability directly(do not need view) in the TMVCApplication , it will be perfect

for now ,  mORMot MVC have some problem :
1、the methodname/json/ can return json data , but it can NOT take param(like json format) send by POST ,just GET work for now
2、every TMVCApplication view method need a view template, while some processing like :login/logout just need process params(by get/post) , they do NOT need view template