directConnect:true vs starting seleniumServer at some port in Protractor

Question

I am using Protractor for end-to-end Testing with non-angular app.
So Once I have written in protractor.conf.js file as-

exports.config = {
      directConnect: true,

      // Capabilities to be passed to the webdriver instance.
      capabilities: {
        'browserName': 'chrome'
      },

      // Framework to use. Jasmine is recommended.
      framework: 'jasmine',

      // Spec patterns are relative to the current working directory when
      // protractor is called.
      specs: ['example_spec.js'],

      // Options to be passed to Jasmine.
      jasmineNodeOpts: {
        defaultTimeoutInterval: 30000
      }
    };

Then it works fine for me.
After that I have made some changes like-

exports.config = {
      seleniumAddress: 'http://localhost:4444/wd/hub',

      // Capabilities to be passed to the webdriver instance.
      capabilities: {
        'browserName': 'chrome'
      },

      // Framework to use. Jasmine is recommended.
      framework: 'jasmine',

      // Spec patterns are relative to the current working directory when
      // protractor is called.
      specs: ['example_spec.js'],

      // Options to be passed to Jasmine.
      jasmineNodeOpts: {
        defaultTimeoutInterval: 30000
      }
    };

Then It start with selenium server with port and test cases run successfully.

So My Question is that- What is the diffrence between both the ways? I know when we use directConnect:true, it does not start selenium server, then use chrome driver directly, and test cases run faster than other way?

When protractor can do testing without selenium server, why we need it? What selenium server do in protrator testing?

Answer 1

As you said with directConnect:true Protractor communicates directly with the Drivers of Chrome and Firefox (any other browser will return errors).

The main advantage of directConnect:true seems speed. Test start up and run faster.

On the other hand Protractor mentions for the Selenium Server this:

The server can handle multiple scripts in different languages. The server can startup and manage multiple browsers in different versions and implementations.

Protractor most certainly doesn't want to constantly maintain these possibilities for a directConnect:true as it's not the main purpose of Protractor and they could do it only worse than a SeleniumServer.

Services for Cross-Browser-Testing, such as BrowserStack and SauceLabs, offer their own SeleniumServers, which should be connected to use their services. To convince them to offer a separate Protractor solution also seems kind of senseless, especially as SeleniumServer is already widely common.

Overall I'd consider it a service of Protractor, that they offer a directConnect possibility as a simplification to start with Protractor. Using SeleniumServer would be the more logical solution and offers a wider range of possibilities, such as cross-browser-testing.

I don't see (and never heard of) more magic than this behind it all.