I don't know if what I'm asking is possible. But I have several APIs with about 100 endpoints in total. We are configuring the APIs to use Ocelot Gateway and I was wondering if there's an efficient way to generate the ocelot.json downstream settings. Since we already have the swagger docs generated, is there a library/package which we can use to generate the downstream URLs using the swagger docs?
MMLib SwaggerForOcelot extension provides a better way to literally document your downstream endpoints. They use a key to identify the APIs within the ocelot files. You can also refer to this article.
Related
We have few existing rest apis written in spring boot to fetch different data in our project? Now we are exploring options to use GraphQL. But we don't want rest endpoints & response to change since it is being consumed by many UI/backend applications. Can anyone suggest proper way to use GraphQL within existing API without changing rest endpoints and Response type?
Consider the following scenario:
I have a custom GoLang library that integrates with different micro-service.
Each micro-service is also integrating with prometheus and exposes respective /metrics endpoint where all the prometheus metrics are visible.
What would be the best way to publish custom metrics from my custom library to make sure that these are visible on the /metrics end point of the service?
One way to do it would be to the official prometheus golang package directly inside of custom library, register the collector with the Default register (that is a package level variable). This way we can publish metrics from our custom library, and those metrics will be available to service to expose at /metrics endpoint.
However, this seems to be bit of an anti-pattern since the service as well as the custom library will be accessing the same package level variable.
I checked through some other popular libraries like Spanner
which seems to be following the same approach when publishing traces through openconcensus.
Is there a better approach out there for the same?
I am using AWS API Gateway and would like to construct multiple API's for a set of Spring Boot micro-services that exist behind the scenes, but do so automatically.
For example, lets say I have a User and Contract Micro-service and they expose a simple CRUD, I would like to make 2 API representations inside the API Gateway for these 2 micro-services however they will be in the context of an Admin and a User.
The Admin API would have full access to all operations (CRUD) of both micro-services, however, the User API would only allow Read from both micro-services.
My question is about maintaining the representation of these 2 API contexts (Admin and User) is there any way to easily generate the swagger(s) that I would need that I can synchronize the API Gateway with without having to manually maintain this? Or is there a better approach that others are doing that im missing?
I have found spring fox which I was able to use and generate the swagger defs for the API at the microservice levels, but this only satisfies the Admin Use case and not the User one from what I can tell.
Has anyone found an elegant solution to this?
I saw in many tutorials that we need to go back to gateway and generate an entity after generating a microservice application with the same entity.
Can someone explain me, the architectural benefits of doing so?
What is the goal of generating those entities again in Gateway?
One of the points of doing that is to implement the Backend for Frontend pattern.
Basically you proxy all calls from your front-end to your microservices through the gateway. For convenience reasons the frontend is packaged together with the gateway.
JHipster just adapted the exisiting entity generators from monoliths to let users generate the backend and front-end of an entity separately on microservices and gateways respectively. Of course this is an optional feature and you are free to use it the way you want.
You can use different ways for different purposes to reach the service a microservice is offering to you. As mentioned here you don't have to use AngularJS or Angular, but you can also use React and/or Ionic.
In general you can use more than one gateway to all or only a choice of microservices per gateway (a very good example implementing different gateways is shown here).
We have a web application using Jersey and Spring's rest template. Does anyone know of a tool that can scan a code base and produce a report that lists all exposed endpoints and also internal references to those endpoints?
You may also take a look at Swagger, a framework for describing, producing, consuming, and visualizing RESTful web services.
Swagger supports multiple REST frameworks and also JAX-RS based on Jersey.
From their GitHub Wiki:
The Swagger framework simultaneously addresses server, client, and documentation/sandbox needs for REST APIs. As a specification, it is language-agnostic. It also provides a long runway into new technologies and protocols beyond HTTP.
With Swagger's declarative resource specification, clients can understand and consume services without knowledge of server implementation or access to the server code. The Swagger UI framework allows both developers and non-developers to interact with the API in a sandbox UI that gives clear insight into how the API responds to parameters and options. Swagger happily speaks both JSON and XML, with additional formats in the works.
Jersey can provide a WADL report at the /application.wadl URI. It doesn't document complex types but at least gives you a list of endpoints.
See https://wikis.oracle.com/display/Jersey/WADL