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:
Writing the main logic of the app in client-side JavaScript and using server-side scripting to do I/O, or
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?
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:
jQuery is a wonderful tool for keeping DOM access and manipulation readable and manageable. It streamlines JavaScript for working with the HTML page elements.
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.
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.
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.
After some consideration, I see the following options for your situation:
Disable browser security and directly communicate with GPIO. No standard libaries?
Use a JavaScript server environment with GPIO access and AJAX. Complexity introduced by AJAX
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
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
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).
Related
I am working on a React-based web app that uses Tensorflow.js to run an AI model in realtime on the client in the browser. I've trained this AI model from scratch and I'd like to protect it from being intercepted and used in other projects. Are there any protections available to do this (obfuscation, DRM, etc.)?
From a business perspective, I'd only like the model to work on my web app, nowhere else.
The discussions (1 2 3) I've been able to find on this are more geared toward native apps, not web apps.
Here is an example open source web app that uses Tensorflow.js. These weights are an example of what I would like to protect in my app.
Client-side code obfuscation will never fully prevent it. Use a server instead.
Obfuscation
If your client-side application contains the model, then the user will be able to somehow extract it. You can make it harder for the user, but it will always be possible. Some techniques to make it harder are:
Obfuscating your code: That way the user will not be able to read your code and comments easily. Depending on your build tools, this might already be done for you when you produce a "production ready" build.
Obfuscating the library and its public API: Even if your code is obfuscated, the user might still be able to guess what is going on by seeing the public API calls of the library. Example: It would be rather easy to set a break point at the model.predict function and debug your code from there on. By also obfuscating libraries and their API, this will become harder.
Put "special checks" in your code: You could also check if the page the code is running on is your page (e.g. if the domain matches), etc. You also want to obfuscate this code as well.
Even if your code is perfectly obfuscated and well protected, your client-side code still contains your model somewhere. With these methods it will always be possible to somehow extract your model.
Server-side approach
To make it impossible to get your model, you need a different approach. Only put your "dumb logic" on the client. Exclude the part of code that you want to protect. Instead you offer a API on your server that executes the "protected part" of your code.
This way, instead of running model.predict on the client-side, you would make an AJAX request to your backend (with the parameters) and then return the results. That way the user only sees the input and the output and cannot extract the model itself.
Keep in mind that this means a lot more work, as you not only have to write the code for your client-side application but also for your server-side application, including the API. Depending on how your application looks like (e.g.: does it have a login?), this might be a lot more code.
Another way you can protect your model is to split the model into more than one blocks. Put some blocks at server side and some at client side. This method may also introduce a lot of engineering work, but once you do that you can trade off the computation loading and network latency between the server and client. Users can only get some model blocks which is useless without cooperating with server side blocks.
Can I write my web-site only in JavaScript being sure that my code is concealed from anyone? In this respect, is Node.js, like Apache, can be given access to through an Internet-provider?
The answer to both of your questions is yes.
Node.js can completely replace Apache (assuming you are willing to re-write all of your PHP as JavaScript). If you have your Apache running in reverse-proxy mode between your server and client, you can even handle some requests in Node.JS while handing others in PHP. This will allow you to maintain original functionality while changing the code out, and also allow PHP to handle more mundane tasks.
While you cannot prevent raw JavaScript from being read through any means of obfuscation, you can prevent people from reading your code by note making use of standard JavaScript at all. You can use a NativeExtension for Node to add an extension handler for encrypted JavaScript files:
require.extensions[".jse"] = function (m) {
m.exports = MyNativeExtension.decrypt(fs.readFileSync(m.filename));
};
require("YourCode.jse");
This will convert your JavaScript code to a .jse, which you would then package for production. Considering the encryption is done inside the native extension, the encryption key wouldn't be revealed.
Hope this helps! :)
Yes, you definitely can. It may, however, take a while to transition existing code, and if this is for a corporate institution, you'll have to ask your coworkers and your boss/supervisor. Good luck, and remember, always document your code in JavaScript (no types) all languages.
NodeJS is much faster: http://www.hostingadvice.com/blog/comparing-node-js-vs-php-performance/
Many more libraries: http://npmjs.org
Only need one language for everything
Comparing PHP with another technology like Node.js which is meant for an entirely different type of task, comparer must mention the difference of use-case/context in which one is suitable over others.
Let's talk about in terms of a different area of execution because we can not Disgrace any of them and both have its own priority.
If you talk about in terms of Application Domain.
PHP :
CMS (Content Management Systems) like WordPress, Drupal also use PHP which makes it possible to be used in creating blogs, websites, e-commerce sites, etc.
Used in developing CPU-intensive applications like meteorology applications and scientific applications.
should be used in applications in which the client does not have to interact with the server again and again
PHP 7 is based on the PHPNG engine that speeds up PHP applications more than the previous PHP interpreter (Zend Engine 2.0). Thanks to PHPNG, your apps see up to the 2x faster performance and 50% better memory consumption than PHP 5.6.
NodeJs:
Nodejs is ideal for developing highly scalable server-side solutions because of its non-blocking I/O, and event-driven model.
Used massively in Real-time applications like chat applications, blogs, video streaming applications.
Used in developing single-page applications like resume portfolios, individual websites.
Node.js should be used for the applications which require a lot of interaction between client and server.
For some tasks, Node.js may be faster than the “standard” web server with PHP because it runs as a single thread with non-blocking IO for each connection, hence there is no memory overrun. Due to this, Node.js is useful when there is a need to process data in real-time (chats, games, video, big data streams without logic)
PHP is Still alive and he has learned its lessons from Node.JS
ReactPHP enables developers to write PHP-based socket server to process requests constantly as well as Node.js does it (yes, Node.js is faster, but the fact is that PHP can also do it). The same thing with Workers (the classes responsible for running asynchronous jobs and synchronizing their results) or Amp (libraries that are used for writing non-blocking asynchronous code). Hence, it is easy to create long-running processes using PHP. Additionally, there are a lot of tools for supporting and managing these processes (such as supervisord).
So, the same tasks may be performed either with PHP or with Node.js. The question “what tool to use” is a question of personal preferences. you can use Node.js for tasks involving big data flows and PHP for tasks involving complex logic, high-load tasks, for dealing with external utilities, applications, and OS.
From the scalability perspective, there are no big differences between PHP and Node.js, it is more important to consider the project’s architecture.
Dayle Rees (a Laravel Framework contributor and developer): For a long time PHP was the butt of many language jokes, but I honestly feel that it’s becoming not only a popular language but a powerful one. PHP7 is great. The speed boost is one thing, but having optional support for full type hinting is a game changer. We’ve also got modern tools like Laravel and Composer, breathing new life into the language and its supporting community. With this in mind, I think it’s unlikely that Laravel will move from PHP. I think it’s more likely to gain further integration with front-end tools to provide a complete application building platform. That’s where I see it heading in terms of future expansion. I’m sure the Node will continue to excel when dealing with microservices and threaded applications.
The most important and most awaited News from PHP is, PHP is scheduled to receive a Just In Time (JIT) compiler in its next major version PHP-8 (most probably in sep-2021).This is going to boom the php and it breaks all his limitation due to JIT.
Wrap up
To wrap up Both have some pros, both have some cons but the amazing thing is both are created by intellects to make the web development better. While selecting the technology the question shouldn’t be which one is better but which one can serve your project needs in a better way. Understanding your project and business logic can give you a clear idea about selecting the right technology for your project.Moreover, one more important thing to consider is the skills and proficiency of the developers using the technology, how they use them and apply to the project.
I am developing a standard rails application, and so far I haven't used any AJAX, just good ol' HTML. My plan is to iteratively add "remote" links and all that kind of stuff and support for JS responses, because I know that generating JS server side is very very evil, but I find it to be very handy as well, easy, fast and it makes the application snappy enough and i18n comes out-of-the-box.
Using a pure JSON approach would be lighter, but needs lots of client-side coding.
Now imagine that in this application users have a mailbox, and since the idea is that they will be able to do most or even all of the actions without reloading the page, the mailbox counter will never change unless they refresh the page manually.
So, here comes the question: Which is the best way to handle this?
I thought about using Ember (for data binding), and sharing views with rails, via some sort of handlebars implementation for ruby. That would be quite awesome, but not very transparent for the developer (me). Although I guess that I only need to write handlebars views that will be used by ember, the rest can still be written in their original format, no?
Another option might be to use some sort of event system (EventSource maybe?), and just go with handy the JS views approach, and listen to those events. I guess those should be JSON objects, and the client must be coded to be able to handle them. This seems a bit cumbersome, and I need a solution for heroku (faye?), which is where my app is hosted. Any hints?
I think that the ember approach is the more robust one, but seems to be quite complex as well, and I don't want to repeat myself server and client side.
EDIT:
I have seen this, which is more or less the option #2.
One of the advantages of using a JavaScript framework is that the whole application can be concatenated and compressed into one JavaScript file. Provided that modern browsers aggressively cache JavaScript, the browser would no longer need to request those assets after initial page load.
Another advantage of using a JavaScript framework is that it requires you to be a consumer of your own API. Fleshing out the application's API for your own consumption might lend to less work in the future if there is a possibility of mobile applications or 3rd parties having access to it.
If you do not need your application to respond to every request with an equivalent HTML response, I think a compelling case could be made for using a JavaScript framework.
Many of those benefits might be lost if your application needs to respond to every request with an equivalent HTML template. The Ember core has been relatively vocal and in opposition to supporting this style of progressive enhancement. Considering the tools for using a JavaScript framework in this way are relatively unstable and immature, I might be prone to using option 2 to accomplish this.
We are currently developing a few web applications and are letting our designers convert signed off paper prototypes into static web pages. In addition to having hyperlinks between pages the designers have started adding jquery calls to update elements on the pages by fetching data from static json files. Once the designers are finished and handoff the completed web pages, CSS, and JavaScript files; the server-side developers then edit the pages and replace the references to the local static json documents with references to live json urls that return the same json data structures.
My question:
What are efficient ways to decouple GUI design from serverside dev and reduce the integration time and effort? Some examples:
Do you have the developers manually change every json reference in the designers' prototype web pages?
Do you add a global variable somewhere to enable the designers' pages to be easily switched back and forth between using static and dynamic data?
Do you make the web pages self-aware of when they are running from a web server or just being served from a folder somewhere?
It depends on how much state information does your application need to manage. The examples you have given mention only read operations from the server. Are there any writes? Both read and write operations can potentially fail. Do your designers take care of those cases, or the server-side team jumps in and patches up the GUI later on?
I think it's best to provide a mock server-side implementation of your services for the designers. The server mock could simulate real life behavior as in throw errors and exceptions beyond just the happy path. It really is much less of a hassle to install a simple web server nowadays and a single script that acts as a mock service, rather than trying to create processes for later integration.
One of the things I have seen work fairly successfully for the whole "url/path" problem (dev vs test vs production, etc) is to create a subdomain for your project of "proto" (so proto.mycoolapp.company.int) and have that be the basis for all urls used anywhere in the app.
On top of that using whatever framework you are using set up global page handlers to identify section/page/function+[url data] for all of your data files (i.e. json calls etc).
This allows you to segregate your app into sections and build up functionality as you go and allows both the UI team and the dev team to work on hints for the other team.
For example say I have an app with three sections (login, account management, preview) I would have a login url service (data, files, whatever) at proto.mycoolapp.company.int/frontend/login/securelogin?user=GrayWizardX. The UI team can add these as they identify a need for data and your app dev team can see what functions are being requested (through server logs, etc) and make sure everything is matching up.
The good part is that when you move to production, the only change is to find "proto" and replace it. If that is in your global var, then its a quick and simple change.
It's not real clear what exactly your environment is (plain html only? or something like php?), so this is a bit of a shot in the dark...
If it's plain old HTML + javascript, you could probably use a javascript include on each page to get the right set of addresses. When the include file with all this environment specific information (i.e. use local or use server) remains in the same relative place, you don't need to worry about modifying the actual page. Just tell the GUI guys to always use this same set of variables for the address information and define the address information in that include file. The variable names don't change whether your getting locally or from the server, just the values stored in the variables.
I'm low on Vitamin Coffee, so hopefully that makes sense.
Is the use of server side javascript prevalent? Why would one use it as opposed the any other server side scripting? Is there a specific use case(s) that makes it better than other server side languages?
Also, confused on how to get started experimenting with it, I'm on freeBSD, what would I need installed in order to run server side javascript?
It goes like this:
Servers are expensive, but users will give you processing time in their browsers for free. Therefore, server-side code is relatively expensive compared to client-side code on any site big enough to need to run more than one server. However, there are some things you can't leave to the client, like data validation and retrieval. You'd like to do them on the client, because it means faster response times for the users and less server infrastructure for yourself, but security and accessibility concerns mean server-side code is required.
What typically happens is you do both. You write server-side logic because you have to, but you also write the same logic in javascript in hopes of providing faster responses to the user and saving your servers a little extra work in some situations. This is especially effective for validation code; a failed validation check in a browser can save an entire http request/response pair on the server.
Since we're all (mostly) programmers here we should immediately spot the new problem. There's not only the extra work involved in developing two sets of the same logic, but also the work involved in maintaining it, the inevitable bugs resulting from platforms don't match up well, and the bugs introduced as the implementations drift apart over time.
Enter server-side javascript. The idea is you can write code once, so the same code runs on both server and client. This would appear to solve most of the issue: you get the full set of both server and client logic done all at once, there's no drifting, and no double maintenance. It's also nice when your developers only need to know one language for both server and client work.
Unfortunately, in the real world it doesn't work out so well. The problem is four-fold:
The server view of a page is still very different from the client view of a page. The server needs to be able to do things like talk directly to a database that just shouldn't be done from the browser. The browser needs to do things like manipulate a DOM that doesn't match up with the server.
You don't control the javascript engine of the client, meaning there will still be important language differences between your server code and your client code.
The database is normally a bigger bottleneck than the web server, so savings and performance benefit ends up less than expected.
While just about everyone knows a little javascript, not many developers really know and understand javascript well.
These aren't completely unassailable technical problems: you constrain the server-supported language to a sub-set of javascript that's well supported across most browsers, provide an IDE that knows this subset and the server-side extensions, make some rules about page structure to minimize DOM issues, and provide some boiler-plate javascript for inclusion on the client to make the platform a little nicer to use. The result is something like Aptana Studio/Jaxer, or more recently Node.js, which can be pretty nice.
But not perfect. In my opinion, there are just too many pitfalls and little compatibility issues to make this really shine. Ultimately, additional servers are still cheap compared to developer time, and most programmers are able to be much more productive using something other than javascript.
What I'd really like to see is partial server-side javascript. When a page is requested or a form submitted the server platform does request validation in javascript, perhaps as a plugin to the web server that's completely independent from the rest of it, but the response is built using the platform of your choice.
I think a really cool use of server-side Javascript that isn't used nearly often enough is for data validation. With it, you can write one javascript file to validate a form, check it on the client side, then check it again on the server side because we shouldn't trust anything on the client side. It lets you keep your validation rules DRY. Quite handy.
Also see:
Will server-side Javascript take off? Which implementation is most stable?
When and how do you use server side JavaScript?
Javascript is just a language. Because it is just a language, you can use it anywhere you want... in your browser, on the server, embedded in other applications, stand-alone applications, etc.
That being said, I don't know that there is a lot of new development happening with "Server-Side Javascript"
Javascript is a perfectly good language with a self / scheme prototype style base and a C style syntax. There are some problems, see Javascript the Good Parts, but in general it's a first rate language. The problem is that most javascript programmers are terrible programmers because it's very accessible to get started.
One team at google built out Rhino on Rails, which is an MVC framework like Ruby on Rails which is written in javascript and runs on Rhino a javascript interpreter for the Java VM. In this case they had a requirement to use the Java VM, but wanted to get a language which was fast (javascript is fast), supported duck typing, and was flexible.
Another example is something like CouchDB, a document oriented database which uses json as it's transport format and javascript as it's query & index language. They wanted the database to be as web native as possible.
Javascript is good at string and dom (xml) manipulation, being sandboxed, networking, extending itself, etc... Those kind of features are the thing you often do when developing web applications.
All that said, i don't actually develop server side javascript. It's not a bad idea, but definitely less common.
We use javascript on the client because it is there, not because from a list of languages it was our choice. I wouldn't choose it for any chore on the server.
You can run any language you like on the server, in fact, as many as you like.
javascript is reliable and easy to use, but it is just too labor intensive for common tasks on the server.
I have used both Javascript (NodeJS) and compiled languages (such as Java or C#.NET). There are huge discussions on the internet about which is preferable. This question is very old (2009). Since then the Javascript world has changed considerably, whereas honestly the Java world has not changed much (relatively).
There have been huge advancements in the Javascript world with Typescript, amazing frameworks (such as Next.JS), reactive programming, functional programming, GraphQL, SSR etc.
When I look at compiled code, especially Java code it all still seems to be the same old tools - Spring (maybe SpringBoot) and Jackson. .NET has advanced server side, but not to the extent of the JS world.
Sure my list there can be used with several languages, but I believe Javascript has improved the software engineering world considerably.
Server side development with Javascript, Typescript and NodeJs is engaging, fun and productive. Use it and enjoy it. Like millions are today.