Question

Basically I started to design my project to be like that:

1. Play! Framework for web gui (consuming RESTful service)
2. Spray Framework for RESTful service, connects to database, process incoming data, serves data for web gui
3. Database. Only service have rights to access it

Now I’m wondering, if it’s really best possible design.
In fact with Play! I could easily have both web gui and service hosted at once.
That would be much easier to test and deploy in simple cases probably.
In complicated cases when high performance is needed I still can run one instance purely for gui and few next just to work as services (even if each of them could still serve full functionality).
On the other side I’m not sure if it won’t hit performance too hard (services will be processing a lot of data, not only from the web gui). Also, isn’t it mixing things which I should keep separated?

If I’ll decide to keep them separated, should I allow to connect to database only through RESTful service? How to resolve problem with service and web gui trying to use different version of database? Should I use versioned REST protocol in that case?

—————– EDIT——————

My current system structure looks like that:

But I’m wondering if it wouldn’t make sense to simplify it by putting RESTful service inside Play! gui web server directly.

—————– EDIT 2——————

Here is the diagram which illustrates my main question.
To say it clearly in other words: would it be bad to connect my service and web gui and share the model? And why?
Because there is also few advantages:

• less configuration between service and gui needed
• no data transfer needed
• no need to create separate access layer (that could be disadvantage maybe, but in what case?)
• no inconsistencies between gui/service model (for example because of different protocol versions)
• easier to test and deploy
• no code duplication (normally we need to duplicate big part of the model)

That said, here is the diagram:

Answer 1

Well, after few more hours of thinking about this, I think I found solution which will satisfy my needs. The goals which I want to be fulfilled are:

1. Web GUI cannot make direct calls to the database; it need to use proper model which will in turn use some objects repository
2. It must be possible to test and deploy whole thing as one packet with minimum configuration (at least for development phase, and then it should be possible to easy switch to more flexible solution)
3. There should be no code duplication (i.e. the same code in the service and web gui model)
4. If one approach will appear to be wrong I need to be able to switch to other one

What I forget to say before is that my service will have some embedded cache used to aggregate and process the data, and then make commits to database with bigger chunks of them. It’s also present on the diagram.

My class structure will look like this:

| 
|- models
    |- IElementsRepository.scala
    |- ElementsRepositoryJSON.scala
    |- ElementsRepositoryDB.scala
    |- Element.scala
    |- Service
         |- Element.scala
    |- Web
         |- Element.scala
|- controlers
    |- Element.scala
|- views
    |- Element
         |- index.scala.html

So it’s like normal MVC web app except the fact that there are separate model classes for service and web gui inheriting from main one.

In the Element.scala I will have IElementsRepository object injected using DI (probably using Guice).
IElementsRepository have two concrete implementations:

1. ElementsRepositoryJSON allows to retrieve data from service through JSON
2. ElementsRepositoryDB allows to retrieve data from local cache and DB.

This means that depending on active DI configuration both service and web gui can get the data from other service or local/external storage.
So for early development I can keep everything in one Play! instance and use direct cache and DB access (through ElementsRepositoryDB) and later reconfigure web gui to use JSON (through ElementsRepositoryJSON). This also allows me to run gui and service as separated instances if I want. I can even configure service to use other services as data providers (however for now I don’t have such a needs).

More or less it will look like that: