questions/discussions

[vicpon]

Where is the best place to ask about microdot?

[tsibelman]

For now, this is the best place.

[vicpon]

Okay. May I suggest gitter? https://gitter.im/

So my question is about documentation/support. I'm in the very early stages of implementing a microservices solution and am comparing different things: microdot, orleanka, or a more home grown solution like like the MS eShopOnContainerr sample (https://github.com/dotnet-architecture/eShopOnContainers).

I would really like to use microdot. It looks like you guys have done a great job of building this but I'm a bit wary because it's so new and there isn't much documentation to get started with. Is microdot used in production within gigya? What are the plans for microdot? How many contributors are there? Is it actively being developed or is it waiting for outside contributors to join or show interest?

Thanks

[tsibelman]

Microdot is actively used in Gigya (now part of SAP ) it supports very high scale application in production with dozens of microservices developed on top of it, it constantly evolving you can check release history. We have some documentation in Wiki and we have samples repository you should take a look.

The code base is not very large and not very complex so even if you encounter some bug it would be easy for you to overcome it.

Ultimately you should make a decision that works best for you, you can use Microdot or you can just look at Microdot as a sample and source of ideas for your own solution.

[vicpon]

Thanks for the response. I'll look into the code more and try to understand everything.

[Allon-Guralnek]

Just wanted to add that Microdot is at the core of Gigya's solution and services built upon it are serving paying customers at this very moment. We make changes to Microdot on a daily basis and it is actively maintained.

As far as documentation, we're far behind where we'd like to be. Unfortunately, at this point we can't dedicate as much time as for documentation as it deserves (extremely time consuming task), but I'm hoping this changes in the near future. In any case, if you have any question or need guidance on any topic or subsystem of Microdot, we'll do our best to help you with it. Feel free to ask any questions you have, and mention the most critical parts of the documentation that are missing for you, so we can prioritize them.

[vicpon]

Thank you gentlemen. I really appreciate the quick replies and am hoping microdot becomes widely popular. ++1

[vicpon]

In the sample InventoryService project, the InventoryServiceHost is used as a console application so it uses Source="Local" as the service discovery method. I think the client service discovery would be a priority for me as I would like to implement a polyglot microservices architecture where some of the microservices may not be Orleans/Microdot services. I'm thinking that that this could be accomplished using an HTTP interface to the Microdot service(s).

[Allon-Guralnek]

In order to support certain features such as distributed tracing, host overrides and certain C# language features (such as method overloading), the request to a service uses an "envelope" that contains more than just the parameters to the method, it also contains information about which method to call on which type, tracing and correlation information and more metadata. In order for a non-Microdot client to call methods on a Microdot service, they would have to know the method's metadata (otherwise obtained from the interface assembly that the service publishes to all its clients) and create a compatible envelope (which is not particularly difficult, its simple JSON). Method metadata can be obtained from a metadata endpoint that each Microdot service exposes, or you could write a tool to statically generate that metadata from the interface assembly into your target language and embed it into the client.

A trickier part would be exception serialization which heavily relies on .NET exception types, embedded in the $type JSON property that is used for polymorphism in Json.NET. You may be able to get away with simply deserializing those exceptions into simpler non-exception types on the other side.

At Gigya we do have a Java system that makes very specific calls to a certain Microdot-based service that has an extremely stable API surface, so it can be done. But you'll lose some of the features and the seamless experience which makes Microdot unique.

[vicpon]

Thanks for the high level explanation of how Microdot works. It makes sense that the service API calls are more than the method contract defines given everything Microdot does for you out of the box. I may consider putting one ore more gateways in front of the Microdot services to abstract the envelope and provide simple HTTP contracts to my clients.

[Allon-Guralnek]

At Gigya we have our own API gateway (based on ASP.NET Core) that handles all incoming API requests from the internet at large and translates them into Microdot service calls into our plethora of services. It uses a special feature of Microdot that allows dynamic discovery and dispatch of calls without needing to deploy a new version of the gateway every time a new service is used or its interface changes, instead it queries the aforementioned metadata endpoint of all the services to discover which URLs should be routed to which service methods, all at runtime and responding to any changes immediately without intervention. The metadata is generated by each of the services based on .NET attributes which you use to decorate certain methods in your service that you'd like to make callable through the API gateway.

This API gateway is very Gigya-specific, performing specialized authentication and authorization, so it's not suitable to open-source it at this point (but we're thinking about it). Nevertheless, the dynamic discovery and dispatch is already in Microdot, and you might find it useful if you'll go down that path. Between services there is less of a need for dynamic dispatch, so we still use strongly- and statically-typed interfaces for ease of development allowing cross-service communication at a higher level of abstraction, without concerning yourself with the underlying protocol or serialization used (HTTP and JSON, currently) like you do in an API gateway.

[vicpon]

I am really curious on the dynamic discovery and dispatch of calls feature of Microdot. Would it be possible to add a simple demo in the samples repo?

[daniel-lamberger]

Victor, we've been meaning to open-source dynamic dispatching, we'll try to do so in the next couple of weeks, or at least to provide a code sample. I'll let you know.

[daniel-lamberger]

@victor-ponce Sorry for not getting back to you, we didn't prioritize open-sourcing that part for now. Did you manage to get things going? Need assistance?

[vicpon]

@daniel-lamberger. I took a look at the code but wasn't able to figure it out before I had to move on to something else. I'll have to wait until more examples and documentation area available. Thanks

[sabernar]

Would there be any difficulty using microdot with Docker?