Scaffolding for Brewblox backend services
Scaffolding for Brewblox service applications
In order to reduce code duplication between services, generic functionality is implemented here.
For an example on how to implement your own service based on
brewblox-service, see https://github.com/brewblox/brewblox-boilerplate.
brewblox-service can technically be launched as a standalone application, but will not be very useful.
Small generic tools are defined here.
brewblox_logger can be used for creating module-specific loggers. It is not required, but will play a bit nicer with default formatting of the log.
from brewblox_service import brewblox_logger LOGGER = brewblox_logger(__name__) LOGGER.info('hello')
Parses commandline arguments, creates an
aiohttp app, and runs it.
The shortest implementation is:
app = service.create_app(default_name='my_service') service.furnish(app) service.run(app)
This will get you a working web application, but it will not have any endpoints.
Applications can configure their own features, and add new commandline arguments.
# Separately creating the parser allows adding arguments to the default set parser = service.create_parser(default_name='my_service') parser.add_argument('--my-arg') # Now create the app app = service.create_app(parser=create_parser()) # Add features for this service device.setup(app) api.setup(app) # Furnish and run service.furnish(app) service.run(app)
Many service features are application-scoped. Their lifecycle should span multiple requests, either because they are not request-driven, or because they manage asynchronous I/O operations (such as listening to AMQP messages).
ServiceFeature class offers an abstract base class for this behavior. Implementing classes should define
shutdown(app) functions, and those will be automatically called when the application starts up and shuts down.
shutdown() are called in an async context, making them the async counterparts of
Features must be constructed after the app is created, but before it starts running. (
get() functions make it easy to centrally declare a feature, and then use it in any function that has a reference to the aiohttp app.
The replacement for the AMQP-based
The major advantages over AMQP is that the protocol is simpler, and supports websocket transport. This allows for it to be used outside a Brewblox network.
Messages have a /-separated topic and a JSON-serialized body.
To publish data, all you need is the
publish(topic, message) function.
To listen to incoming messages, you can combine
subscribe(topic) with one or more calls to
The subscribe/listen functions allow for + and # wildcards to be used.
For a detailed explanation of how to use MQTT topics, see http://www.steves-internet-guide.com/understanding-mqtt-topics/.
For the Brewblox spec on how and where to publish data, see https://brewblox.netlify.app/dev/reference/event_logging.html.
Includes top-level convenience functions for
listen(topic, callback) and
Release history Release notifications | RSS feed
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Hashes for brewblox_service-1.0.0-py3-none-any.whl