I have a simple database application in mind and I am thinking of making it browser-accessible instead of creating a standalone one.
I almost finished creating the DB schema in a PostgreSQL Server and I will now start developing. My first idea was using PHP or Ruby On Rails to manage the backend logic and interfacing with the DB, but since this application is fairly simple I think that I can easily implement all business and data manipulation logic with JavaScript or with the DB triggers.
So I am now wondering: is there a way to directly send the queries to a PostgreSQL Server, without server-side scripting?
More generally: can a PostgreSQL(9.3) Server receive the queries in Http requests and provide the results in Http responses?
I know this might sound stupid, and I am not looking for answers like "Use JS for presentation, PHP for logic and DB for data storage". I believe this is a lightweight solution for a very simple application, so I want to try it if possible!
Yes, That is possible.
What you can do is to send it via REST API. (post, get request ).
Here are some reference for you:
https://github.com/begriffs/postgrest
https://github.com/pgrest/pgrest
Please take a look at this for more HTTP API
[update!]
This idea is currently not possible (as I tought when I answered you before).
I tought it was possible after checking this node-postgres library written in javascript but it uses Node.js specific functions not present in the web browser as stated by the library's creator himself and this answer at stack overflow.
There is this package called browserify that exports a Node.js javascript file into a browser front-end ready javascript file. The problem with node-postgres + browserify is that it throw some errors during the browserification process, precisely when it tries to access libpq (an API written in C for accessing PostgreSQL).
I'm sorry I have mistaken you
Yet I still have a suggestion for you. You can try CouchDB if you really want to build a backendless/serverless application. It is natively RESTful, handles authentication and authorization at some extent, is opensource but unfortunately: NoSQL. It processes queries based on Map/Reduce paradigm and Mango query language so it's an entire different world for you to discover if you are used with SQL.
[old answer, I'm leaving it here for learning purposes]
Have you considered using a PostgreSQL driver for JavaScript? It is not RESTful, but it can connect to PostgreSQL and query it!
The library is called node-postgres and you can download it via npm
https://www.npmjs.com/package/pg
Just don't forget to enable SSL connection in the PostgreSQL server and in the client to avoid man-in-the-middle attacks.
An here's a tip: if you need an ACL for allowing or denying selects or inserts for specific users you can manage that through PostgreSQL user management and privileges. PostgreSQL has row level security, allowing you to define which rows in a table can be selected updated and deleted for a given set of users or groups.
Related
I am a developer who wants to be able to make cross-platform applications and have came across Xamarin and React Native.
Since the language that Xamarin uses is C#, this means that the code has to be compiled before the application can be run. React Native, however, uses JavaScript. Since JavaScript source code can be seen on websites, and is downloaded into the webpage unlike PHP, this means that the user on the client end can easily view the source code. If the user is able to get to the source code easily and the application in question connects to a database, this means they would be able to view the password, making the application insecure.
The question is, if I where to make an application which connects to a MySQL using React Native, would the user be able to easily view the source code like they can on a webpage, or is it compiled like Xamarin is, making it harder to view the source code?
The javascript does not compile to native code. It uses a bridge to communicate between javascript/native components. JS is obfuscated but that is about it. You should not be storing any secrets client side.
See: https://github.com/facebook/react-native/issues/1093
'As #vjeux said, we have no immediate plans to add encryption for JS bundle files, and yes, under the currently recommended bundling instructions, your JS will be included as plaintext that can be extracted and de-obfuscated with relative ease.'
He goes on to mention a way to base64 encode the jsbundle to deter 'casual' hackers but then explains it will not stop a 'determined hacker'.
You should not connect the client directly to the DB. You need a secure server to handle authentication, and retrieve and validate db queries.
Nothing is secure on client. So you must validate all db queries before calling the db with them. See: https://www.acunetix.com/websitesecurity/sql-injection/ 'An SQL Injection needs just two conditions to exist – a relational database that uses SQL, and a user controllable input which is directly used in an SQL query.'
By allowing the client to directly connect to the DB, you cannot prevent the oldest of attacks.
Consider a ClojureScript web application using reagent where the reagent components are subscribed to a single db atom containing a vector of maps. The contents of this vector is different for each user and has to be queried from a mongo database ( which is updated with regular intervals ). The database might be hosted by a third party. Considering that CongoMongo, Karras and Monger are Clojure ( not ClojureScript ) libraries what would be the best way to connect to MongoDB from a single page ClojureScript/React.js using Ajax?
This “answer” is more of a comment but here goes.
If you don't absolutely need a Clojure backend, I'd recommend having a ClojureScript-only single-page app without any Clojure wrapper to Mongo (so no need for Sente either). As Timothy Baldridge (of Cognitect, so he knows a thing or two about this 😛) pointed out, your ClojureScript app can just make HTTP REST requests to the database.
cljs-http is a ClojureScript project that uses Clojure's core.async library to make HTTP requests and is perfect for interacting with REST APIs if you know or can learn core.async.
A more conventional (i.e., callbacks) approach, but still very ClojureScript-friendly, is to use Google Closure's goog.net.XhrIo library. I have an example here of connecting to a public REST API using XhrIo and re-frame (built on top of reagent, and highly recommended) that may help show how to get started.
Using either of these ClojureScript/JS libs, you can make requests directly from the ClojureScript browser app to the database, get replies, parse the JSON with (js->clj (js/JSON.parse json-string)) or with transit-cljs, and do something with the result.
Since Mongo has a fairly simple REST interface (https://docs.mongodb.org/ecosystem/tools/http-interfaces/#simple-rest-api), I'd be tempted to just write my own CLJS code that calls the Mongo server. Depends on your security requirements. But writing the CLJS code would be no different than any other remote request. Just a bit of string concatenation and parameter serialization.
You could use sente to get communication going between the Reagent application and your web server. This SO answer references an example client/server application that consists of a web server with browser access, giving you some buttons to press that return information from the server. It is not Reagent - but you can substitute what they use. It is a starting point example that works out of the box.
Then build up the example's web server so that it communicates with the three Clojure libraries rather than just returning static text as it does.
I would like to use Meteor (Node.JS) to develop an application that will be used by 3,000+ concurrent users on a large size database.
I have looked at the nice examples and the idea to push changed data to the clients is very nice and very useful, but before I start the development I want to be sure how it works behind the scenes to be sure that when I have the application running with all these users it work fast with standard hardware.
I also require this to use Oracle as a database, but not sure that it is supported and if not, what are the requirements from an Oracle package to enable this facility.
I think that the server is having an active on going non-blocking query on the OPLOG table in mongodb and that is how we get the callback for all the changes in the database. Is that correct ? if so, is there a similar way to do it in Oracle ?
Thanks Roni.
I also require this to use Oracle as a database, but not sure that it is supported and if not, what are the requirements from an Oracle package to enable this facility.
Nope, meteor is currently mongo-only as they have implemented an in-browser library called minimongo. My guess is this project will never support oracle, but who knows. There is no mention of oracle support on the meteor project roadmap
Just happened to come across this question while searching at google.
However, if there are no native solutions. We can always figure out a way for a medium language to issue publishing.
Example Case:
Python will be used for synchronising data between Mongodb and Oracle (24/7 operation using cx_Oracle and MongoDB drivers from python)
Meteor Server will keep watch on what to publish
Meteor clients/browsers that subscribed to the channel that will be updated with oracle data.
I'm new to CouchDb and am trying to comprehend how to properly make use of it. I'm coming from MongoDB where I would always write a web layer and put it in front of mongo so that I could allow users to access the data inside of it, etc. In fact, this is how I've used all databases for every web site that I've ever written. So, looking at Couch, I see that it's native API is HTTP and that it has built in things like OAuth support, and other features that hint to me that perhaps I should no longer have my code layer sitting in front of Couch, but instead write Views and things and just give out accounts to Couch to my users? I'm thinking in terms of like an HTTP-based API for a site of mine, or something that users would consume my data through. Opening up Couch like this seems odd to me, though. Is OAuth, in Couch's sense, meant more for remote access for software that I'd write and run internal to my own network "officially", or is it literally meant for the end users?
I know there might be things that could only be done through a code layer on top of CouchDB, like if you wanted additional non-database related things to occur during API requests, also. So thinking along those lines I think I will still need a code layer, anyway.
Dealer's choice.
Nodejitsu has a great writeup on this sort of topic here.
Not knowing your application specifics I'll take a broad approach...
Back-end
If you want to prevent users from ever seeing your database then make it back-end. You can pipe everything through something like node.js and present only what the user needs to see and they'll never know anything about the database.
See Resource View Presenter
Front-end
If you are not concerned about data security, you can host an entire app on CouchDB; see CouchApp. This approach has the benefit of using the replication mechanism to control publishing your site/data. The drawback here is that you will almost certainly run into some technical limitations that will require moving CouchDB closer to the backend.
Bl-end
Have the app server present the interface and the client pull the data from the database separately. This gives the most flexibility but can be a bag of hurt because even with good design this could lead to supportability and scalability issues.
My recommendation
Use CouchDB on the backend. If you need mobile clients to synchronize then use a secondary DB publicly exposed for this purpose and selectively sync this data to wherever it needs to go.
Simply put, no.
There's no way to secure Couch properly on a public facing site. There's no way to discriminate access at a fine enough granular level. If someone has access to any of the data, they have access to all of the data.
Not all data on a site is meant for public consumption, save for the most trivial of sites.
I'm using delphi at the moment and have a program that connects to another program (a server) which has the mysql database on it and sends the data back to the client. I have a web server that has the server program and the database but my question is can I just go straight from the client program I have made (windows and future mac) to the mysql database on the web server? Or do I really need the server program? If so, what do I need to do to connect my client program to the MySQL database over the internet?
You should be able to access the mysql database directly as long as you've created a user/pw combo for the database that allows remote access (Security discussion aside). You'll then want to search for a compatible mysql library that would ease the communication between your program and mysql. At the far technical end you might have to read/write directly to the mysql socket but that's possible as well.
Depends on whether your client programs will continue to be native applications or whether you plan to migrate to browser based clients.
If they're native applications you can obtain library components for the languages they're written in which will be able to communicate directly with the MySQL database. There are plenty of options for Delphi; I'm not familiar with what options might be available for native Mac development (but, of course, Embarcadero is in the process of rolling out a Delphi that can generate Mac applications).
If, however, you're planning on making your clients browser-based, ajax solutions want to talk to a web server rather than a database server. In that case, you will need to maintain your middleware. For a discussion of whether it's possible or desirable to have a browser based application communicate directly with a database server see this question.
I would use SOAP/XML for this, and leave the SQL out of the client entirely.
This is a typical use case where REST (for example using JSON encoded database records) can be helpful. It is easy to implement a Delphi client using lkJSON or SuperObject, to put the database records from the HTTP response into a TClientDataSet.
Yes, it's possible, but is it a good idea?
here's a basic discussion of 2 tier v 3 tier architecture