[Spike] Weakly typed integration with REST/SOAP service

[dhmlau]

Weakly typed integration - runtime integration

What's involved

• configure DataSource pointing to the service spec (service metadata) / endpoint (URL to talk to).
• create service proxy for typescript developers. i.e. collection of methods you can invoke without any type checking. Checking only happens at runtime.
• Have base class for service that can declare dependencies on DataSource. The service instance will used in the controllers.
• In LB3, we have a dummy model that associates with the datasource that functions as service proxy. In LB4, we want to get rid of that dummy model.

Questions to answer

Quick spike/ PoC (1 or 2 days)

• create a base service class and declare dependencies on DataSource (configure to use REST/Swagger connector)
• implementation will be delegated to the juggler implementation
• Can reuse REST connector example as the user scenario
• Also consider Proxy in JavaScript: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy

Coming from discussion with @raymondfeng

[raymondfeng]

See an early PoC at https://github.com/strongloop/loopback-next/tree/service-proxy

[bajtos]

IMO, the pull request #1119 is only a part of the overall story. While it makes it easy to consume services in controllers, it omits other important use cases.

For example, when consuming a service using rest-connector with template-based configuration: as an app developer, I would definitely want to have few smoke tests to verify that my templates work as intended and match the API provided by the service at the other side. I would like to write an integration test that's using only the service (not the full app!), something along the following lines:

import {GeoService} from '../services/geo.service';
import {expect} from '@loopback/testlab';

describe('GeoService', () => {
  let service: GeoService;
  beforeEach(() => service = new GeoService());

  describe('geocode', () => {
    it('returns geo coords for a given address', () => {
      const result = await service.geocode('107 S B St', 'San Mateo', '94401');
      // { lat: 37.5669986, lng: -122.3237495 }
     expect(result.lat).approximately(37.5669986, 0.5);
     expect(result.lng).approximately(-122.3237495, 0.5);
    });
  });
});

There should be also a new CLI command for creating services, this command should:

• Create the datasource.
• Create any artifacts needed to register the service with the app for dependency injection. This may require us to implement support for services in @loopback/boot.
• Create any artifacts needed to write an integration test for the service as I shown above.
• Ideally, include a scaffolding making it easier for app developers to start writing smoke tests.

[dhmlau]

@raymondfeng , the spike seems to be done. Is this good to close? thanks.