I am using serverless framework to build a REST API. I have reached the 200 limit stack size and read about the multiple approaches to circumvent it. The most common approach is to split the stacks in a "microservices fashion", where each stack handles a particular set of resources that make sense together.
Because of how serverless works each of those services would create a new api gateway for itself and then, as explained in this blog post, a shared domain can be setup between them so all endpoints can be accessed through the same base url.
Even though this is a valid solution I would really like to be able to work with a single API gateway resource shared between the different stacks, so I don't have to decide upfront a separation of concerns between the different components of my api. Is this possible?
This feature has been recently added to serverless. Documentation is available here.
Essentially the apiGateway to be used in a serverless file can be configured through a config option inside "providers".
provider:
...
apiGateway:
restApiId: xxxxxxxxxx # REST API resource ID. Default is generated by the framework
restApiRootResourceId: xxxxxxxxxx # Root resource, represent as / path
This feature was introduced by this pull request and is available from serverless version 1.26.
Related
Bear with me, I am still on training wheels with GCP
Scenario being
I have a Cloud Run instance serving an API (to be consumed internally)
A middleware running on Cloud Compute instance serving an API. This utilises API served by (1)
(2) needs to access (1)
I'm trying to figure out how to discover the internal DNS name or IP, so that the middleware (2) can be configured to access Cloud Run served API (1)
Intention being to create templates (environment config files) so that I can eventually automate the deployment of all layer.
With Cloud Run, you can't know before the first deployment the URL of the service. The pattern is
https://<serviceName>-<projectHash>.<region>.run.app
You can also have optionally a tag at the beginning, but it's not important here.
The bad part is the project Hash can't be calculated before the deployment (or I donc know the hash formula). Thus it's impossible to register in a DNS the URL in advance of the deployment.
However, if you use tools like terraform, you can get, as output, the URL of the service after the deployment and then register it in your DNS, as CNAME (Cloud Run is a managed service, you haven't a static IP).
You can also use the CLoud Run API to request the list of services on a project, pick the service that you want and get the URL of the service (get request to the service API)
A last word before you hit the wall, you talk about internal endpoint. Cloud Run url is public, and public only. Therefore, your middleware need to access to the internet to be able to request Cloud Run.
If your middleware is deployed on the same project, you can set the Cloud Run service ingress to internal to allow only resources from the VPCs of the current project to access to Cloud Run service.
But the URL is still public and you need an internet access to resolve and to access it.
If you don't wanna be bothered by service discovery and constructing the full URL, you can use runsd, a solution that I developed for Cloud Run that allows you to call a service by its name (e.g. http://hello).
Microsoft offers a RESTful API for Azure App Configuration with the documentation at:
https://learn.microsoft.com/en-us/rest/api/appconfiguration/configurationstores/list
I have defined some features using Feature Manager in an instance of App Configuration. When I use the above API, it just gives me a list of App Configuration. I was wondering if there is an API for listing the features defined in App Configuration. I am building a service and I need to be able to query it programmatically.
The key-values present in your instance of App Configuration can be accessed through the data-plane API detailed here. The API docs you linked to are control-plane docs for creating/managing App Configuration instances, rather than working with the data inside of them.
Features in an App Configuration instance are key-values that follow specific conventions detailed here. To work with them programmatically, you can use the key-values API and follow the feature flag conventions for key-values.
I am currently looking at implementing feature toggles using ff4j for our application. We want to have a remote central config app which will hold all the features in it and the applications will talk to this central config app via REST to get the features. We will not be able to leverage Spring Cloud Config or Archaius for this purpose.
I went through the documentation and it seems there is a support for HttpClient (https://github.com/ff4j/ff4j/wiki/Store-Technologies#httpclient). But I couldn't find any sample for the same. Can someone please let me know if I can leverage this method to build my feature store from a REST endpoint. Also, I would appreciate if someone could point me to a sample of this.
This is a common pattern.
A component holds the Administration UI (console) and the REST API. You can call it the "Admin Component". For security reasons It may be the only component to have access to persistance unit (any of the 15 DB implementation available)
For the "admin component" HERE is sample using standAlone spring-bppt application using JDBC DB, and HERE you find a simple web application.
The REST API can be secured using credentials user/password and/or API Key. More information HERE
All microservices access the REST API as clients and request feature store. You will need the dependency ff4j-webapi-jersey2x or ff4j-webapi-jersey1x that hold the client http> Then you can define the store using :
FeatureStoreHttp storeHTT = new FeatureStoreHttp("http://localhost:9998/ff4j");
Warning : Please consider using cache to limit overhead introduce by accessing the REST API at each feature usage. More info on cache HERE
To get started quickly with API Connect, I just want to import a Swagger spec of an existing service and make this service a managed API in API Connect.
API Connect provides an import function for YAML files, but the API can not be tested.
I've seen this scenario several times, so I though it might be useful to have some documentation on this.
When importing a swagger specification, you need to modify a few settings to transform this service definition into an API definition (even though they are quite similar). You need to modify the following parameters:
Schemes https - The Gateway enforces HTTPS
Host: $(catalog.host) - This variable links to the current host (in a certain catalog)
Then, you need to build an assembly. The proxy policy is well suited for building facades, as all content from Headers, Body, etc. is re-routed. For the URL, enter the URL of the endpoint + a context variable that refers to the incoming path, like:
http://example.com$(request.path)
I have created a small video on Youtube to demonstrate the neccessary steps.
We are developing a custom console to manage development environments. We have several application templates preloaded in openshift, and whenever a developer wants to create a new environment, we would need to tell openshift (via REST API) to create a new application based on one of those templates (oc new-app template).
I can't find anything in the REST API specification. Is there any alternative way to do this?
Thanks
There is no single API that today creates all of that in one go. The reason is that the create flow is intended to span multiple disjoint API servers (today, Kube and OpenShift resources can be created at once, and in the future, individual Kube extensions). We wanted to preserve the possibility that a client was authenticated to each individual API group. However, it makes it harder to write easy clients like this, so it is something we plan on adding.
Today the flow from the CLI and WebUI is:
Fetch the template
Invoke the POST /processedtemplates endpoint
For each "object" returned invoke the right create call.