We use Nameko at Lystable to encapsulate our core business logic.
Our overall architecture is similar to the one Matt described with a few
We use Flask applications/blueprints to provide the HTTP APIs our client
apps consume which constitutes the `Facade` pattern Matt described. This
stems from a decision made quite some time ago when the http support in
Nameko was still in it's relative infancy. That wouldn't necessarily be the
case if we were faced with the same decision today.
Our Facades / API Gateways are responsible for managing their own resource
definitions and corresponding data. What this means in practice is that
they rely less on direct RPC calls to formulate responses to HTTP requests
and instead maintain a local data store which is kept up to date by
serialising data from lifecycle (state change) events broadcast by the
We also talk quite a lot about Domain services (in the context of Domain
Driven Design <http://domainlanguage.com/ddd/>). Services are considered
either Domain or Utility and each one has a clear remit or mission
statement to help enforce the service boundaries and mitigate the
likelihood of conflating services with logic outside of their
Domain services are responsible for (usually) a number of entities /
resource types, the related business logic and for publishing lifecycle /
domain events for any consequential state changes.
Utility services are used for breaking out more functional compute logic
that can be shared by other services. Examples here include sending email
notifications or centralised scheduling of timed triggers.
We also terminate authentication at the gateway and trust requests made
within the Nameko cluster.
The dependency injection patterns are really powerful and can help simplify
complexity significantly. It also means you're not limited to amqp or http
as transport protocols should you so desire.
Hope this helps.
On 24 March 2017 at 03:18, <email@example.com> wrote:
Thanks for sharing the details. It has given me the fair idea.
Looking forward to auth example.
On Monday, March 20, 2017 at 11:29:47 PM UTC+5:30, Matt Yule-Bennett wrote:
Great question! Would love to see this thread grow.
I can kick it off --
We've been using Nameko in production at Student.com <http://student.com/> for
In our setup we have:
* Domain services, which look after the data and logic related to specific
domains in our business (we do student accommodation, so one service
manages properties and rooms, another handles prices and availability, and
* Facade services, which aggregate several domain services into APIs for a
specific customer (e.g. there is a facade for our website, another for our
content management system)
Facade APIs all RESTful HTTP, and they call the domain services over RPC.
There's a fledgling example that shows this pattern here:
https://github.com/nameko/nameko-examples (note the "gateway"/facade
service still in a PR).
For auth, there are two approaches I've taken in the past:
1. Authenticate at the boundary (i.e. facade) and have domain services just
trust their callers (simple, but weak security)
2. Also generate a JWT that contains permissions/roles for that identity,
and pass that along with every call so each downstream service can perform
its own authorization checks.
We should try to add auth into the example app. The JWT approach sounds
complex but it's actually quite simple.
I've already written about our ops/hosting in this thread
Hope that helps. I'd love to see some other folks adding their experiences
On Monday, March 20, 2017 at 11:28:36 AM UTC, abhinav...@gmail.com wrote:
We have a Django monolith and planning to move to microervices
architecture. We came across Nameko and found it interesting.
Is there list of projects using nameko in production or case studies/
It would be great if any of you can share your experience with Nameko. How
you have architect it? How have you done authentication? etc.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an
email to firstname.lastname@example.org.
To post to this group, send email to email@example.com.
To view this discussion on the web, visit
For more options, visit https://groups.google.com/d/optout.