Browser-based app needing IO control

Question

This is a question about the best way to structure an app that has both server-side and client-side needs. Forgive the length -- I am trying to be as clear as possible with my vague question.

For a standalone non-web-connected art project, I'm creating a simple browser-based app. It could best be compared to a showy semi-complicated calculator.

I want the app to take advantage of the browser presentation abilities and run in a single non-reloading page. While I have lots of experience writing server-side apps in perl, PHP, and Python, I am newer to client-side programming, and neophyte at JavaScript.

The app will be doing a fair bit of math, a fair bit of I/O control on the Raspberry Pi, and lots of display control.

My original thought (and comfort zone) was to write it in Python with some JS hooks, but I might need to rethink that. I'd prefer to separate the logic layer from the presentation layer, but given the whole thing happens on a single non reloading html page, it seems like JavaScript is my most reasonable choice.

I'll be running this on a Raspberry Pi and I need to access the GPIO ports for both input and output. I understand that JavaScript will not be able to do I/O directly, and so I need to turn to something that will be doing AJAX-ish type calls to receive and sent IO, something like nodejs or socket.io.

My principle question is this -- Is there a clear best practice in choosing between these two approaches:

1. Writing the main logic of the app in client-side JavaScript and using server-side scripting to do I/O, or

2. Writing the logic of the app in a server-side language such as Python with calls to client-side Javascript to manage the presentation layer?

Both approaches require an intermediary between the client-side and server-side scripting. What would be the simplest platform or library to do this that will serve without being either total overkill or totally overwhelming for a learner?

Answer 1

After some consideration, I see the following options for your situation:

1. Disable browser security and directly communicate with GPIO. No standard libaries?
2. Use a JavaScript server environment with GPIO access and AJAX. Complexity introduced by AJAX
3. Use the familiar Python and use an embedded web browser If libraries are around, easy

Don't add too much complexity if you're not familiar with the tooling and language

Answer 2

I have never developed for the Raspberry Pi or had to access GPIO ports. But I have developed stand-alone web apps that acted like showy semi-complicated calculators.

One rather direct approach for your consideration:

Create the app as a single page HTML5 stand-alone web app that uses AJAX to access the GPIO ports via Node.JS or Python. Some thoughts on this approach based on my experience:

1. jQuery is a wonderful tool for keeping DOM access and manipulation readable and manageable. It streamlines JavaScript for working with the HTML page elements.

2. Keep your state in the browser local storage - using JavaScript objects and JSON makes this process amazingly simple and powerful. (One line of code can write your whole global state object to the local storage as a JSON string.) Always transfer any persistent application state changes from local variables to local storage - and have a page init routine that pulls the local storage into local variables upon any browser refresh or system reboot. Test by constantly refreshing your app as part of your testing as you develop to make sure state is managed the way you desire. This trick will keep things stable as you progress.

3. Using AJAX via jQuery for any I/O is very readable and reliable. It's asynchronous approach also keeps the app responsive as you perform any I/O. Error trapping and time-out handling is also easily accomplished.

4. For a back end, if the platform supports it, do consider Node.JS. It looks like there is at least one module for your specific I/O needs: https://github.com/EnotionZ/GpiO

I have found node to be very well supported and very easy to get started with. Also, it will keep you using JavaScript on both the front and back ends. Where this becomes most powerful is when you rely on JavaScript object literals and JSON - the two become almost interchangeable and allow you to pass complicated data structures to/from the back end via a few (or even one!) single object variable.

You can also keep your options open now on where you want to execute your math functions - since you can execute the exact same JavaScript functions in the browser or in the node back end.

If you do go the route of JavaScript and an HTML5 approach - do invest time in using the browser "developer tools" that offer very powerful debugging tools and dashboards to see exactly what is going on. You can even browse all the local storage key/value pairs with ease. It's quite a nice development platform.

Answer 3

Oh what a nice question! I'm thinking of it right now. My approach is a little difference: With old MVC fashion, you consider the V(iew) layer is the rendered HTML page with Javascript CSS and many other things, and M and C will run on the server. And one day, I met Mr.AngularJS, I realized: Wow, some basic things may change: AngularJS considers the View ( or the thing I believed is view ) is not actually view. AngularJS gave me Controllers, Data resources and even View templates in that "View", in another word: Client side itself can be a real Application. So now my approach is: Server do the "server job" like: read and write data , sends data to the client, receive data from client ect.... And client do the "client job": interact with user, do the logic processes of data BEFORE IT WAS SENT such as validation, or format the information collected from user ect...

Maybe you can re-think of your approach: Ask your self what logic should run at client, what should at server. Client with javascript do its I/O, Server with server-side script do its I/O. The server will provide the needed resource for client and javascript use that resources as M(odel) of it's MVC. Hope you understand, my bad English :D

Answer 4

Well... it sounds like you've mostly settled on:

• Python Server. (Python must manage the GPIO.)
• HTML/JavaScript client, to create a beautiful UI. (HTML must present the UI.)

That seems great! You're just wondering how much work to do on each side of the client/server divide... should be functionally equivalent.

In short: Do most of the work in whichever language you are more productive in.

Other notes come to mind:

• Writing the entire server as standalone python is pretty straightforwad.
• You don't have to , but it's nice and self-contained if you serve the page content itself from it.
• If you keep most of the state on the server/python side, you can make the whole app a little more robust against page reloads (even though I know you mentioned, that should never happen).