Gateway use and Dtos from the other service

I have service 1 and service 2

Service 2 is configure with:

Container.Register<IServiceGateway>(c => 
    new JsonServiceClient("http://localhost:5000"));

So in my Interface project of service 2, I use Add ServiceStack Reference and point to my Service 1
All good… Except When I start my service 2, now In my metadata it’s seem that I can call all my request from service 1.

My service look like:

using ServiceStack;
using ServiceStack.OrmLite;
using SSRabbit2.ServiceModel.Person.Request;
using SSRabbit2.ServiceModel.Person.Response;
using SSRabbit2.ServiceModel.Person.Types;
using SSRabbit.ServiceModel.Addresse.Request;
using SSRabbit2.ServiceModel.Person;

namespace SSRabbit2.ServiceInterface.Person
    public class PersonServices : Service
        public object Get(CustomersRequest request)

            var result = Db.LoadSingleById<Customer>(request.Id);
            if (result is null)
                throw HttpError.NotFound("Customer");
            var response = new CustomersResponse { Customer = result};
            if (result.AddressId.HasValue)
                //csharp-ref http://localhost:5000 Address or Add ServiceStack Reference
                var addr = Gateway.Send(new AddressesRequest { Id = result.AddressId.Value });
                response.Address = addr.Adresses.ConvertTo<Address>();
            return response;


The funny thing, AddressesRequest is not listed and that’s the one I use from CustomersRequest:
When I import my Service in PostMan the Circle one does not belong to Service 2
Anyway to Exclude the circle one ?

The Service models you’re referencing are leaking into your Services contract.

If you don’t want them to appear, none of the imported Service Models Types should appear (or be returned) anywhere in your Service Responses.

The [ExcludeMetadata] attribute can be used to hide a Type from appearing in the metadata services however this is masking a symptom which may cause build errors from clients consuming your Add ServiceStack Reference DTOs since it’s likely referencing a Type that you’re trying to hide. If you don’t want them in your Services contract, don’t have any references to them in your DTOs or Service responses.

Forgot to mention, SearchXXXX are AutoQuery so I need to Reference the Type

public class SearchAddresses : QueryDb<Address> { }

OK in my address.dtos.cs file I exclude the following types

ExcludeTypes: SearchRegions,SearchAddresses,SearchContinents,SearchCountries

1 Like

If you don’t need them that would be the cleanest solution. Otherwise you can put the generated DTOs in a different assembly so they’re not in your AppHost Service Assemblies and included in your AutoQuery Services.

I need to think further cause I try to build a MicroService Architecture prototype
generated dto’s spread in many MicroService site will mean difficulty to update one MicroService at a time…

Form service to service I will have different generated dto’s files event if they call the same microservice…

Should I Nuget Package Service.Model.dll and reference them, not sure.

Start with a monolith, only separate them into separate Microservices when you can realize tangible benefit from doing so. Either case the Service Gateway which will allow you to “design for Microservices” whilst keeping them in the same monolith deployment unit whilst making it easy to decouple them into separate Microservices if you need to in future.

Here are a couple of my existing posts on the subject that may provide some more insight.

1 Like

Yes I agree with Monolith first…
We have start new Apps in VueJS + quasar. So we have a site (IIS) for the UI and another site for the REST API (ServiceStack). VueJS use JavaScript client… I will soon test the JavaScript with our php team…

We have different database from different system not in SQL but they have the tools to integrate with .Net.

So I can start with different Service .dlls so I isolate the different DB in different dll. Then I split then monolith…

1 Like