I am hoping to use a grpc-node client to talk to a microservice built in Go using the go-micro framework. I am running into an issue where go-micro defines method names using periods (.) to separate namespaces and method names, whereas grpc-node slashes (/). Is there anyway to configure this pattern to have these two processes talk to each other?
The gRPC over HTTP/2 protocol documentation defines that the path is constructed as follows:
Path → ":path" "/" Service-Name "/" {method name}
with this additional note
Some gRPC implementations may allow the Path format shown above to be overridden, but this functionality is strongly discouraged. gRPC does not go out of its way to break users that are using this kind of override, but we do not actively support it, and some functionality (e.g., service config support) will not work when the path is not of the form shown above.
So, the Node gRPC client is following the specification, and the alternate format used by go-micro appears to be hard coded in their code generation plugin (here). I would consider that to be a bug.
That being said, there is a viable workaround to match that method name format in the Node gRPC library. When you load a .proto file in the Node each client constructor function has a service member which is a plain JavaScript object that describes the service. It is a map of method names to method definitions, and each method definition includes a path member. You can modify the path of each method to match the pattern that go-micro uses, then pass the resulting service object to grpc.makeGenericClientConstructor to get a new client constructor that connects to the modified service.
Related
We're using the Destinations service to configure connections to different kinds of systems. As part of this, we are using the "Additional Properties" section to add non-standard properties, such as my.custom.property=123.
We have successfully used the SAP Cloud SDK's MockUtil to write Spring integration tests that use the files systems.yml and credentials.yml as source for test systems.
However, we couldn't find a way to create an entry there that would provide a test system with a custom property like my.custom.property=123.
The erp section accepts only the properties known for ERP systems, such as sapClient. The general systems section accepts only the absolute basic properties name, type, uri, and proxy. Adding an unknown property in either section results in a runtime error because the mock utils are unable to parse the unknown property into the data classes with fixed structure.
Is there another way to mock a Destination that would allow us to include non-standard properties?
For example, the DestinationAccessorMocker looks promising, as it seems to enable setting up custom implementations of the Destination interface, but we couldn't figure out how to employ it.
Found an option that works.
MockUtil mockUtil = new MockUtil();
MockDestination destination = MockDestination
.builder("my-service", URI.create("http://localhost:1234/"))
.property("my.custom.property", "123")
.build();
mockUtil.mockDestination(destination);
Maybe somebody can confirm that this is an intended way to do this?
I have a group of microservices, called "client-Foo", where Foo is the name for some particular third-party client.
Using those names as-is creates some really ugly endpoint urls, so I want to translate them to a much nicer hierarchal form.
I added a custom PatternServiceRouteMapper that take the serviceId client-Foo and turns it into the url client/Foo.
This gives the url I want, but also breaks the service mapping because it also changes the registered serviceId to client/Foo; thus, when Zuul goes to route it fails because there is no client/Foo service, its id is client-Foo!
I cannot hardcode any paths because the application requires an arbitrary number of different "client-*" services.
By looking at ZuulProxyAutoConfiguration, you can see that you can replace some beans to achieve your goal and in particular you should consider providing your own implementation of RouteLocator interface or extend DiscoveryClientRouteLocator class.
Your service instances could also register in Eureka server with additional data in metadataMap that your RouteLocator could use.
I would simply add a configuration defined Zuul route :
zuul:
routes:
client-foo: /foo/**
Also I would advise against having a dash in a service-id as it can confuse the config server api (in /config/foo-profile.yml where profile is the spring profile for which you want to get the config).
I am wondering if it is possible to configure an Azure Function App to accept a URI-path ID as is typically used in RESTful services, e.g. /api/foo/1, where the function is foo. I haven't been able to find documentation on this and the binding information that I have found suggests that this isn't possible (I don't see a way to map it). It doesn't "just work" with the typical HTTP trigger (which supports /api/foo?id=1). In that configuration one receives a 404 response, I'm guessing because it doesn't know to call the foo function with the ID suffix in the URI.
In case it matters, I'm using C# to write my function.
You are correct that URI parameters are not supported at this time. If you'd like, you can create a feature suggestion for this here in our repo. Thanks :)
I have a few private apis written in plain old express. Time to let it out and provide some api documentation.
What I don't want (at least yet) it to re-write my express app to integrate api documentation into the code. Mainly since I am not sure what framework or spec to use to document my api I don't really want to be locking into one particular thing.
I would like to serve out the doc as part of a sub resource under my api (ie I do not want to run a different server or subdomain). Maybe '/api/docs'. A plus would also be a UI that I could embed within my app that could parse the docs and at the very least provide a nice presentation of the docs in html (api interaction is a plus).
Things like swagger-node are cool, but would require me to re-write all my express code to integrate swagger. At that point I have a big investment and am tightly coupled to swagger.
Is there a way to serve out swagger or iodocs or maybe something else to document my api in a way that is minimally invasive to existing routes?
EDIT:
I could serve out the Swagger spec from a hand written doc. Problem I see is that you have to define basePath in the swagger doc. This does not really allow me to easily deploy under different domains.
There's a wide array of node.js tools to integrate Swagger with your application, and I assume they offer different ways of doing so. You can find a list of such integrations here - https://github.com/webron/swagger-spec/#nodejs - but I can tell you that there are additional tools out there that are not listed there. You can try searching github for swagger and node/express.
As for the manual spec and the basePath - Swagger 2.0 actually solves that for you. You can use the online editor - http://editor.swagger.io - to write your specs in a more human-friendly YAML form, which then you can export to JSON.
Unlike Swagger 1.2 and previous versions, the basePath is now split into three properties - schemes (http, https), host (domain, port) and basePath (the root context of the application). None of these properties are mandatory, and they all default to whatever is serving the swagger.json file (the spec itself). schemes defaults to the scheme service the swagger.json, host defaults to the host used for serving the swagger.json and basePath will be \ unless explicitly specified. I believe this should solve your concerns regarding the basePath.
The Problem
I'm aware of the basic way to create a route/endpoint in ServiceStack using methods with names like "Get", "Post", "Any", etc inside a service but in the particular case that I'm trying to work with I have an existing service (which I can make an IService via inheritance) that can not be retrofitted w/ServiceStack attributes and currently uses DTOs for the requests and responses.
This service contains many functions that I do not want to manually mask (as this is a pass-through layer) but otherwise already conform to ServiceStack's requirements. What I'm wondering is if there's a way to manually create these routes in a way that would work like I've mocked up here. My existing functions and DTOs already contain the information I would need to define the routes so if this approach is possible it would only require me to enumerate them at initialization time as opposed to generating the services layer manually.
I noticed there is an extension method on Routes.Add that takes an Expression of type Expression> but I was not able to get that working because I believe the underlying code makes assumptions about the type of Expression generated (LambdaExpression vs MemberExpression or something like that). I also may be barking up the wrong tree if that's not the intended purpose of that function but I can not find documentation anywhere on how that variant is supposed to work.
Why?
I'm not sure this is necessary but to shed some light on why I want to do this as opposed to retrofitting my existing layers: The current code is also used outside of a web service context and is consumed by other code internally. Retrofitting ServiceStack in to this layer would make every place that consumes it require ServiceStack's assemblies and be aware of the web service which is a concern I want separated from the lower code. We were previously using MVC/WCF to accomplish this goal but we want some of the features available from ServiceStack.
the current architecture looks like this:
data -> DAL -> discrete business logic -> composition -> web service
Hopefully that makes enough sense and I'm not being obtuse. If you would like any more details about what I want to do or why I'll try to update this post as soon as possible.
Thanks!
You might use the fallback route in order to provide your own routing mechanism.
Then you get the request.Path property and route using your own mapping of path:Function which can be stored in a simple dictionary.
Anyway, if you go this path I don't see much benefit in using servicestack. It seems you just need an http handler that routes requests to existing services.