Awesome thx Richard - another provider to add to the Release Notes! Yeah I think a NuGet package would greatly ease the effort to adoption. I’d also include the necessary instructions for downloading/enabling the plugin, e.g:
I’d also include an example of using the base.Gateway and mention that if the Request DTO is implemented internally it will call that otherwise it will query Redis to determine which external Service it should call using a JsonServiceClient instead.
I use an appveyor account linked to my github account to build the repo on commits and it creates a nuget package from a nuspec file, then you just need an nuget api for running a deployment to nuget.org.
Sounds good. I just committed after I pulled it out of my ServiceStack.SimpleCloudControl project (which I’ll also be releasing later, it sits on top of this discovery layer) and did a quick set of sample services.
I’ll improve some of the documentation, plus it is also missing an ExcludeServiceDiscoveryAttribute which I know I’ll need in my production environment (we “proxy” a bunch of services which reuse the DTOs of the internal services they are calling, in these cases we want to make sure we attribute the “gateway” services so they are not picked up as valid entry points).
I’ll take a look at AppVeyor, I have had NuGet packaging on the list of things to explore for a while now, just haven’t had the need until now.
I need an alternative flag because we have a sisuation were I have internal service A, it is called via a “proxy” service on the DMZ which uses the exact same DTO as the internal service (same typename), on the proxy service I would want to mark those DTOs as not discoverable on that node.
I was figuring because my existing implementation is a stand alone attribute I can easily have a a process that at AppHost init can dynamically attribute the DTOs that should be ignored for discovery. For my DMZed proxy situation it would be easiest to just have a method which marks all the exposed services before startup.
I’m all for either of these suggested alternatives, but I’m not sure if I can “append” to existing attributes or how that would work?
I’m going to add a public HashSet<Type> ExcludedTypes property on the feature. I’ll wait to hear what opinion @mythz might have on the attribute situation. I do think a global policy would be best.
One thing I came across which you might want to update is when filtering the metadatatypes which I tidied up into (tested!) extensions methods you might find useful. I also added support for the RestrictAttribute
One question that the RestrictAttribute use raised is how this would work with a couple of scenarios
when a request is restricted to secure but is registering only as http
when requests are restricted to certain formats (xml,csv) etc how to create the correct IServiceGateway client for the request. I’m toying with the idea of creating variable prefixes on the dto tags to denote the format with json being the preferred and default.
@mythz I swear it’s a coincidence but that PR merge puts the nuget package version as 4.0.56!
I’m not sure about [Restrict(RequestAttributes.External)] being ignored by default, I think I was just coding without thinking about it. I’m fairly certain there are plenty of times one would want a DTO discover-able internally but its restricted external.
I am just going to provide a Func<,>FilterTypes that the user can optionally fully filter if required just before building my final cached list.
You do bring up good points about needing an alternative format, HTTPS, etc:
I think it can be done now that I pass the requestType as well to the SetServiceGateway delegate here
At least for the moment this isn’t going to present an issue for me, but I will add some notes about the limitations/assumptions of the current implementation so others might not expect to get too creative with this initial release.