直接连接到 SQL Azure 还是通过 API 服务层连接？

Question

Currently our DB works in customer's local network and we have client app on C# to consume data. Due to some business needs, we got order to start moving everything to Azure. DB will be moving to Azure SQL.

We had discussion about accessing DB. There are two points:

1. One guy said that we have to add one more layer between our app (that will be working outside Azure at end-user PCs) and SQL Azure. In other words he suggested adding API service that will be translated all requests to DB, ie app(on-premises) -> API service (on Azure)-> SQL Azure . This approach looks more reliable and secure, since we are hiding SQL Azure behind facade of API service and the app talks to our API service only. It looks more like a reverse proxy. Obviously, behind this API we can build more sophisticated structure of DBs.
2. Another guy suggested connecting directly to DB, ie app(on-premises) -> SQL Azure . So far we don't have any plans to change structure of DB or even increase count of DBs. He claims it more simple and we can secure our connection the same way. Having additional service that just re-translates our queries to DB and back looks like wasting time.In the future, if needed, we would add this API.

What would you select and recommend, and why ?

Few notes:

• We are going to use Azure AD to authenticate users.
• Our application will be moving to Azure too, but later (in 1-2 years), we have plans to create REST API and move to thin client instead of fat client we have right now.
• Good performance is our goal, we don't want to add extra things that can decrease it, but security is our most important goal as well.

Answer 1

Certainly an intermediate layer is one way to go. There isn't enough detail to be sure, but I wonder why you don't try the second option. Usually some redevelopment is normal. But if you can get away without it, and you get sufficient performance then that's even better.

I hope this helps. Thank you. Guy

Answer 2

If your application is not just a prototype (it sounds like it is not), then I advise you to build the intermediate API. The primary reasons for this are:

Flexibility

Rolling out a new version of an API is simple: You have either only one deployment or you have something like Octopus Deploy that deploys to a few instances at the same time for you. Deploying client applications is usually much more involved: Creating installers, distributing them, making sure users install them, etc.

If you build the API, you will be able to make changes to the DB and hide these changes from the client applications by just modifying the API implementation, but keeping the API interfaces the same. Moving forward, this will simplify the tasks for your team considerably.

Security

As soon as you have different roles/permissions in your system, you will need to implement them with DB security features if you connect to the DB directly. This may work for simple cases, but even there it is a pain to manage.

With an API, you can implement authorization in the API using C#. Like this, you can build whatever you need and you're not restricted by the security features the DB offers.

Also, if you don't take extra care about this, you may end up exposing the DB credentials to the client app, which will be a major security flaw.

Conclusion

Build the intermediate API. Except you have strong reasons not to. As always with architecture considerations, I'm sure there are cases where the above points don't apply. Just make sure you understand all the implications if you decide to go the direct route.