Direct vs. Indirect access of service by a Client?

[David Schwartz 415]

I'm using TMS WEB core to build a web app, and it's talking with a dedicated REST-based service (built with XData).

 

I have several back-end services that I'm using and the XData service interfaces with them itself. In most cases, it's also doing stuff that makes it more of a middle-tier app -- things that I simply don't want to do on the Client side.

 

I see where TMS just came out with support for Google's Firebase using some DB-specific components in WEB Core that work on the Client side to connect directly to a Firebase DB remotely.

In my mind, I tend to think of my back-end service as a class where I get and set things as needed, and I don't have to worry about how they're implemented or where they're stored. But putting logic in the Client that now knows these implementation details creates complications and dependencies that can affect future changes.

 

I'm curious what others who've built some web apps think of the pros and cons of accessing back-end services directly from the Client app vs. through their dedicated service back-end? Do you mix it up, or prefer to hide everything behind your back-end service?

 

[Fr0sT.Brutal 897]

I didn't create web apps but I created a DB app with almost all logic at client and a DB app with all logic at server (only a few stored procs exposed to clients).

Answer: it depends. Every approach has its pros and cons and which are more valuable to your project is you to decide. If your API grows, you can end with 100s of server end points with separate one for every modification. With client-side logic data flow could appear too fat or exposing too much internal fields

[David Schwartz 415]

@Fr0sT.Brutal I don't think you're understanding the gist of my question. 

 

I can't recall ever seeing anybody recommend that it's a Good Idea to write an app that connects directly to the IP:Port# of a back-end DB like, say, MySQL. Why? Because everybody who has been working in the industry for any length of time says it's a HUGE security risk to expose the local DB access port to the entire internet.

 

There used to be this terrific, and inexpensive, DB management tool called SQLYog that had a proxy layer that completely insulated the front-end GUI from the back-end MySQL DB. (I think they expanded it to work with other DBs over time, but I only used it with MySQL.) You had to install a script on your server that it talked to via a secure connection so you didn't have to expose the MySQL port to the entire world. That was the only MySQL DB maintenance tool that was affordable that operated securely. It got bought up and now it's as expensive as the others.

 

Did you write your own secure proxy layer for your remote DB applications? Given that you think it depends mainly on the number of API calls you need, I'm guessing you aren't really dealing with the underlying risks.

 

It doesn't matter if you have just one or thousands of APIs -- all it takes is one a-hole and lots of time on his/her hands to swamp your server with direct requests to your IP:Port# in an effort to break into your back-end DB. It's not like most DBs don't have a well-known port# they're configured to use, right? MySQL uses port 3306 by default. How many apps have you built where you put the DB logic on the front-end and made port 3306 public on the back-end servier just so you didn't need to bother with any kind of API layer for security, eh?

 

For most folks it's an all-or-nothing proposition -- you don't build it for just a few then throw it away as your API needs grow. And you don't take the easy way out and pretend it's not an issue until you get your system hacked and have to report it to your users and the authorities as a breech.

 

In this case, if you have a web app (as opposed to a typical client/server app that runs on a intranet LAN), it's probably designed to access most logic through your own back-end service. Even if the API itself is published (and many public services are; eg., Amazon and Google, among many others), the security is set up so nobody knows how the services themselves are implemented. It's like OOP -- you've got some "encapsulation" going on that hides the underlying implementation, with all of the corresponding benefits. One of the biggest consumers of such public APIs is Zapier, and they don't seem at all concerned with the quantity of calls each of their services might support.

 

But if you DO have a dedicated service layer on the back-end, and then decide to implement some UI features that access something like Firebase directly from the front-end, you've now exposed an implementation detail to the world that can be easily detected that people might try to hack. Sure, it's more secure than just a raw IP:Port#, but ... I'm wondering how many people who've built apps partitioned this way think it's a risk or not. Are they inclined to hide everything behind their own services API? Or add-on UI services that expose some of their back-end service providers directly?

[Attila Kovacs 617]

On 8/16/2023 at 7:40 AM, David Schwartz said:

I see where TMS just came out with support for Google's Firebase using some DB-specific components in WEB Core that work on the Client side to connect directly to a Firebase DB remotely.

 

How would you manage to allow 20 million users to authenticate simultaneously?

You can't. Google can.

