Giter VIP home page Giter VIP logo

pyramid_services's Introduction

pyramid_services

main CI Status

The core of a service layer that integrates with the Pyramid Web Framework.

pyramid_services defines a pattern and helper methods for accessing a pluggable service layer from within your Pyramid apps.

Installation

Install from PyPI using pip or easy_install inside a virtual environment.

$ $VENV/bin/pip install pyramid_services

Or install directly from source.

$ git clone https://github.com/mmerickel/pyramid_services.git
$ cd pyramid_services
$ $VENV/bin/pip install -e .

Setup

Activate pyramid_services by including it into your pyramid application.

config.include('pyramid_services')

This will add some new directives to your Configurator.

  • config.register_service(obj, iface=Interface, context=Interface, name='')

    This method will register a service object for the supplied iface, context, and name. This effectively registers a singleton for your application as the obj will always be returned when looking for a service.

  • config.register_service_factory(factory, iface=Interface, context=Interface, name='')

    This method will register a factory for the supplied iface, context, and name. The factory should be a callable accepting a context and a request and should return a service object. The factory will be used at most once per request/context/name combination.

  • config.set_service_registry(registry)

    This method will let you set a custom wired.ServiceRegistry instance which is the backing registry for all services.

Usage

After registering services with the Configurator, they are now accessible from the request object during a request lifecycle via the request.find_service(iface=Interface, context=_marker, name='') method. Unless a custom context is passed to find_service, the lookup will default to using request.context. The context will default to None if a service is searched for during or before traversal in Pyramid when there may not be a request.context.

svc = request.find_service(ILoginService)

Registering per-request services

Some services (like your database connection) may need a transaction manager and the best way to do that is by using pyramid_tm and hooking the request.tm transaction manager into your service container. The request object itself is already added to the container for the pyramid.interfaces.IRequest interface and can be used in factories that require the request.

This can be done before any services are instantiated by subscribing to the pyramid_services.NewServiceContainer event:

from pyramid_services import NewServiceContainer

def on_new_container(event):
    container = event.container
    request = event.request
    container.set(request.tm, name='tm')

config.add_subscriber(on_new_container, NewServiceContainer)

Examples

Let's create a login service by progressively building up from scratch what we want to use in our app.

Basically all of the steps in configuring an interface are optional, but they are shown here as best practices.

# myapp/interfaces.py

from zope.interface import Interface

class ILoginService(Interface):
  def create_token_for_login(name):
    pass

With our interface we can now define a conforming instance.

# myapp/services.py

class DummyLoginService(object):
  def create_token_for_login(self, name):
    return 'u:{0}'.format(name)

Let's hook it up to our application.

# myapp/main.py

from pyramid.config import Configurator

from myapp.services import DummyLoginService

def main(global_config, **settings):
  config = Configurator()
  config.include('pyramid_services')

  config.register_service(DummyLoginService(), ILoginService)

  config.add_route('home', '/')
  config.scan('.views')
  return config.make_wsgi_app()

Finally, let's create our view that utilizes the service.

# myapp/views.py

@view_config(route_name='home', renderer='json')
def home_view(request):
  name = request.params.get('name', 'bob')

  login_svc = request.find_service(ILoginService)
  token = login_svc.create_token_for_login(name)

  return {'access_token': token}

If you start up this application, you will find that you can access the home url and get custom tokens!

This is cool, but what's even better is swapping in a new service without changing our view at all. Let's define a new PersistentLoginService that gets tokens from a database. We're going to need to setup some database handling, but again nothing changes in the view.

# myapp/services.py

from uuid import uuid4

from myapp.model import AccessToken

class PersistentLoginService(object):
  def __init__(self, dbsession):
    self.dbsession = dbsession

  def create_token_for_login(self, name):
    token = AccessToken(key=uuid4(), user=name)
    self.dbsession.add(token)
    return token.key

Below is some boilerplate for configuring a model using the excellent SQLAlchemy ORM.

# myapp/model.py

from sqlalchemy import engine_from_config
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm import sessionmaker
from sqlalchemy.schema import Column
from sqlalchemy.types import Text

Base = declarative_base()

def init_model(settings):
  engine = engine_from_config(settings)
  dbmaker = sessionmaker()
  dbmaker.configure(bind=engine)
  return dbmaker

class AccessToken(Base):
  __tablename__ = 'access_token'

  key = Column(Text, primary_key=True)
  user = Column(Text, nullable=False)

Now we will update the application to use the new PersistentLoginService. However, we may have other services and it'd be silly to create a new database connection for each service in a request. So we'll also add a service that encapsulates the database connection. Using this technique we can wire services together in the service layer.

# myapp/main.py

from pyramid.config import Configurator
import transaction
import zope.sqlalchemy

from myapp.model import init_model
from myapp.services import PersistentLoginService

def main(global_config, **settings):
  config = Configurator()
  config.include('pyramid_services')
  config.include('pyramid_tm')

  dbmaker = init_model(settings)

  def dbsession_factory(context, request):
    dbsession = dbmaker()
    # register the session with pyramid_tm for managing transactions
    zope.sqlalchemy.register(dbsession, transaction_manager=request.tm)
    return dbsession

  config.register_service_factory(dbsession_factory, name='db')

  def login_factory(context, request):
    dbsession = request.find_service(name='db')
    svc = PersistentLoginService(dbsession)
    return svc

  config.register_service_factory(login_factory, ILoginService)

  config.add_route('home', '/')
  config.scan('.views')
  return config.make_wsgi_app()

And finally the home view will remain unchanged.

# myapp/views.py

@view_config(route_name='home', renderer='json')
def home_view(request):
  name = request.params.get('name', 'bob')

  login_svc = request.find_service(ILoginService)
  token = login_svc.create_token_for_login(name)

  return {'access_token': token}

Hopefully this pattern is clear. It has several advantages over most basic Pyramid tutorials.

  • The model is completely abstracted from the views, making both easy to test on their own.
  • The service layer can be developed independently of the views, allowing for dummy implementations for easy creation of templates and frontend logic. Later, the real service layer can be swapped in as it's developed, building out the backend functionality.
  • Most services may be implemented in such a way that they do not depend on Pyramid or a particular request object.
  • Different services may be returned based on a context, such as the result of traversal or some other application-defined discriminator.

Testing Examples

If you are writing an application that uses pyramid_services you may want to do some integration testing that verifies that your application has successfully called register_service or register_service_factory. Using Pyramid's testing module to create a Configurator and after calling config.include('pyramid_services') you may use find_service_factory to get information about a registered service.

Take as an example this test that verifies that dbsession_factory has been correctly registered. This assumes you have a myapp.services package that contains an includeme() function.

# myapp/tests/test_integration.py

from myapp.services import dbsession_factory, login_factory, ILoginService

class TestIntegration_services(unittest.TestCase):
  def setUp(self):
    self.config = pyramid.testing.setUp()
    self.config.include('pyramid_services')
    self.config.include('myapp.services')

  def tearDown(self):
    pyramid.testing.tearDown()

  def test_db_maker(self):
    result = self.config.find_service_factory(name='db')
    self.assertEqual(result, dbsession_factory)

  def test_login_factory(self):
    result = self.config.find_service_factory(ILoginService)
    self.assertEqual(result, login_factory)

pyramid_services's People

Contributors

aodag avatar digitalresistor avatar ianjosephwilson avatar jon-betts avatar mmerickel avatar uralbash avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

pyramid_services's Issues

How to use pyramid_services in tests

For the test setup, I usually config.include() the main application includeme() and then config.include test stuff, to override some of the services/utilities.
It's less intrusive, test code is clearly isolated.

I really like pyramid_services. It's neat and clean.
However it's not possible to "override" a service (same context, name).

How do you test the application if some service must be swapped with "test" service ?

Using one service in another service?

Sometimes it might be convenient to use other services when implementing a new service.
Is this a good approach and are there any possible problems associated with it?

Support services outside of a request context

Currently this assumes that the only use of looking up services will be inside of a request context. This is certainly the most common case but I have a case where It would be beneficial to be able to look up the registered service when I don't have a request (such as in an async worker or in a batch script).

Looking at the implementation, it appears that even for already created services (e.g. register_service) a dummy factory is created which does nothing but return the already created service. So I think for this to work, when you're not operating inside of a request, then request would be set to None.

I've copy/pasted the find_service function into my own app to see if I can make it work, and this appears to work:

def find_service(registry, iface=None, context=None, name=''):
    if iface is None:
        iface = Interface
    if name is None:
        name = ''

    context_iface = providedBy(context)
    svc_types = (IServiceClassifier, context_iface)
    svc_factory = registry.adapters.lookup(svc_types, iface, name=name)
    if svc_factory is None:
        raise ValueError('could not find registered service')
    # We are not operating in the confines of a request, so we'll pass a
    # None for the request.
    return svc_factory(context, None)

I'm not sure what the best API would be for using this outside of a request context, I originally thought that a config directive like config.find_service() would work, but the #pyramid IRC channel didn't seem to think that was the right way to go. There's no cache that'll return the same object for multiple find_service calls with this, since there is no request/response cycle to tie the lifetime of that cache to.

Thoughts? Is this something that would be useful to have inside of pyramid_services or should I just keep a copy of my find_services function inside of my app?

Singleton per request object

One issue I ran into with your dbsession service example (that uses a service factory) is the following:

When looking for the service different sessions are returned depending on the context. This is by design. Citing the documentation:

The factory will be used at most once per request/context/name combination.

Having different DB session in one request is quite ugly and I can think of no use case for it. How did I end up with different contexts? By using the request object outside a view function invoked directly with pyramid.threadlocal.get_current_request . In that case the context is None.

This example by Jon Rosebaugh - What the Zope Transaction Manager Means To Me (and you) would work but I wanted to use pyramid_services (for consistency, because I'm already using it in other parts of the application).

I'm aware that this might not be the place for this since it classifies more as a question than an issue, but you could at least fix the example to be more clear that

request.find_service(name='db')

will return different sessions depending on the request context.

My workaround is to always pass context=None:

request.find_service(name='db', context=None)

Is there a simpler solution (e.g. a singleton per request)? register_service() would register a singleton object for the whole application, but I do want a different DB session for every request.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.