I was wondering how the client should send a request on server network.
1.) Synchronous client request, Asynchronous network implementation
2.) Synchronous client request, Synchronous network implementation
3.) Asynchronous client request, Asynchronous network implementation
4.) Asynchronous client request, Synchronous network implementation
Out of above 4 implementations, which one is the best implementation.
Synchronous client request, Asynchronous network implementation. Why? Because why not.
Related
I have read a couple of articles which tells us about the communication between microservices, I have chosen the event based communication between microservices pattern, but now I am wondering how the client is supposed to communicate, if it sends a request to the API gateway, should it wait for a response (which might take time due to the event based nature of communication between the microsrvices internally) or should it say "processing" and do polling to check if the request was completed?
What is the standard practice for client --> api gateway --> microservices communication?
Most of the time you will find that Clients --> API Gateway --> Microservice communication is actually synchronous, which means that client would need to wait and block until a response is received. Typically it is implemented as a HTTP based call that the client fires to the API gateway and then reaches the microservice at the back. This doesn't seem to be the kind of event based communication that you are talking about.
The standard practice for event based communication would be something like : Client --> Event/Message Broker --> Microservice this is an asynchronous approach where the Client doesn't block/wait for a response. However, the client would need to have a back channel event handling process that is listening to the communication to handle the response that comes back from the microservice. Microservice --> Event/Message Broker --> Client.
I have read that HTTP is a synchronous protocol. Client sends a request and wait for a response. Client has wait for the first response before sending the next request. Ajax uses HTTP protocol but is asynchronous in contrast. I also read that
Synchronous request blocks the client until operation complete from here. I am confused and my quesetion are:
what is definition of synchronous when talking about HTTP Protocol?
Does synchronous associated with blocking?
HTTP as a protocol is synchronous. You send a request, you wait for a response. As opposed to other protocols where you can send data in rapid succession over the same connection without waiting for a response to your previous data. Note that HTTP/2 is more along those lines actually.
Having said that, you can send multiple independent HTTP requests in parallel over separate connections. There's no "global" lock for HTTP requests, it's just a single HTTP request/response per open connection. (And again, HTTP/2 remedies that limit.)
Now, from the point of view of a Javascript application, an HTTP request is asynchronous. Meaning, Javascript will send the HTTP request to the server, and its response will arrive sometime later. In the meantime, Javascript can continue to work on other things, and when the HTTP response comes in, it will continue working on that. That is asynchronous Javascript execution. Javascript could opt to wait until the HTTP response comes back, blocking everything else in the meantime; but that is pretty bad, since an HTTP response can take a relative eternity compared to all the other things you could get done in the meantime (like keeping the UI responsive).
Asynchronous means, you do an HTTP request, but you are not waiting until the answer arrives. You will handle it, when it arrives and are free to do other stuff in between. Meaning: You are not blocking your application from doing anything else.
Synchronous on the other Hand means, you do a request and wait for the answer before you do anything else. Meaning: You are blocking your application from doing anything else.
In microservice architecture, It is suggested that:
client app to API gateway communication should be synchronous (like
REST over http).
API gateway to micro-service communication should also be
synchronous
But service to service communication should be asynchronous.
Another rule you should try to follow, as much as possible, is to use
only asynchronous messaging between the internal services, and to use
synchronous communication (such as HTTP) only from the client apps to
the front-end services (API Gateways plus the first level of
microservices).
https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/asynchronous-message-based-communication
Now, If I understood it right, when user requests to API gateway, and in turn it calls the fist service, it will return a acknowledgement (with some GUID) which will be passed to client application. But services will keep on executing the request.
Now the question pop ups, how will they notify the client application when the request is processed completely. One way is that client can check the status using the GUID passed to it.
But can it be done with some push notification? How can we integrate server to server push notification?
I have little bit different understanding on this as it says communication between services should be asynchronous while communication to API gateway and API gateway to service should be rest API.
so we don't need to do anything as these are simple API calls and pipeline will handle request-response tracking while asynchronous calls between services will increase the throughput of the service.
Now, If I understood it right, when user requests to API gateway, and in turn it calls the fist service, it will return a acknowledgement (with some GUID) which will be passed to client application. But services will keep on executing the request.
No, the microservices should not continue to execute the request, it is already finished. They will, when it is required, update their internal cache (local representation to be more precise) of the needed remote data (data from the microservice that executed the request) when that remote data has changed. The best way to do that update is using integration events (i.e. when a microservice executes a request that mutates the data, it publishes an event to the subscribed microservices).
The microservices should not communicate not even asynchronously in order to fulfill a request from the gateway or clients. They should use background tasks to prepare the data ahead of time for when a request comes.
You're depicting a scenario where the whole interaction between the system and external actors (to be rude, the users) follows an asynchronous model. This is perfectly reasonable, but just if you really need it. Matter of fact, if you are choosing to let 'the outside' interact with your system through REST APIs, maybe you don't need it at all.
If the system receives requests through a synchronous application endpoint, such as REST endpoint, it has to complete requests before to send a response, otherwise it would be meaningless. consider an API like
POST users/:username/notifications
a notification is synchronous by it's nature, but the the request just states that 'a new notification should be appendend to the notifications collection of user'. The API responds 201 that means 'ok, the notification is already associated with the user, it will be pushed on some channel, eventually'. This is a 'transactional' way to describe an asynchronous interaction
Another scenario comes when the user wants to subscribe the notification channel. I expect that this would be implemented with a bi-directional, asynchronous, pubsub communication protocol, such as websockets.
In both cases, however, doesn't matter how microservices communicate with each other, if the request is synchronous, the first service of 'the chain' should wait until is ready to respond. This is the reason beacause API gateway forwards the request in http.
On the other hand, aynchronous communication could be used to enforce consistency between services, instead of to make the actual communication. Let's say that the Orders service sends data to a broker. each time some attribute on the orders[orderId] is changed, it published the change in /orders/:orderId topic. At the same time, expose an internal http point. each service caches data from the services which depends on. The user service make a GET /orders/:orderId , while sends a response to the requester, puts the data in a local cache and subscribes the orders/:orderId topic. each time that a 'mutation' is sent on this topic, the User service catches it and applies the mutation on the corresponding cached object. The communication is syncrhonous, keeps to be synchronous and it' relatively simple to manage; at the same time your system can hold replicated data and be still [eventually] consistent
I'm implementing a distributed system for a project and am a bit confused as to how I should properly implement the Req/Res pattern. Basically I have a few endpoints that will send a request to a client for processing tasks and responding.
So basically:
Incoming request is received
The endpoint opens a req and res socket type with the broker
Broker receives the request, proxies it to an available worker
Worker responds and the endpoint receives the processed value, reports it back via the endpoint.
I've found a decent load balance broker script here: http://zguide.zeromq.org/js:lbbroker. There's also an async client/server pattern I'm interested in implementing: http://zguide.zeromq.org/js:asyncsrv which I might adapt into a load balanced implementation.
My question is perhaps a bit simplistic but, would each endpoint open a new socket on EVERY request or maintain and open socket for every request? That means there would be n connections for every request made to the endpoint.
You'd keep the sockets open, there's no need to close them after each request. And there'd be a single socket one every endpoint (client and server). At the server end you read a request from the socket, and write your response back to the socket; zmq takes care of ensuring that the response goes back from the right client.
This is a first server-side swift framework available now. I am interested to use it for high traffic mobile app server.
Does this swift based framework implement the non-blocking I/O http server?
Yes, the internal networking in Perfect is all non-blocking. This is the case if you are doing raw TCP comms., using the built-in HTTP server or the FastCGI server. Check out the NetTCP and NetNamedPipe classes. They take callbacks when you connect, accept, read or write data. All of the relevant functions take a timeout parameter as well. You can optionally accept custom server connections in a blocking loop.
The individual web handlers are non-blocking as well in that you call a callback to tell the system that you are done with the request. The system will complete the current request and await others utilizing keep-alive.