Some services are meant for the clients, while others are not.

Relying on such services always carries some risk, but not necessarily the ones you are most concerned about. Instead of fearing discontinuation, excessively frequent updates, or lack of support,..

Edited August 23, 2023 by Attila Kovacs

[aehimself 388]

Zeos recently implemented a Proxy driver which does exactly what you describe - it only exposes the proxy and client apps “connect” to this proxy. It supports all protocols which Zeos itself supports.

 

I personally never tried it so I cannot say anything about security and such, but you can give it a try.

[David Schwartz 415]

On 8/23/2023 at 1:25 PM, Attila Kovacs said:

How would you manage to allow 20 million users to authenticate simultaneously?

You can't. Google can.

Some services are meant for the clients, while others are not.

Relying on such services always carries some risk, but not necessarily the ones you are most concerned about. Instead of fearing discontinuation, excessively frequent updates, or lack of support,..

Sorry, I'm not following you at all. This isn't an ad on the SuperBowl.

 

It's a fairly nondescript membership-based service -- something like this forum, where the choice here might be whether the script talks directly to the service storing the data you're reading right now, or does it access it through a service (ie, a middle-tier) that might talk to different datastores and, for most purposes, introduces an unnoticeable delay?

 

[Attila Kovacs 617]

6 hours ago, David Schwartz said:

Sorry, I'm not following you at all. This isn't an ad on the SuperBowl.

 

Why do you care then? Anyway, "service storing the data" is a kind of middle-tear API too, nobody exposes the DB itself.

[David Schwartz 415]

22 hours ago, Attila Kovacs said:

Why do you care then? Anyway, "service storing the data" is a kind of middle-tear API too, nobody exposes the DB itself.

I'm asking for YOUR opinion, and you just asked me some questions. 

 

YOUR opinion seems to be, "Unless I'm running something with the bursty traffic of a Superbowl ad, then I don't care." 

 

That's fine. Thanks.

 

 

[Attila Kovacs 617]

You asked for thoughts, pros, and cons. Then, you became anxious when I provided you with a point of view and introduced your implementation details (traffic) into the equation, which changed the entire question.

But hey, we're used to it 😉

Do you still have any concerns?

 

 

[darnocian 70]

@David Schwartz  The approach of placing some middleware in front of the database is definitely better. The benefit of the approach vs direct db access is that you are likely to have more options in terms of scalability and support, and ability to centralise business logic. If you define the service contract well, you can change the implementation of the backend, as long as you don't break the contract, and all your clients can continue working. From a scalability perspective, you can easily put a load balancer in place to front multiple servers. When it comes to the db, you could have multiple read replicas with the backend server spreading the load between them, if your system is more read heavy. Anyways, it all depends on the problem you have, but having a service offering does give you options. It can become a pain if you have multiple clients (say desktop, web, mobile) having to implement business logic - one could get out of date because of a bug and management forgot to replace the contractor that was last working on that client that everyone forgot about. 😉 Further, you also have away of measuring usage, as you can enable logging, whereas with direct access to a db, you would need to query db logs or something. Further, the art of the service contact is how much data is in a request/response, do you make lots of small calls, or do you make one big one, etc...  all depends on the problem.

 

So with Google Firebase DB, I've seen mobile clients connect directly to it. Many companies have found this attractive in terms of simplicity, as an object store, it is easy to add / query items. However, I've seen issues where initially people get excited as it is so fast just accessing the db directly. then the pain creeps in there are different clients that have implemented the business logic internally. Anyways, you have to be careful about the use case and the problem being solved. Typically a cloud functions  (like an aws lambda) could also linked to an endpoint to wrap business logic. I havn't tried using Firebase from TMS, so can't comment, but google essentially exposes the nosql db like a rest api (https://firebase.google.com/docs/reference/rest/database) So all the scalability and separation between implementation is handled by google probably in ways I've described, and hidden to the end user / developer.  In my opinion, it is still a db store, so I'd still prefer to with front business layer or something vs going directly in.

 

in my opinion, it is definitely useful to create the abstraction of having a service to front the db / storage ecosystem. don't expose the sql or whatever the underlying storage query language directly to the user, as you are then you are exposing internals and likely to have problems later where some friendly guy sends a 'drop table transactions' or something. 😉