regarding about game servers performance and security

Question

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

Answer 1

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.

Answer 2

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:

• When you have multiple consumers, then you can offer a static interface which is decoupled from the implementation details. This is useful when you want to change the way the service works internally without having to change all the consumers. But that's only useful when you have a lot of different consumers probably implemented in different technologies, so changing them all would be a lot of work.
• When you don't just have multiple consumers but also multiple data providers, then you can hide that behind one common API. For example, you can change your API implementation to draw data from not just one database but from multiple databases using different query languages, from other APIs or from filesystem resources. All while the consumers are unaware of where the data actually resides.
• You can control what the interface can and can not do, which is useful when you have untrusted consumers. For example, 3rd party services drawing data. Or perhaps you want the game client to do certain operations bypassing the gameserver entirely.

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:

• You create more complexity in your server setup. There is now one more piece of software to develop, deploy, host and maintain.
• You are creating another level of indirection causing additional latency and which might potentially become a bottleneck.
• Implementing and testing new features might become harder, because they require changes to the API.