Class: Hoodoo::Services::Service
- Inherits:
-
Object
- Object
- Hoodoo::Services::Service
- Defined in:
- lib/hoodoo/services/services/service.rb
Overview
Hoodoo::Services::Service is subclassed by people writing service implementations; the subclasses are the entrypoint for platform services.
It’s really just a container of one or more interface classes, which are all Hoodoo::Services::Interface subclasses. The Rack middleware in Hoodoo::Services::Middleware uses the Hoodoo::Services::Service to find out what interfaces it implements. Those interface classes nominate a Ruby class of the author’s choice in which they’ve written the implementation for that interface. Interfaces also declare themselves to be available at a particular URL endpoint (as a path fragment); this is used by the middleware to route inbound requests to the correct implementation class.
Suppose we defined a PurchaseInterface and RefundInterface which we wanted both to be available as a Shopping Service:
class PurchaseImplementation < Hoodoo::Services::Implementation
# ...
end
class PurchaseInterface < Hoodoo::Services::Interface
interface :Purchase do
endpoint :purchases, PurchaseImplementation
# ...
end
end
class RefundImplementation < Hoodoo::Services::Implementation
# ...
end
class RefundInterface < Hoodoo::Services::Interface
interface :Refund do
endpoint :refunds, RefundImplementation
# ...
end
end
…then the entire Service subclass for the Shopping Service could be as small as this:
class ShoppingService < Hoodoo::Services::Service
comprised_of PurchaseInterface,
RefundInterface
end
Names of subclasses in the above examples are chosen for clarity and the naming approach indicated is recommended, but it’s not mandatory. Choose choose whatever you feel best fits your code and style.
Conceptually, one might just have a single interface per application for very small services, but you may want to logically group more interfaces in one service for code clarity/locality. More realistically, efficiency may dictate that certain interfaces have such heavy reliance and relationships between database contents that sharing the data models between those interface classes makes sense; you would group them under the same service application, sacrificing full decoupling. As a service author, the choice is yours.
Class Method Summary collapse
-
.component_interfaces ⇒ Object
Return an array of the classes that make up the interfaces for this service.
Instance Method Summary collapse
-
#call(env) ⇒ Object
Since service implementations are not pure Rack apps but really service middleware clients, they shouldn’t ever have “call” invoked directly.
-
#component_interfaces ⇒ Object
Instance method which calls through to ::component_interfaces and returns its result.
Class Method Details
.component_interfaces ⇒ Object
Return an array of the classes that make up the interfaces for this service. Each is a Hoodoo::Services::Interface subclass that was registered by the subclass through a call to #comprised_of.
86 87 88 |
# File 'lib/hoodoo/services/services/service.rb', line 86 def self.component_interfaces @component_interfaces end |
Instance Method Details
#call(env) ⇒ Object
Since service implementations are not pure Rack apps but really service middleware clients, they shouldn’t ever have “call” invoked directly. This method is not intended to be overridden and just complains if Rack ends up calling here directly by accident.
env
-
Rack environment (ignored).
104 105 106 |
# File 'lib/hoodoo/services/services/service.rb', line 104 def call( env ) raise "Hoodoo::Services::Service subclasses should only be called through the middleware - add 'use Hoodoo::Services::Middleware' to (e.g.) config.ru" end |
#component_interfaces ⇒ Object
Instance method which calls through to ::component_interfaces and returns its result.
93 94 95 |
# File 'lib/hoodoo/services/services/service.rb', line 93 def component_interfaces self.class.component_interfaces end |