ttiurani

The motivation for the two server backend is that I currently have one working standalone B and will build a second B soon to serve a closely related purpose, and really don't want to duplicate the work or the data. That's why a backend server that stores common data and also most of the heavy business logic looks like the best solution at the moment.

Obvious seems like a very good fit for all the B's (closely related Python websites).

But I don't know about Scala backend though: do you have thoughts on packaging of different deliveries for static languages in Obvious? Because if there is only one folder structure, you typically (with Maven) get only one JAR.

To get many JARs the folder structure quickly turns into:

app/actions/common/src/main/scala

app/actions/featureset1/src/main/scala

app/actions/featureset2/src/main/scala

delivery/plug1/src/main/scala

delivery/plug2/src/main/scala

etc.

which isn't very pretty nor obvious (sic!). The other option I can think of is to have one big JAR that always has every plug and delivery baked in with a folder structure like:

src/main/scala/[Obvious folders]

and plugs and deliveries would then need to be activated runtime with configuration files. But that also seems sub-optimal: I don't want to have any code in production I'm not going to use.

Am I missing something?

Really cool! However I'm struggling a bit to see how to use the architecture in larger projects. I have a (grandiose) idea for a group of web sites with the following structure:

* Backend server A provides a REST API and stores data to a NoSQL database.

* Website B communicates with A or can work standalone with MySQL.

* Android client C communicates with A, and also caches data to its own SQLite database for off-line access.

A is written in Scala, B in Python and C is native Android.

How would you use Obvious in this scenario? Is it one big Obvious architecture or three separate Obvious instances? The REST API here is both a delivery and a plug, no?