I have two options to implement
- should my game server access the database directly
- should game server access database via api
would it be necessary to abstract the calls via api even though its located in same location
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.Sign up to join this community
You can do whichever one you want. Note that the second option is more work. Note that the database is already an API, so if you want to put your own API on top of that API you'd better have a good reason for it.
There are some good reasons, like if you want to make it possible to drastically change the database system later. If you use MySQL and the game server runs
select * from players where id = 123456; when you log in, you can't change to MongoDB without updating the game server. If you use
http://localhost/players/123456 then you can update your API instead of updating the game server. But on the other hand, what's wrong with updating the game server? Maybe if you have 500 game servers and one API server then it's easier to update the API server.
If you don't have a reason to create a separate API, then don't. It's just extra work. If you think of a reason later, you can always create it at that time.
Technically, your gameserver is already an API used by clients as an intermediary to communicate with the database. API does not necessarily mean web service API.
A service-oriented architecture (SOA) has several advantages:
But note that all these advantages are moot when you only have one consumer. In that scenario there is really not much to gain from delegating the construction of SQL queries and parsing their results to a separate middleware. Anything the API does can be done by the gameserver directly.
But a SOA also has disadvantages: