Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have an internal database at my work. At the moment we are using excel to import data, but this is very error prone, so I would like to replace this with some javascript based application which exposes some of the data in lookup tables in dropdown menus, for our customers to fill in, on a public website.

So my internal database lives on an internal server not viewable by the public.

How should I go about building an application that communicates with the internal database, and only exposes certain tables?

Is some middleware like Django, that rather than using an SQL database uses some other way of getting the lookup values (I have a REST interface set up on the main database).

(To clarify, I am looking for a server side technology that I can put on a public facing server, that will communicate with the internal server).

share|improve this question
    
Is there anything about selective replication in one or both directions that disqualifies it? –  Blrfl Apr 20 '13 at 1:38
add comment

2 Answers

Since you already have a REST interface setup to access your data, I would consider using Javascript, jQuery, and Backbone to create a browser client to interact with the data. Backbone very much embrases REST, so you should find it pretty straight-forward to use. If you take an approach similar to this, you will need to make sure that your REST I/F is accessible to your customers. If your REST I/F is part of your DB, I'd be pretty nervous about exposing that directly to the "world". If your REST I/F is a different middle-ware, that can probably be exposed while still remaining secure. When you explore Backbone, you might also look at backbone-relational, which provides a nice way to relate different models together (if you have a complex set of tables/data). You might also consider using Marionette with Backbone, which provides some nice helpers and organization to the out-of-the-box Backbone setup (by default, Backbone let's you make a bunch of decisions, which means writing more code - Marionette makes a bunch of those decisions for you, which means less code to write).

An alternative approach would be to use a more standard non-AJAX-ish, non-REST-ish ... more traditional "web app" approach: You could use Rails or Java or PHP, etc., and their many frameworks to build a web app that provides access to the data. Depending on how you approach this, you would write code for that App Server that creates the HTML served to the browser, and likely have little Javascript (though that's still an option), but much more code on the server side.

These are trade-offs you have to decide between based on your experience and the details of the project. Also, note that Backbone and Marionette are much newer technologies, so you may find less documentation and helpful websites, but you may also find more people excited to work on that project since they get exposed to those technologies. Since you already have a REST API, I'd probably lean toward the Backbone type approach. Obviously, all of this is just my opinion based on my experiences working with these technologies. There are certainly other approaches and technologies that you could consider also.

share|improve this answer
    
That will take care of the front end, (I was planning something along those lines with Angular rather than backbone) but I need something on a public facing server, that can communicate with the internal server. The front end will not be able to see the internal database server. –  wobbily_col Apr 19 '13 at 14:08
add comment

Does your public web site have a database of it's own?

If so you could achieve this with Replication of specific tables from your internal work database to your public database.

You can use circular replication if you need to get data back to your work database, but it sounds like this is just for presentation purposes.

This will be a more secure way to solve the problem because you only have to deal with one permanent secure connection between the servers.

share|improve this answer
    
That is one way. I had thought that communicating between servers would be better, and avoids problems with synchronization. –  wobbily_col Apr 24 '13 at 7:54
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.