Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃巵 simpler API #242

Open
3 tasks
katzIdo opened this issue Mar 17, 2020 · 1 comment
Open
3 tasks

馃巵 simpler API #242

katzIdo opened this issue Mar 17, 2020 · 1 comment

Comments

@katzIdo
Copy link
Collaborator

katzIdo commented Mar 17, 2020

General description

Scalecube requires a lot of setups to start

  • when bootstrapping a microservice container the service definition can be optional.
    when it's not passed then all the reference<->definition validation should be skipped,

instead of createProxy we should use getService
which get

type getService = (qualifier : string) => ServiceInvokation

interface ServiceInvokation {
  subscribe: ()=> Observable<any>
  then: () => Promise<any>
}

API

Design description

A clear and concise description of the design proposition.

  1. Is it a breaking change (not backward compatible)? no
  2. Is it adds new API? yes
  3. Is it changes existing API? yes
  4. Is it removes existing API? yes

Changes

old

interface Service {
  /**
   * @property
   * The metadata for a service, that includes the name of a service and the map of methods that are
   * included in it
   */
  definition: ServiceDefinition;
  /**
   * @property
   * The implementation of a service, that can be an object with methods or a module with a function being exported
   */
  reference: ServiceReference;
}

interface Microservice {
  /**
   * @method destroy
   * The method is used to delete a microservice and close all the subscriptions related with it
   */
  destroy: () => Promise<any>;

  /**
   * @method createProxy
   * Creates a proxy to a method and provides extra logic when is invoked
   */
  createProxy: CreateProxy;

  /**
   * @method createServiceCall
   * Exposes serviceCall to a user (not via Proxy)
   */
  createServiceCall: CreateServiceCall;
}

new

interface Service {
  /**
   * @property
   * The metadata for a service, that includes the name of a service and the map of methods that are
   * included in it
   */
  definition ?: ServiceDefinition;
  /**
   * @property
   * The implementation of a service, that can be an object with methods or a module with a function being exported
   */
  reference: ServiceReference;
}

interface Microservice {
  /**
   * @method destroy
   * The method is used to delete a microservice and close all the subscriptions related with it
   */
  destroy: () => Promise<any>;

  /**
   * @method getService
   * Creates a proxy to a method and provides extra logic when is invoked
   */
  getService: GetService;

  /**
   * @method createServiceCall
   * Exposes serviceCall to a user (not via Proxy)
   */
  createServiceCall: CreateServiceCall;
}

Behavior

Consideration

List of everything to consider before writing test cases.

Test cases

Add test case that are written in Gherkin Syntax and cover all the possible scenarios.

DoR

  • API has been approved
  • Test cases have been prepared
  • Discussed with Technical lead
@idanilt
Copy link
Contributor

idanilt commented Mar 13, 2021

@katzIdo
I don't think it should be instead, it should be in addition
Actually, the current API of SC has two methods createProxy and createServiceCall
createServiceCall is similar to what you are suggesting:

ms.createServiceCall().requestStream(Message).subscribe(...);
ms.createServiceCall().requestResponse(Message).then(...);

I suggest leaving the old API as is and add:

interface ServiceInvokation {
  then: ServiceCall.requestResponse.then,
  subscribe: ServiceCall.requestStream.subscribe,
}
interface Microservice {
// ...
  invoke(qualifier: Message.qualifier, ...args: Message.data): ServiceInvokation;
}

But let's leave for now until we have any request

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants