Integration of services with controllers (technical preview)

[b-admike]

Description

Explore how service integration works with controllers. This task is an outcome of #1069.

Use case

A controller needs to invoke a REST API or SOAP web service.

export class ShoppingController {

  @serviceProxy('pricingService')
  private pricingService: pricingService;

  @serviceProxy('shippingService')
  private shippingService: ShippingService;
}

Or

export class ShoppingController {
  constructor(
    @serviceProxy('pricingService')  private pricingService: pricingService,
    @serviceProxy('shippingService') private shippingService: ShippingService
  ) {}
}

We'll configure two datasources and bind them to the context.

• pricingService: REST API
• shippingService: SOAP Web Service API

context.bind('dataSources.pricingService').to(...);
context.bind('dataSources.shippingService').to(...);

Acceptance Criteria

• Controllers can use @serviceProxy decorator for constructor parameters or properties to inject a service proxy for backend services
• The service proxy can be resolved from data source name or instance
• The service proxy can be optionally typed with a hand-written TS type/interface

[raymondfeng]

See https://github.com/strongloop/loopback-next/blob/970524567a15f1162bc244f060eb602b7647f9c5/packages/service/test/unit/decorators/service-proxy.decorator.unit.ts

[shimks]

@raymondfeng Could you update the acceptance criteria for estimation? Thanks

[raymondfeng]

@shimks Updated

[virkt25]

Is the Service assumed to be created using LB3 constructs? (strong-remoting / strong-soap)?

[b-admike]

Looking at the PR we have for the weakly typed service integration spike, we already have the serviceProxy decorator and have a test using it with a controller as shown above. What else do we need to for this ticket?

Is the Service assumed to be created using LB3 constructs? (strong-remoting / strong-soap)?

Yeah I think so (see https://github.com/strongloop/loopback-next/pull/1119/files#diff-acfd88705f55f0e2f6831937a276b7fbR19).

[raymondfeng]

The PR is feature complete and ready for review.

[bajtos]

Cross-posting from #1069 (comment):

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.

1] 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);
    });
  });
});

2] 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.

[shimks]

@bajtos Although I agree that what you're proposing should be done as an outcome of the spike, IMO this is out of scope for what we have estimated and I feel that it should live in its own issue to be estimated and groomed.

[dhmlau]

PR: #1119

[bajtos]

@shimks you are right, I agree scope creep is bad. At the same time, I don't want us to release a half-baked feature that's difficult to use.

I am going to:

• Update the title of this issue to say it's a "technical preview"
• Create a story to address testability - see Make services easy to test + docs #1311
• Create a story for a CLI command - see CLI: a command to create a new service #1312

[shimks]

@raymondfeng Is the (technical preview) feature complete? If so, can you close it please?

[bajtos]

Closing as done.