I'm trying to host a database (on either AWS or Heroku) to store data from my web app. I also need to create an API to interact with the database. Basically, like this picture from Google.
Image source: https://dzone.com/articles/an-introduction-to-restful-apis
What I'm trying to figure out:
Is the API and database typically hosted separately? Or are they often hosted together? I'm not sure if the API and DB are together 1 component (with sub components being API and DB), or if they are 2 separate standalone components.
If they are 1 component and they can be hosted together, then I believe you can use something like Express.js for your API which can query the database and respond to HTTP requests from the website.
If they are 2 separately hosted components, I feel that means I have to have 2 APIs, unless my API can directly talk to the database (I'm not sure if this is proper). So I would need my API to talk to some server side technology (PHP, Java, etc.) which would then query the database and return result to the API. So basically my API is talking to an API which is talking to the database. I'm not sure if this is over complicating things, but it sure seems like it.
I'm trying to clarify how this process works.
Is the API and database typically hosted separately? Or are they often hosted together?
Since the API service needs to make lots of requests to the database, you want the minimum network lag possible between them.
So generally they should be hosted together. What that means depends on the style of hosting. Using the same cloud service makes sense if you are using something like AWS Lambda. Otherwise using the same machine for both the database and HTTP service until you scale to the point where you need to separate them.
If they are 1 component and they can be hosted together, then I believe you can use something like Express.js for your API which can query the database and respond to HTTP requests from the website.
This is a common approach.
Related
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 currently have an Electron ReactJS application on hand that uses CouchDB as its backend for syncing and real-time updates. I have been tasked with "porting" the backend of this application to an existing webserver. The goal is to use the existing permission management and business logic implementations. At the same time the intent is to refactor the data structures as the data is heavily relational in nature. That said, personally, I would keep the app on CouchDB as it full-fills the main "offline-first and real-time" requirements and just add the missing authentication and permission layers, but management wants otherwise.
The port would be using an existing web server (running Play Framework with Scala) and a relational database (MySQL). I have been scavenging the web for a good existing solution. The "simple" solution that came to my mind sounds tedious and like I'm reinventing the wheel. My idea was to create an API and on top of it also send real-time updates to the users to which a change is relevant via web sockets. For state management on the client I would use Redux + Redux Offline. While this would work, this would require a lot of manual wiring of CRUDs on the backend server and the according requests and mutations on the client.
I have taken a look at AWS AppSync, Meteor.js and Apollo. AWS AppSync sounds like exactly what I could use, but it relies on the database being accessible to it, which is not an option due to my DB instance being on premise. From Apollo, the client part sounds like an option I could go with and then use Sangria on the backend. I suppose I could also drop the idea of Redux and use Apollo's "local state", although this requires more thought as I'm not familiar with it.
All of the latter solutions involve GraphQL. While this would still require quite some work on the backend, the communication itself between the frontend and backend would be simpler to handle.
In my case where the use of an existing backend server is a must, are there any more elegant solutions for offline-first collaborative real-time apps? Am I missing something?
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.
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.