Service Basics
Last updated
Last updated
One of the main concepts within Angel, which is borrowed from FeathersJS, is a service. You more than likely have already dealt with another implementation of the service concept. In Angel, a service is a class that acts as a Web interface and exposes CRUD actions operating on a set of data. Angel services extend Routable
, and thus can be mounted on a certain path and become REST endpoints.
The Angel core library includes the Service
base class, as well as two in-memory service classes. Database adapter packages, such as include service classes that let you interact with a database without writing complex code yourself.
Services can also be filtered or reacted to with .
A service looks like this:
There are meta-methods that default to delegating to the above:
findOne
readMany
You can override these for your service, if it will improve performance.
You might notice that each service method accepts an optional Map
of parameters. When accessed via HTTP (i.e., not over Websockets), req.query
or req.bodyAsMap
is passed here (query
for index
, read
and delete
, bodyAsMap
for create
, update
and modify
). To pass custom parameters to a service, you should create a middleware to do so. @Middleware
annotations can be prepended to service classes or service methods. For example, the following will pass foo='bar'
to every method in the service:
Additionally, when accessed by a client, params
will contain a field called provider
.
provider
will be a Providers
class, whose String via
will tell you where the service is being accessed from, i.e. 'rest'
, 'graphql'
or 'websocket'
.
As mentioned above, services extend Routable
, so you can simply app.use()
them. You can also supplement them with additional routes or middleware, placed before the mounting of a service:
Important things to consider when writing your own service:
Services need only worry about handling Map
s. Object serialization should be handled by angel_serialize
, another serializer, or TypedService
.
Allowing users to query the service via query string is optional (see allowQuery
)
Allowing users to remove all entries is optional, and should be disabled by default
DELETE /null
should trigger an evaluation of allowRemoveAll
Service.toId
will return null
in these cases
Always return the most recent representation of the data
After remove
, return the old item
After modify/update, return what the item looks like in the database
modify
and update
are not interchangeable!
modify
merges changes into an existing item
update
overwrites an existing item
BOTH should create an item with the given ID if it does not already exist
is a good reference implementation]