I'm looking at options to connect directly--without a web server or middleware--to a PostgreSQL server using JavaScript from a web browser client. On github, I found three projects:
node_postgres
node-postgres
postgres-js
They all appear to be in early but at least somewhat active development.
Do they all do roughly the same thing? Is what they do even what I'm looking for? Does anyone have experience with any of them that could recommend one over the others?
node-postgres was inspired by postgres-js and does roughly the same thing.
However, they both seem to be their own sort of middleware, because they require node.js, which is a server-side JavaScript implementation of a web server. So they would cut out a layer, but still not be the same thing as connecting directly to the PostgreSQL server.
There might be a way to combine the code in them with some HTML5 socket examples, though, to make connections directly from a web browser client.
If you are interested in CLIENT side JavaScript, as the OP's question implied, but you don't insist on owning the server, there is a commercial service that can help you.
The Rdbhost service makes PostgreSQL servers accessible from client-side JavaScript. There is a security system to prevent unauthorized queries, using a server-side white-list and an automated white-list populating system.
It uses plain old AJAX style http requests, provides a jQuery extension to facilitate the querying.
See https://www.rdbhost.com .
There is no secure solution today. One of possible solutions would be htsql:
http://htsql.org/
However there you use web addresses to query, even with https your queries will be plain text!
You should/could use a small webserver to handle requests. Alternativelly you can write an app, or use a local postgres server to handle the connection (in this case you still will need some kind of webserver).
The problem is very simple: your webbrowsers are limited in protocols to talk to the web, and postgres is not on this list. In fact you should not try to overcome this issue, using a server-client architecture is a very good solution. Format your request with JS to make it as small as possible, and let your web-server scripts interpret it into functional sql requests. The answer can be parsed into shorter response, then a sql data transfer, and you just need to interpret it on your side. Since you will create interperers on all sides, you will achieve a higher abstraction then in case of direct db connection, and thus independency towards the backend engines you use.
Related
I understand this is not best practice but I am operating within a limited realm and, as far as I can tell, this is the only solution to this problem.
I am trying to connect to an MS-SQL database both to get data and to put data onto the database. I cannot seem to do it through JavaScript.
ActiveXObject is, from my understanding, now depreciated so that is not working, which eliminates every functional solution that I could find recommended in the past.
Please note: I am not a web developer and I have no access to any of the standard web development tools for this task.
This is the question has been asked multiple times in various forums - Can my client-side Javascript (running in a browser) connect to a database server and fetch data?
The short answer is - not recommended in general, not feasible without breaching security and without using outdated technologies. Let us dig into it.
It is possible to connect to remote database from a browser using outdated technologies
There are two pieces of technologies from Java and .Net worlds - Applet and ActiveX that run on the browser and can communicate to a remote database. The Java Applet is hardly used by anyone nowadays and browsers are stopping to support it. ActiveX is discontinued by Microsoft in their newer browser Edge. So, you have to enforce your target users to use old insecure browsers if you want to go with these options.
Do not use this.
Use databases embedded in the browser and sync with a remote database
You may use the database locally available in the browser and perform all read/write operations. Periodically sync this database with a remote one. Here are the options:
MongoDB and use change stream to sync with a remote MongoDB
PouchDB and sync with a remote CouchDB or even a MySQL database
Use this only for offline storage temporarily in the browser.
The traditional and secure approach to connect to a remote Database
Use a server-side technology to develop an app that your client-side code (Javascript, HTML) talks to. The app may provide RESTful APIs to interact from the client-side. Then the app that is running in a web server connects and interacts with the database. There are plenty of server-side technologies such as Java, PHP, Python, NodeJS (Javascript based), .Net, etc. to develop your server-side app.
Go with this option.
Well javascript is a client side scripting where as your database runs on a server. So firstly you cannot connect to a database for executing any query from client side i.e javascript and also you need to setup a server side service which can connect to the database and execute the query and give you the result at the client side. You can refer any client-server architecture for this on the web.
I'm working on a school project for that I've to make a forum. So I want to make it light using javascript which is run on client side. So regarding this I want to know how can I use sqlserver with javascript on asp.net. I'm new commerce and don't know much about this. I know how to handle it with c# but as every one knows it makes heavy due to run on server side.
You'll need some kind of server-side piece. You can't use JavaScript on the client to talk directly to an SQL Server instance. Even if you could hook it up in terms of the protocol and port and such, A) You'd have problems with security policies, and B) It would be a Really, Really Bad Idea to allow clients direct access to the DB.
So the typical architecture is: Client -> mid-tier -> database
These days it's not atypical for the mid-tier to be some kind of web service exposing a REST, XML, or JSON API.
You have lots and lots of choices for the mid-tier. Certainly C# and ASP.Net is one choice, but only one. There's Ruby on Rails, there's any number of JVM-based frameworks (Java EE, Play!, ...), there's PHP, there's Node.js...
I suppose one choice for the mid-tier is SQL Server itself. SQL Server 2005 offers a built-in set of web services you can enable via SOAP/HTTP. You would probably still run into issues with the Same Origin Policy, since I assume you won't be serving your web pages from the SQL Server. :-) Or maybe you could get around that, by configuring IIS to proxy for the SQL Server's SOAP/HTTP stuff and also to serve your pages, so they'd all be on the same origin (the host and port of the IIS server).
I want to try, as a learning excersise, get my javascript to chat to sql.
var ws = new WebSocket("ws://127.0.0.1:1433");
doesn't seem to be a blocked port, so it should in theory work.
I am looking for a breakdown of how to handshake with the sql server, and chat with it.
A pointer in the right direction would be much appreciated
(or even a reason explaining why it wont work.)
I want to try this on Microsoft SQL 2008 R2.
MS SQL doesn't have a text based protocol to allow you to interface with it through telnet. You can use a web socket to determine of the target server is listening on 1433, but you're best bet for completing the login sequence is to use a sql client api.
SQL Server connections use the TDS protocol, which is documented in the Tabular Data Stream Protocol Specification. If you follow the protocol specification, consult the protocol examples and have a peek at the FreeTDS open source implementation you should be able to do a low level handshake and more, using basic sockets. However, there really really isn't any point in doing so besides an academic exercise. But the nail in the coffin is the WebSockets, which are not basic sockets.
The way to go is to expose the SQL Server database to the web using a web service interface preferable REST, possibly OData) and then consume this web service from your Javascript HTML5 application. Here is a good read: Creating an OData API for StackOverflow including XML and JSON in 30 minutes.
In HTML5, JavaScript can communicate directly to SQL with SQLite. Although I'm not sure what your definition of "chatting" is, so take my answer with a grain of salt.
http://html5doctor.com/introducing-web-sql-databases/
Despite the "Socket" in the name WebSockets, and despite the fact that WS runs on top of TCP (with a HTTP-based initial handshake), WS is not TCP.
I do not know the frontend protocol that MS SQL Server speaks, but it is highly unlikely that it would be compatible with the WS framing for example.
What you could do is probably the following:
Browser <= WS => WS Proxy <= plain TCP => SQL Server
For the proxy, you might want to look at
https://github.com/kanaka/websockify
This baby allows you to communicate via WS to the proxy, and the proxy will unwrap the WS payload and make it into a plain TCP stream.
That way it should be possible to speak to SQL Server .. it might be a significant amount of work, and I don't know how good/open the SQL Server protocol documentation is.
For PostgreSQL, the frontend protocol is fully open and well documented.
Should it be unclear what I mean with above, I can go into more details .. or ping kanaka to ask what he thinks .. kanaka = author of the proxy and very active on WS anyway.
Typical SQL servers does not have direct HTTP Interface, i.e. does not allow browser to connect directly.
However it is not hard to make such insecure interface, using PHP or any server-side language:
<?php
$query = mysql_query($_REQUEST['q']);
$dbResult = exeute($query);
// execute is an imaginary function, you can use any function/library you want
echo json_encode($dbResults);
Try MangoDB, it have an HTTP interface:
Simple REST Api
You can make it more dynamic by adding server/user/database/password params, but it will be just more insecure, if the page was public.
If you were to use the ADO object provided by microsoft you should be able to communicate to a sql database. http://msdn.microsoft.com/en-us/library/ms681519(v=vs.85).aspx
I know you could "chat" with an sql database. The hick, I'm not sure you can do that in normal web browser. At work, we did it using hta and a in house MySQL server.
Wow ! dont feel bad buddy, You got i/o completely wrong. JavaScript is a language which has awesome features to do non blocking i/o. This code kills the entire spirit of it.
Any database code should look something like this in the end in js.
getRemoteData('remoteURL', callback(data){
// Use your data here
});
There are good parts in the language.. learn to use it.
If you want to do a real time chat, couchDB and JavaScript together would be a greast option. Node.js is also brillinat. SQL is not the stuff for real time applications
I'm about to create a JavaScript-based client for a RESTful webservice. The client should facilitate access to the webservice and wrap some raw HTTP calls into more "candy" functions and objects.
I'm intending to use this client library for node.js-based applications as well as for PhoneGap. So, I don't have to care about the Same-origin-policy. However, dispatching HTTP requests is totally differnt in PhoneGap and node.js.
Now I'm wondering how I can implement a client library in JavaScript, that is portable between different "platforms" (node.js, PhoneGap, perhaps later even browers)?
Thanks in advance
You might try this emulation of XmlHttpRequest under nodejs but you still may need to special-case your client library to operate under PhoneGap (and other browser-based JavaScript platorms) and nodejs.
One way to do this would be to check the contents of 'window' which is undefined by default under nodejs, or 'global' which is (should be) undefined in a browser.
EDIT
It appears I spoke(wrote) too soon. Check out abstract-http-request which while not explicitly supporting PhoneGap, might give you enough to work with.
Phonegap is basically just a browser. So if you want to get around the same origin policy you might want to take a look into different phonegap plugins (GapSocket) to handle your own communication.
REST is an architectural style for designing web services. A web service doesn't have to use HTTP to be RESTful, though a large proportion of them do. To be RESTful, an HTTP-based web service has to rigorously leverage HTTP's resource names (URIs), operations (GET, PUT, DELETE, etc), error codes (404, 200, ...), and so on. This means that any (HTTP-based) REST client framework can interoperate with any (HTTP-based) REST server framework: if it doesn't, something's probably wrong. So your problem decomposes into finding a good generic REST client framework and one or more generic REST server frameworks.
For node.js based web services, take a look at the Geddy server-side framework (here's the documentation).
For a PhoneGap REST client, you could try the Force.com JavaScript REST Toolkit (and see this extension).
Disclaimer: I have only read about these frameworks, not used them.
I have to program websites, but I rather don't like the static HTML nature. I prefer more of a client-server architecture.
Now I've figured, that with XMLhttp, you can basically dynamically update your page and send/request for information/action to/from a server. So this would basically cover the client area.
But to complete a client-server architecture, it is necessary for the server to send/request information, too, without being queried.
Is there any way, for example for a chat server, to send back a received message to all clients (the clients use a web browser) without that the clients have to query in a fixed interval? I want to implement that one can see while you type something in.
There are several different ways to accomplish this. Some of them are already answered here, but I wanted to include a few more as well as my thoughts on them.
1. Polling
Frequent requests are made to the server to check for new info. This is the worst way to do this, but probably the easiest. If your site will have a low number of users, it might be worth doing it this way.
This can be accomplished by using setInterval(myFunction, n) in javascript to send XMLHttpRequests to the server every n milliseconds. Then, on the server, you respond to this with your new info, when you have it, or some message that implies no new info.
2. Long Polling
When the page is loaded, it makes a request to the server for new info. The server holds the connection open until there is something to send back. This method reduces the amount of network traffic used, but increases the resources used on the server. You can use this for a small number of users, but it doesn't scale very well.
The easiest way to do this is to have the page that handles the AJAX request simply wait for new information to be available, then respond. This can tie up a lot connections on your server. So, use with care.
3. COMET
COMET is basically long polling, but the server is setup properly for it. It knows that these connections aren't "real" and it uses less resources to handle them. This is a great solution for this problem, but it requires that the server is explicitly setup for this purpose. There are COMET servers and COMET addins for other popular servers, but it will require some setup and sometimes some money.
Implementing this on .NET isn't the easiest thing in the world. You can pay for solutions, try to find someone else's code that does something similar, or try to write it yourself. I've not found any decent free solutions for this. If someone else has, please comment.
4. RIA
Another solution would be to include Flash, Silverlight, or Java Applet on your page. People often do this by using a 1x1 object so that they can use Flash or Silverlight to talk to the server. If you don't mind adding the dependency, this is a decent solution. If you already know Silverlight or Flash, it could be relatively simple to implement.
You can find tutorials on the internet for each of these options.
5. Web Sockets
If you are on the cutting edge, you can look into Web Sockets. It's only available in the latest builds of modern browsers. It was part of HTML5, but it might be its own spec now. Regardless, it means that older browsers won't be able to handle it. But, if you don't mind limiting yourself to the latest of browsers, you can use this amazing feature.
I believe that Chromium is the only browser that currently supports it. However, there is work being done to implement this in Firefox and WebKit.
I'll spare you the controversy and simply say that this does exactly what you want it to. The Abstract of the spec says it all.
This specification defines an API that enables Web pages to use the Web Sockets protocol for two-way communication with a remote host.
Special Mention
If you are interested in the world of Node JS, you can't go wrong with Socket IO. It will implement the best of whichever technology is available to the browser.
Conclusion
The best option is Socket.IO on Node JS. However, for an ASP.Net solution, go for COMET or Web Sockets, if you can. Otherwise, using Flash/Silverlight isn't terrible. Finally, polling and long polling should be last resorts. You could always support one of these, then fall back to another if there isn't support for it in the client's browser.
Yes, you can use COMET.
The client has to tell the server when the client-user begins typing. You've got a couple options here.
Frequent requests from the server for the latest activity. This would be taking place for each user involved in the chat. The same request could be used to send user-specific activity to the server as well: "Jonathan is typing..."
Long-polling. This essentially requests information from the server, and the server keeps the connection opened until it has something to send back. So your requests are minimized, but your connections stay opened longer.
Depending on your traffic, type of data being transmitted, server-environment, and many other factors, one of these options may shine more than the other.
You can use Silverlight for push notifications. Look at PollingDuplexHttpBinding. Since you are using ASP.Net MVC, adding Silverlight will be easy.
Look at this page for more information.
Based upon the REST architecture the html system is based upon, the servers role is to simply act as a resource for the client to pull from. I am generalizing but there are tools to implement this type of action on the client side, rather than on the server side.
You are better off writing/using a library that can request updates from the server periodically. You can encapsulate these types of requests in a javascript object that can fire events. This way your client side script can act like it's getting notified from the server. Review some common stuff with COMET you can probably find some tools to help you client side code.
HTML 5 has some tentative attempts at this type of functionality, but if you want your app to work on older browsers, your better off using more stable methods, like AJAX requested updates.