Selenium Grid - Architecture

Selenium Grid is developed as a group of components with each component performing its own tasks so that the Selenium Grid works as a unit. The working of individual components may sound a bit complicated. The latest version of Selenium Grid 4, is developed without leveraging the code base of the older versions of the Selenium Grid.

Components of Selenium Grid

The key components of Selenium Grid are listed below −

Event Bus − A Event Bus is used to convey messages which may be obtained asynchronously among the other components.
Distributor − A Distributor keeps a track of every accessible resource in the Selenium Grid which can be utilized to start a session(as called the slots) and take up new inward requests and give it a slot.
Node − A Node is used to execute a webdriver session. Every session is provided a slot and a Node may or may not have multiple slots.
Session Map − A Session Map maintains a relation between the session id and the location of the Node where the session is running.
New Session Queue − A New Session Queue stores the list of incoming sessions which do not have a Node given by the Distributor.
Router − A Router is as if the face of the Selenium Grid and exposed to the web. A Router directs the incoming requests either to the New Session Queue or to the Node where a session is going on.
Slot − A slot is a location where a session can execute. A slot should have some minimum features which a new session request should match so that the Distributor can dispatch that request to a Node having a slot.
Grid Model − A Grid Model describes the way the Distributor keeps a watch on the performance of the Selenium Grid.

Communication Methods Among the Components

The communication methods among the components in the Selenium Grid are listed below −

Synchronous JSON over HTTP requests.
Asynchronous events dispatched to the Event Bus.

In the scenarios where the task being done is synchronous, or if misplacing a response would be difficult, a synchronous communication is done. However, in the scenarios where only broadcasting information is being carried out, or if misplacing a response is fine, an asynchronous communication is sent to the Event Bus.

Dependencies Among the Selenium Grid Components

Any Selenium Grid component can begin in any order, however ideally the components start in the below sequences −

The Session Map and the Event Bus begin at the first. They are independent of each other and can work simultaneously.
Next, the Session Queue takes part.
Next, the Distributor can come into picture. It will connect with the Session Queue at an interval and poll for the jobs. The polling can be done either in an interval or by an event.
At this point, the Router can be kicked off. The New Session request is sent to the Session Queue, and the Distributor will try to search for a slot to execute the session.
Next, the Node can be started. Once Node registration is done, Selenium Grid can work with traffic.

	Event Bus	Distributor	Node	Router	Session Map	Session Queue
Event Bus	No
Distributor	Yes	No	Yes			Yes
Node	Yes		No
Router			Yes	No	Yes
Session Map					No
Session Queue	Yes					No

The above table shows the dependencies among the components, where Yes reflects there is a presence of synchronous dependencies between the components.

How is Node Registration Done in Selenium Grid?

The entire process of Node registration is a light weight process. When a Node becomes active, it should release a ‘heart beat’ event on an interval. This gives an idea of the status of the Node.

The Distributor listens to the ‘heart beat’ events. As it receives the ‘heart beat’ events, it tries to GET the /status endpoint of the Node. This information is used to configure the Selenium Grid. This check performed by the Distributor is done in a methodical manner. However, the Node should always dispatch the ‘heart beat’ events even after it has begun working. This is done so that the Distributor can be resumed without a consistent store of the status of the Selenium Grid.

Fields in a Node Status Object in Selenium Grid

The Node Status is received as a JSON object with the below fields −

Name	Type	Description
availability	string	Can be one of three string values - up, draining, and down. The most common one is draining which says that no new session should be directed to the Node, and that once the previous session on it is done, the Node shall terminate or restart.
externalUrl	string	The Url that every component in the Selenium Grid should contact.
lastSessionCreated	integer	The epoch timestamp of the last session of the Node. The Distributor tries to direct new sessions to the Node that is not in use for the longest duration if all the other parameters are similar.
maxSessionCount	integer	This integer value suggests the maximum number of sessions that should be running in parallel on the Node prior being considered as full.
nodeId	string	A UUID used to identify this object of the Node.
osInfo	object	An object having either of the three fields - arch, name, and version. These are used by GridUI and GraphQL queries.
slots	array	Slot objects array
version	string	The Node version

It is a good practice to set values in all the above fields.

Slot Objects in Selenium Grid

A Slot Object points to one slot inside the Node. A particular session can run within a slot. The fields in the Slot Object are listed below −

Name	Type	Description
id	string	A UUID is used to identify a slot.
lastStarted	string	This indicates the time when the last session had begun in ISO-8601 format.
stereotype	object	The minimum group of capabilities that a slot should have. For example: {"browserName": "chrome"}
sessionObject	object	Indicates the Session object.

Session Objects in Selenium Grid

The Session Objects are used to refer to a current session inside a slot. The fields in the Session Object are listed below −

Name	Type	Description
capabilities	object	The correct features given by the session.
startTime	string	This indicates the beginning time of the session in the ISO-8601 format.
stereotype	object	The minimum group of capabilities that a slot should have. For example: {"browserName": "chrome"}
uri	string	The Node uri to interact with the session.

This concludes our comprehensive take on the tutorial on Selenium Grid - Architecture. We’ve started with describing what are the key components of Selenium Grid, what are the communication methods, and dependencies among these components, how Node registration is done, what are the fields in the Node Status Objects, Slot Objects, and Session Objects in Selenium Grid.

This equips you with in-depth knowledge of the Selenium Grid Architecture. It is wise to keep practicing what you’ve learned and exploring others relevant to Selenium to deepen your understanding and expand your horizons.