Tldr; Since 0.12 you don't need to spin up 2 containers for the basic stuff, just get the Database up as you would. Half the containers twice the features, or the same features w/e.
If you played around with Conduit a little, and when I see a little I mean even just running our handy "getting started" script, you'll know that the Database is an absolutely important module of the platform. You can't do anything(pretty much) without the Database module being online and connected to either MongoDB or one of the supported SQL databases.
That's for good reason of course. We don't think that any kind of backend(or at least one with an API) can exist without a datasource and the most prominent datasources are databases. So Conduit uses its database to manage the state of the platform, the configuration, the schemas you create and obviously your data. Once it's up and running, you're in business.
The Database handles a lot of stuff, since it's the single point where all data is retrieved from or updated. It keeps track of all the schemas you create (either through code or the admin UI), it fetches and updates data for those schemas, handles permissions (on a module level) and provides a handy adapter layer so that you can write the same queries both for MongoDB and SQL (which was tough to do so we hope you like it).
As you're probably aware, the CMS is another important part of a backend, yes not every backend, but it tends to be very useful when you have an API serving an application or maybe using it as a headless CMS for your website. In the context of Conduit, it definitely fills that role, but also does a bunch of other cool stuff.
For example, you create new schemas through it so that you can store any data you want, you add and manipulate data (duh), it automatically creates CRUD endpoints for you so that you don't have to, and lastly it provides you with the ability to write custom logic (up to a point of course) which again is exposed through automatically generated endpoints.
So yeah, it's not actually just a CMS, it does a bunch of stuff.
So we decided to break the thing apart into separate modules, for a bunch of reasons that it'd probably be best to read the architecture section of the docs than me claiming more of your time to discuss it. We were perhaps a bit too greedy, in this break-up process, as we all know break-ups are never easy (come back Maria I still miss you). We wrote CMS and Database as separate modules, for the sake of linear scaling and blah blah.
Until we realized, that there wasn't any reason whatsoever for them to actually be separate modules. The CMS does 99.9% of its work on the database, it "just" constructs queries. The only other logic that it has, is centered around configuration and modification of schemas which is minimal, unless your use-case is to have a monke army modifying schemas every 100ms, where yes, you would need a separate module to handle the load.
Looking forward though we have more awesome stuff planned for the Database like:
If you've managed to get this far, thanks! And check out the links below: