Skip to content
This repository has been archived by the owner on Jun 27, 2023. It is now read-only.

requests should go directly to the resource actor #167

Open
bblfish opened this issue Feb 22, 2016 · 0 comments
Open

requests should go directly to the resource actor #167

bblfish opened this issue Feb 22, 2016 · 0 comments

Comments

@bblfish
Copy link
Member

bblfish commented Feb 22, 2016

It would be worth considering the following refactoring of the code, where HTTP requests are dealt with directly by the actor for the resource.

This actor should then deal with:

  • access control
  • etags
  • mime types etc...
  • return types

This would allow:

  • the system to be distributed for large databases with multiple servers could handle subsets of resources and redirect the requests directly to the relevant actor.
  • the resource actor could itself keep mini databases of acls so as to reduce the computation time needed to calculate them
  • the actor could work out directly if the etag is valid. Currently there is a problem because the front end has to request the meta data in one step and then check the etag. In the mean time another write could occur.
  • the actor could work out exactly what type of object to return, for example it could return a stream directly instead of having to serialise a graph. Note that some actors would still keep graphs in memory, eg in order to make calculations of acls easier, or to allow queries.
  • because the full headers could be sent to the actor, it would have a lot more information about what it should do with the request, making it much more extensible.

There may be other advantages and disadvantages to consider. So this is the space to list them.

@bblfish bblfish added this to the Move to akka-http milestone Feb 22, 2016
@bblfish bblfish changed the title requests should go directly to the actor responsible for the request requests should go directly to the resource actor Feb 22, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant