Hey guys,
I’m working on Lagom 1.6 combined with open api support (GitHub - taymyr/lagom-openapi: OpenAPI/Swagger module for Lagom).
I’m wondering why I shouldnt organize my internals in different services (without create a complete new module).
Use case:
My focus is to offer an APIs that is documented by openapi file which can be downloaded by an endpoint of that API to make sure that the doc is always up to date.
A requirement is that we have multiple endpoints that belongs to the same domain and expected in the same service but only a part of that should be external available. Also that documentation should only contains these ones. The endpoints should only be implemented one time.
Following example:
The service offers:
GET /mydomain/stuff/list
PUT /mydomain/stuff/
Additional for openapi:
GET /doc/mydomain/internal/
GET /doc/mydomain/external/
Additionally I want to offer a subset of that API which is public available.
For external purpose only GET /mydomain/stuff/list should be available and documented.
That means there are two gateways: external-gateway and internal-gateway.
Following should work:
GET internal-gateway/mydomain/stuff/list
PUT internal-gateway/mydomain/stuff/
GET internal-gateway/doc/mydomain/ (that contains just the two endpoints above)
external-gateway
GET external-gateway/mydomain/stuff/list
GET external-gateway/doc/mydomain/ (that contains just the only endpoint above)
Generating a documention just based on a service is possible. If you have two services you can have two docs. The combining of the external and internal ones is then very easy. You only need tu use the same implementation but with a reduced interface (or a separated implementation which only use delegation of the methods).
Thats easy if you can use multiple services. But the method to do that (ServiceGuiceSupport::bindServices) is deprecated.
ServiceGuiceSupport (Lagom Services API)…-
How should I implement that without using a deprecated method?
PS: We need that because the exernal available endpoint needs to be much more stable, needs a deprecation process therefore we don’t want to expose all what we have but it should be easy to expose an endpoint if we want that.
Best
Sigurd