how to register new client-ids and subscription (with open source version)

[rohgoyal]

Hi, I have downloaded the open source version of Microgateway and created a Swagger yaml with SecurityDefinitions

securityDefinitions:
  clientIdHeader:
    type: apiKey
    in: header
    name: X-IBM-Client-Id

I was able to call the API with following curl command
curl http://localhost:3000/trial/echo -H "X-IBM-Client-Id:default"

I wanted to find out how can I register more specific client ids with Microgateway?

[ozairs]

If you wanted to manually create subscriptions, you could use the following repository: https://github.com/strongloop/microgateway-datastore and modify the code as a custom datastore and include it within your package.json (default one contains microgateway-datastore as a package dependency)

[rohgoyal]

Thanks ozairs. We do have APIc on-prem installed as well and running number of DataPower API gateways. Can you guide to best place/documentation that explains how we can install/configure a Microgateway with existing APIc cloud?

[ozairs]

You need to associate the microgateway to the catalog (using the standalone option and NOT collectives). In the API Manager settings -> gateway URL, specify the microgateway as the endpoint.

[rohgoyal]

Thanks Ozairs. Can you pass any link that explains HOW TO CONFIGURE Microgateway as Catalog?

Also I am still not sure what is the best way to use a Microgateway?

Option 1: I can design Swagger in API Developer Toolkit and then package it along side Microgateway open source framework available under this Git repo as Docker Image and deploy without worrying about management server.

Option 2: Use it as a Catalog under API management and push API from there.

I am not clear what Option 2 provides that Option 1 can't? Would you suggest anything?

[ozairs]

See https://www.ibm.com/support/knowledgecenter/SSMNED_5.0.0/com.ibm.apic.install.doc/tapic_microgw_add_to_catalog.html and step 6. Ignore the Collective Controller option.

You can use the microgateway in standalone mode (per option 1) when you want to use the 'gateway as a microservice' pattern where its providing gateway capabilities for your microservices. In this case, you don't use it as an API gateway (ie deployed at the edge or ingress point).

In option 2, you are using the Microgateway as the API gateway since your publishing API definitions via the catalog.

I would recommend Option 1 over Option 2.