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.
Related
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.
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.
We're developing a cloud based web application for customer management. One of the main goals i the capability to connect to different local applications on the customer endpoint.
As example, we don't want to have a customer database in out application, the customer should be able to search within his local ERP system right away.
What we need is not much. Only a client on the customers server with access to the local SQL server as well as the COM model.
But as webdevelopers and mainly going with PHP the question came up, what technology we should use?
I've got two approaches in mind:
NodeJS
Lightweight, Javascript and with the Express and winole32 extension we should have everything we need. But the deployment and installation as a service seems to be a bit wacky.
C# .Net Web API
Also a good approach I guess since the client servers are allways windows. But is there a way without IIS?
Or do you have something completely different in mind? It should be very fast and compact. So its basically just a RESTservice that can be deployed with ease.
Thanks for your inputs and thoughts.
C# .Net Web API Also a good approach I guess since the client servers are
allways windows. But is there a way without IIS
It is called OWIN and it is properly documented (web api self host is a good keyword) and works like a charm. Using that on various services to expose an API into the service.
I have been attempting to teach myself quite a bit about silverlight, and how it all works, for the past few weeks, and I am to the point in my app development where I would like to connect up to my web server's MySQL database.
My web server is capable of running ASP.NET pages, but is Apache, and natively runs PHP (which is what I'm far more familiar with). It has a MySQL database engine, and I am very well-versed in your typical dynamic page creation with PHP and MySQL.
What I'm NOT familiar with are these "Web Services" that people keep mentioning every time I find an answer regarding the question of "how do you connect silverlight to a database?"...
So my basic question is really one of data FLOW, and where everything fits in the puzzle, and how to get it all working in this particular configuration. Most of the answers I have seen deal with IIS instead of Apache, ASP.NET instead of PHP, and MS SQL Server instead of MySQL.
Also, answers tend to start using abbreviations and acronyms without actually explaining what they stand for.
For example: What is WCF, and RIA services, and how do they fit in to the puzzle as a whole?
I suppose I'm just looking for a top-down overview of the structure of data flow on a MACRO level, not on the micro (code) level.
(Edited to add:)
Also: I have done vb.net apps in the past which have used MySQLConnector.NET to pull from my web server's database remotely, but I understand that the client machine would have to be whitelisted as a remote machine, meaning I'd have to open my MYSQL server up, and make the access mask basically %.%.%.% in order for any client to connect... and that is undesirable... so if I understand things right, the web service runs on the web server, and the client sends requests to it, and the web service acts as an intermediary, grabbing the data from the database (possibly with some sort of "stored procedure" look-alike?), and passes the data on to the client... which also means all database access credentials are on the server, and not inside the (potentially hackable) client...
Do I have it right?
Also, when answering, I need to know where the access to the web services is... in the silverlight APP project code, or the silverlight WEB project code...
I have found this wonderful tutorial that helps to explain it...
http://www.designersilverlight.com/2010/05/23/php-mysql-and-silverlight-the-complete-tutorial-part-1/
Here is how I understand it all working.
There are 3 "Layers" to the process: The application, the web server, and the database.
The application calls out to the web server to execute a script file (like a normal PHP script). There script file can have normal URL variables passed to it (like script.php?foo=bar, so $foo is defined as "bar" in the script)... so you can use those URL encoded variable/value pairs to tweak your script results as you would normally with a web page.
I imagine you would have one script per TYPE of database query, with var/value pairs to tweak your results. So on your web server you would end up with numerous PHP scripts, just like you would normally for a website with different pages, and you pass variables in to those scripts to customize the results.
For example, for users, you could have a get_users.php script that would return all users...
but get_users.php?loggedin=true would get all users that are logged in currently
get_users.php?loggedin=true&ingame=true would get all users that are logged in and in a game... You just script the logic and the resulting SQL query accordingly.
All of the results are encoded either with XML or JSON (Javascript Open Notation: see What is JSON and why would I use it? ) for transport to the app... the app, in effect, is reading the results of an echo of the JSON encoded stuff.
If you were to open these scripts in a web browser, the only thing you would see is a text printout of the JSON data... no web page... just data that is read by the app and then decoded in to objects.
So in effect, the silverlight app is reading a text output of a PHP script executed on your web server, and interpreting the output.
^^^^^ THIS IS THE SHORT ANSWER TO MY QUESTION. :)
To be blunt, the whole use of the terminology "web service" is misleading, and what was really leading me astray. I thought it was some sort of service or app you had to install on your web server just like PHPMyAdmin or something.
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.