I am new to web development, and have seen posts such as these . If one is using AWS and is connecting to an AWS rds instance through Node, is that still considered a direct connection as opposed to a web service?
You're probably going to get a bunch of conflicting opinions on this. My personal opinion is a web service in front of your database makes sense in some scenarios. Multiple applications connecting to the web service instead of directly to the db gives several advantages, security, caching, etc.
That being said, if this is just a single app then most of those advantages disappear and in fact just make things more complex for you. You're going to have to setup your web service for the db as well as your actual code.
If one is using AWS and is connecting to an AWS rds instance through Node, is that still considered a direct connection as opposed to a web service?
No, if Node.js is running on a server or in "serverless" containers (e.g. AWS Lambda) that is not a direct connection. That is a web service, and that's what you want.
A direct connection means the app connects to the database itself... but that requires embedding credentials in the app.
You do not want to embed anything in your app that you would not willingly hand over to an arbitrary user -- such as database credentials and API keys -- because you cannot trust that the app won't be reverse-engineered.
You should design the app in such a way that you would have no security concerns if the entire source code of the app were exposed, because knowing everything about the app's internals would give a malicious actor no valuable information. How? The code on the server side (e.g. in Node.js) should treat every request from the app as potentially suspicious, untrustworthy, etc., and validates every request to do anything.
This layer of separation is one of the strongest reasons why you never give the app direct access to the database. Code running in a trusted place -- your web server/API layer -- needs to vet every database interaction. This topology also decouples the app user from tying up resources on the database server when not actually interacting with the database, which is far less practical with a direct connection.
Related
What's the best practice for connecting to an SQL database from Vercel/Next.js serverless functions? I've seen a few options commonly mentioned:
Create a new direct database connection in the serverless function. This has important drawbacks:
Connection pooling: every new invocation of a serverless function would create its database connection, which could quickly overwhelm the database
Security: the database has to be publicly exposed since Vercel doesn't support static IPs or VPC peering. This unfortunately is deal-breaker for any security-sensitive application (fintech, healthcare, education, etc.) and SOC 2 compliance
Add an intermediary service that receives HTTP requests and proxies it to the database
My understanding is that this is a common thing people do? How does this work?
Use a vendor-specific solution, like the Prisma Data Proxy product (requires using the Prisma ORM) or AWS Aurora Data API (essentially an out-of-the-box version of the second option, now deprecated)
Trying to understand what the "best practice" solution to this problem is — have others deployed solutions they're satisfied with?
For personnel blog application should be okay to connect your edge function direct to database. Unless, this small website becomes super popular.
Eventually, For your application hosted on edge, another API endpoint is needed. It can be REST API or GraphQL does not matter. What matters is that, at the front this endpoint will accept loads of request from your edge functions (nodejs applications on vercel/netlify) and at the back, it will communicate with database, pool the connections and caching so on.
You can add nginx load balancer in front of that API endpoint to make it scale.
There are tons of options to engineer it
Is it possible to fetch database data directly from Front end app(Angular or any other) with out server?
I am not getting any idea to try.
No, you need a server of some kind, whether it's Java, C#, NodeJS, or something like GraphQL.
Let me clarify something, remember that your Angular and React run in Javascript, which run on the user's browser, on the user's computer, whereas the backend code runs on your server which you have a lot of control over. The browser is very much a sandbox and has only limited capabilities due to security concerns and it's development over the years.
Now, you could say, that someone has a API that you can consume without a database server - however, you are probably still not talking to their database server, you're talking to their back-end app server.
There are many services out there such as AWS, Firebase, which can provide this, and are dubbed "Serverless" because the main construct is an application or service, rather than a server.. But somewhere, there's a server.
I have a MySql database set up and a mobile app that should be able to write/read to and from the database.
The data being stored will be posts, comments, votes, etc.
Eventually, I might create a website that uses the same database.
My question is, do I need some sort of middleman (restful) service running or can I just connect straight to the MySql db from the client code (either the mobile app or website)?
Introducing a REST api into the middle would be much beneficial in a lot of ways.
Improve generalization and reuse. (REST api can be used by both mobile client and web client, no need to do the same work twice)
Can maintain business logic centrally. (If there's a logic to change or a bug fix, no need to correct in 2 places)
Can be easily exposed to any other app/client which would need the set of operations provided by the api.
Extending and maintenance of the app would be much simplified and would take minimum effort.
Especially with the mobile application, where you have much less control of updates, it seems better to use some middle-ware to connect to your database.
Say for instance your website needs a little change in the database that would break an active version of the mobile application. A web service could catch that for you.
What about a new version of your mobile app that needs a change. Again a web service can handle that for you.
This is all about cutting dependencies and keep the complete ecosystem adaptable.
Whether this is a rest or any other type of web service is a completely different discussion.
Im just in the process of putting together the base framework for a multi-tenant enterprise system.
The client-side will be a asp.net mvc webpage talking to the database through the asp.net web api through ajax.
My question really resides around scalability. Should I seperate the client from the server? i.e. Client-side/frontend code/view in one project and webapi in another seperate project server.
Therefore if one server begins (server A) to peak out with load/size than all need to do is create another server instance (server B) and all new customers will point to the webapi's on server B.
Or should it be all integrated as one project and scale out the sql server side of things as load increase (dynamic cloud scaling)?
Need some advice before throwing our hats into the ring.
Thanks in advance
We've gone with the route of separating out the API and the single page application. The reason here is that it forces you to treat the single page application as just another client, which in turn results in an API that provides all the functionality you need for a full client...
In terms of deployment we stick the single page application as the website root with a /api application containing the API deployment. In premise we can then use application request routing or some content-aware routing mechanism to throw things out to different servers if necessary. In Azure we use the multiple websites per role mechanism (http://msdn.microsoft.com/en-us/library/windowsazure/gg433110.aspx) and scale this role depending upon load.
Appearing to live in the same domain makes things easier because you don't have to bother with the ugliness that is JSONP or CORS!
Cheers,
Dean
Could someone please explain to me in a simple way, what is a web service?
Please correct me if I'm wrong. I have a DB hosted somewhere in the web, and I want to perform DB transactions from a desktop application as well as a mobile application. Can this be done through a web service ? Someone mentioned it to me and I wanted to make sure this could happen.
Here's a good explanation on Wikipedia.
A middle dynamic content processing and generation level application server, for example Ruby on Rails, Java EE, ASP.NET, PHP, ColdFusion platform
The middle tier of a 3-tier application is often the web service
i want to perform DB transactions from a desktop application and a mobile application, can this be done through a web service ?
This is Exactly what a web service is for.
A web service allow you to create multiple front ends if needed, and serve your database data to all of those front ends. You can also open up the API and allow third party developers to access the web service and thereby access the data of your application in a controlled environment.
It's considered a better practice for larger applications to access a web service or a middle tier rather than directly access the database.
In your case, a web service would involve setting up your DB behind a web server that listens for incoming requests, performs the appropriate DB operations, and returns whatever data is appropriate. Then, your desktop and mobile applications could send a http request and the DB would respond appropriately. This would let all your applications access the same DB.