# Offline meetup notes

**URL:** <https://discourse.nameko.io/t/offline-meetup-notes/142>\
**Category:** googlegroup\
**Created:** [August 18, 2016, 9:57am UTC](https://discourse.nameko.io/t/offline-meetup-notes/142 "2016-08-18T09:57:43Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![mattbennett](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/mattbennett/32/13_2.png) [@mattbennett](https://discourse.nameko.io/u/mattbennett)\
**Post date:** [August 18, 2016, 9:57am UTC](https://discourse.nameko.io/t/offline-meetup-notes/142/1 "2016-08-18T09:57:43Z")

</div>

Hi all,

A few of us who are based in London recently got together in person. It was  
fairly unstructured and we talked about lots of things, but I made notes of  
the topics we discussed in depth.

In the interest of transparency and the wider community, here’s a summary  
of our conversations:

\* AMQP internals:

We talked generally about the AMQP spec (and RabbitMQ’s extensions) and the  
limitations of the nameko implementation. It became clear that our current  
implementation could be more sympathetic to how AMQP is designed:

The biggest problem the QueueConsumer, which is used to share a single  
Consumer between all AMQP-based entrypoints. It would be better if each  
entrypoint had its own Consumer, so that QoS and other settings can be  
applied per-entrypoint or per-entrypoint-type. At the moment, for example,  
it’s not possible to have a QoS of 10 for RPC methods, and a different QoS  
for event handlers, without using two QueueConsumers (which is a clunky  
workaround). This refactor could probably be made without breaking  
backwards compatibility.

We also talked about possibly changing exchange names, routing keys and  
queue names used by the current AMQP implementations. At present they are  
fairly inconsistent, and some improvements could be made by updating them.  
For example, using an RPC exchange per service would make detecting  
“UnknownService” errors easier. Any changes to routing keys, queues or  
exchanges would be backwards incompatible, though.

We also talked about replacing kombu with a more flexible and powerful  
library. Kombu is a general-purpose messaging library that supports  
RabbitMQ as one of many possible backends, none of which we make use of.  
Kombu also doesn’t support some desirable AMQP features, such as connection  
heartbeats. An alternative AMQP library, such as the official one (pika),  
would give us more control.

\* Config:

We decided to accept the recent community proposal of a yaml loader that  
could also read environment variables  
([https://github.com/onefinestay/nameko/issues/223](https://github.com/onefinestay/nameko/issues/223)). We’ll give the proposer  
a few weeks to raise a PR and otherwise implement it ourselves (and give  
attribution).

We decided to remove the ``—-broker`` option to nameko run and provide an  
alternative way to specify configuration options at run time (without a  
configuration file). We reaffirmed a previous suggestion that extensions  
should declare their own configuration options, including registering an  
option for the command-line runner if it’s useful to be able to provide it  
there.

\* Documentation:

We agreed the most important next step would be a reference application.  
This should be something that people can clone, tweak and run as easily as  
possible (e.g. include dockerfiles so no other dependencies are required).  
It should make particular effort to show how to use the nameko test  
utilities, because these are powerful but easiest to understand through  
example.

A fledgling example has been started in  
[https://github.com/nameko/nameko-examples](https://github.com/nameko/nameko-examples). It’s going an ordering system  
for the fictional "Air Ship LTD”.

Services:

Orders:  
- RPC CRUD for Orders/OrderDetails  
- RDBMS Data Store  
- Events: order\_created  
- External dependencies: nameko-sqlalchemy and alembic migrations

Products:  
- RPC CRUD for Products  
- Document Data Store with Redis to demonstrate creation of dependency.  
- Events: handle "order\_created" event and decrease stock

Gateway:  
- HTTP API - Create Order, List Orders, Show order details  
- Async RPC calls to get orders and product details  
- Dependencies: config dependency to prepend domain name to returned  
product images. Showing how to use access config in service code.

[https://hub.docker.com/u/nameko/dashboard](https://hub.docker.com/u/nameko/dashboard) has been created for the  
dockerfiles.

\* Project website:

We spec’d out a draft for this. I need to tidy up the language slightly and  
then will put it in a gist or somewhere for people to see. We’re also  
searching for a designer to make it look pretty. It’ll be hosted at  
[http://nameko.github.io](http://nameko.github.io) and replace the basic page there.

\* PRs:

We went over all the outstanding (and old!) PRs and discussed next and/or  
final steps. Some have been cleaned up already, others are waiting for an  
agreed next step.

---

<div class="post-metadata">

**Author:** ![Jesse\_Pollak](https://avatars.discourse-cdn.com/v4/letter/j/b5a626/32.png) [@Jesse\_Pollak](https://discourse.nameko.io/u/Jesse_Pollak)\
**Post date:** [August 22, 2016, 10:09pm UTC](https://discourse.nameko.io/t/offline-meetup-notes/142/2 "2016-08-22T22:09:58Z")

</div>

Thank you for documenting and sharing this! We really appreciate it at Clef  
🙂

> **···**
>
> On Thursday, August 18, 2016 at 2:57:43 AM UTC-7, Matt Yule-Bennett wrote:
> 
> > Hi all,
> > 
> > A few of us who are based in London recently got together in person. It  
> > was fairly unstructured and we talked about lots of things, but I made  
> > notes of the topics we discussed in depth.
> > 
> > In the interest of transparency and the wider community, here’s a summary  
> > of our conversations:
> > 
> > \* AMQP internals:
> > 
> > We talked generally about the AMQP spec (and RabbitMQ’s extensions) and  
> > the limitations of the nameko implementation. It became clear that our  
> > current implementation could be more sympathetic to how AMQP is designed:
> > 
> > The biggest problem the QueueConsumer, which is used to share a single  
> > Consumer between all AMQP-based entrypoints. It would be better if each  
> > entrypoint had its own Consumer, so that QoS and other settings can be  
> > applied per-entrypoint or per-entrypoint-type. At the moment, for example,  
> > it’s not possible to have a QoS of 10 for RPC methods, and a different QoS  
> > for event handlers, without using two QueueConsumers (which is a clunky  
> > workaround). This refactor could probably be made without breaking  
> > backwards compatibility.
> > 
> > We also talked about possibly changing exchange names, routing keys and  
> > queue names used by the current AMQP implementations. At present they are  
> > fairly inconsistent, and some improvements could be made by updating them.  
> > For example, using an RPC exchange per service would make detecting  
> > “UnknownService” errors easier. Any changes to routing keys, queues or  
> > exchanges would be backwards incompatible, though.
> > 
> > We also talked about replacing kombu with a more flexible and powerful  
> > library. Kombu is a general-purpose messaging library that supports  
> > RabbitMQ as one of many possible backends, none of which we make use of.  
> > Kombu also doesn’t support some desirable AMQP features, such as connection  
> > heartbeats. An alternative AMQP library, such as the official one (pika),  
> > would give us more control.
> > 
> > \* Config:
> > 
> > We decided to accept the recent community proposal of a yaml loader that  
> > could also read environment variables (  
> > [Issues · nameko/nameko · GitHub](https://github.com/onefinestay/nameko/issues/223%5C)). We’ll give the  
> > proposer a few weeks to raise a PR and otherwise implement it ourselves  
> > (and give attribution).
> > 
> > We decided to remove the ``—-broker`` option to nameko run and provide an  
> > alternative way to specify configuration options at run time (without a  
> > configuration file). We reaffirmed a previous suggestion that extensions  
> > should declare their own configuration options, including registering an  
> > option for the command-line runner if it’s useful to be able to provide it  
> > there.
> > 
> > \* Documentation:
> > 
> > We agreed the most important next step would be a reference application.  
> > This should be something that people can clone, tweak and run as easily as  
> > possible (e.g. include dockerfiles so no other dependencies are required).  
> > It should make particular effort to show how to use the nameko test  
> > utilities, because these are powerful but easiest to understand through  
> > example.
> > 
> > A fledgling example has been started in  
> > [https://github.com/nameko/nameko-examples\](https://github.com/nameko/nameko-examples%5C). It’s going an ordering system  
> > for the fictional "Air Ship LTD”.
> > 
> > Services:
> > 
> > Orders:  
> > - RPC CRUD for Orders/OrderDetails  
> > - RDBMS Data Store  
> > - Events: order\_created  
> > - External dependencies: nameko-sqlalchemy and alembic migrations
> > 
> > Products:  
> > - RPC CRUD for Products  
> > - Document Data Store with Redis to demonstrate creation of dependency.  
> > - Events: handle "order\_created" event and decrease stock
> > 
> > Gateway:  
> > - HTTP API - Create Order, List Orders, Show order details  
> > - Async RPC calls to get orders and product details  
> > - Dependencies: config dependency to prepend domain name to returned  
> > product images. Showing how to use access config in service code.
> > 
> > [Docker](https://hub.docker.com/u/nameko/dashboard) has been created for the  
> > dockerfiles.
> > 
> > \* Project website:
> > 
> > We spec’d out a draft for this. I need to tidy up the language slightly  
> > and then will put it in a gist or somewhere for people to see. We’re also  
> > searching for a designer to make it look pretty. It’ll be hosted at  
> > [http://nameko.github.io](http://nameko.github.io) and replace the basic page there.
> > 
> > \* PRs:
> > 
> > We went over all the outstanding (and old!) PRs and discussed next and/or  
> > final steps. Some have been cleaned up already, others are waiting for an  
> > agreed next step.