I recently got a recommendation to always build backend applications as a pair of two servers: an API server and a database server.
The API server exposes APIs to the mobile/web clients, but to get/create/update data it communicates - through, say, gRPC - with another server that accesses the database. The database server can only be accessed by the API server.
The merits of this method, as opposed to a single server setup, are that the database credentials are not stored on the server that is exposed publicly (the API server), so if a hacker gains access to the API server, they would not be able to access the database directly. Also, the two servers might potentially be built in different languages.
However, I see challenges with writing more abstractions (function definition in the database server, type definitions, function call in the API server) to process data - more code and more time spent.
What do you think about this? Do you use this two-server method? Are there other merits/demerits? Are there situations were it is absolutely necessary to do this? Or do you use other methods of securing your database?
Thanks for the reply, Mark.
To further clarify, the database itself is cloud-hosted. What the database server does is access that data then returns to the API server.
For example, for a simple blogging system (JS), with a normal monolith, one might do:
router.get('/posts', (req, res) => {
// get user from DB
const user = db.users.find(req.token.id);
// get posts from DB
const posts = db.posts.find(user.id);
res.json(posts);
});
for a database-server - api-server pair:
DB server
function getUserWithID(id) {
return db.users.find(id);
}
function getPostsWithUserID(userID) {
return db.posts.find(userID);
}
API server
router.get('/posts', (req, res) => {
const user = getUserWithID(req.token.id);
const posts = getPostsWithUserID(user.id);
res.json(posts);
});
This way only the DB server has direct access to the DB, while the API server can only access the DB through pre-defined functions. So, an attacker on the API server cannot, for example, drop all posts.
Do you see any advantages/limitations to doing this?
Mark
Just going by the title, I think it is a good idea to have an API service that uses a database service for storage. It moves logic out of the database layer, which is good for scaling and perhaps easier to develop. It's also necessary for authenticating end users and managing permissions.
In the description, it seems the database server does more than just databasing though, at least something related to authentication? I don't really think that's useful unless I'm missing something - the API service can run queries against the database somehow, possibly through an intermediary service, so if it gets compromised, the attacker can run any queries without needing DB credentials.