I've been reading about Node.js hoping to expand my web development skills.
Now I don't quite understand how I will use it to develop my own mini-project, what I'm trying to achieve is to have, say, a html webpage (www.example.com/routine/video.php) that will display a series of videos.
I would like to then have another html webpage say(www.example.com/routine/controller.php) that will have a button that will pause/unpause the video thats currently playing on video.php. (why do I need another html page?, because my goal is to have like a remote controller inside a mobile device, it might even add a login to this working experience and after the login that will lead me to the controller.php page and while on my monitor the video.php will be playing, I can pause and unpause with my phone using controller.php).
Another thing that I don't quite understand is, I would like video.php be like dynamic with for example 3 videos(v1,v2,v3), and open it on monitor1, then have another monitor open that same webpage and run other 3 videos (v4,v5,v6) all working like parallel. (maybe using some ids for the post? video.php?type=sequence1)
Some people have told me to use node.js, but the video.php cannot be dynamic because if I understood correctly the js creates a server with a ip and a port, and I cannot create multiple servers on the same port.
Any ideas?
Just some comments:
It doesn't matter if you using PHP, Node.js, or even Ruby if you want to make certain type of apps, they eventually can be built, just using different implementations.
Node.js essentially allows you to write server side code in JavaScript, so that you can just use 1 language for front-end and back-end.
You probably will need to look at web socket to realize your 'remote' functionality. (think about a live chat app.) Some idea would be you can streaming your video via a readable stream, and your app provide an API to control how it would response by watching the change of states.
You may want to lookup some Node frameworks, such as Express.js to save your time.
I don't understand why you say 'video.php' can not be dynamic (BTW, in Node.js you don't need .php, the idea between PHP and Node.js is totally different). And of course, 1 port can only serve 1 server, because you don't want multiple server against one another.
IMO, I'll assume you just adapted Node.js from PHP, so I will suggest you to look how Node.js is different than PHP, and try to build an normal website (such as a forum, blog or something similar). Your 'mini project' is actually not 'mini' at all, it requires you to leverage many concepts (e.g. readable/writable stream, etc.)...
Related
A few days ago I decided to make my own "interface" to make it easier to organize (and work with) some of my personal files. You know when a lot of related data, pictures and links are right in front of you and you can change them in a couple of clicks, this is very convenient.
I started by studying HTML, CSS and JS, because I thought that the changes made to the local page would be saved somewhere on my PC so I can just run Index.html and do whatever I want. But they didn't. Refreshing the page erased all changes.
Using browser localstorage does not suit me, because if I change the browser, the data will be lost. I wanted it to just open with Index.html and work fine even if I change my browser or move the site folder to another computer.
Then I decided to learn more about server-side languages (such as PHP or Node.js) because they are directly related to databases, so I was hoping to save changes through them. But these languages required me to really open the server, with ip and port tracking. And I just wanted to open a local page through one file, without any ports or connections via the console. So this method scared me off quickly.
So is there an easy way to make a local page like this? Maybe I have not studied well one of the above methods and it has this opportunity?
Or the best I can hope for is a simple application that will use that local page as an interface to interact with data? I accidentally heard about this possibility a long time ago. Then I will ask you to give at least a hint as to which language to choose for this.
I don't understand well everything that lies outside of vanilla HTML, CSS and JS, so a complete study of a complex language like Java or Python will be too difficult for me, and the goal is not worth such a lot of effort.
I hope I understand correcly what you are trying to do.
If your goal is to make an application to manage your files, I think the simplest solution will be, as you said, to look into NodeJS and the File system api which will let you interact with your files through javascript code.
Your program will have to be in two part that will have to interact:
the "front" html page
the "back" nodejs script
The downside is that you'll have to go deeper into your study of the language to learn how to create the interactions you want between your html file and your NodeJS application.
However, there is no need to open your server to the web to make it work. The NodeJS application can be set to listen to requests from only the computer that runs it (localhost).
I obviously can't get too much into details without knowing precisely what you want to do but you'll probably have to learn to make a local server with node (search "nodejs http" or "nodejs express"), then make requests to it via the html page's scripts (search "ajax request").
What you need to look into are (web based) content management systems. like strapi or "grand old dame" WordPress.
I'm relatively new to node.js and I'm trying to make a game that only uses one accessible URL but has multiple pages. In my game I'm going to be using the socket.io and express modules. I really want to have one URL that the client will access which will give them the title screen and then the menu page. There will be buttons on this page which will send the client to different servers that run games. The only way that I can think of how to do this is to have multiple servers running on different pages and have the buttons contain links. I know that it is possible to have multiple servers running on the same URL. One example of this is the diep.io online game. Is it possible to accomplish this with node.js? If so, how would I go about making this happen? Should I be using ports to create these pages?
I believe what you're talking about is referred to as "horizontal scaling" where instead of having one beefy server you have many lower-end servers that run the same code.
Or since you're using Socket.io there's a concept of "rooms" that you can use.
My memory on both of these topics is a bit cloudy so I can't help much more, but you should be able to Google them now.
This channel has tutorials on JS / Node game dev:
https://www.youtube.com/user/RainingChain/featured
I'm working right now on a project that could allow me to generate movies based on the user input. User will upload some samples (photos, movies) to the web app and web server should generate movie based on that input and some predefined movie compositions.
I know that there are plenty of libraries for ffmpeg that could let me connect movies, photos programmatically (for example https://github.com/schaermu/node-fluent-ffmpeg for node.js) , but I was wondering if it's possible to use Aftereffects for that purpose since I have some knowledge in that software. I imagine that there should be set of scripts in Aftereffects that could import user uploaded data, fire the movie renderer and save output to the given location.
Do you think this is achievable using Aftereffects? Or maybe someone had similar problem and solved that differently ?
Cheers!
I have done the exactly same thing.
I DO NOT suggest you use script to do it. I have made the same mistake. Script is fine for a small job, but when you try to use it on a web server and run constantly for days and days it's very unstable. You will be facing a lot of crashing.
I would suggest you use sdk to do the job. It's much more difficult to use sdk than using script, but is more stable and much faster! When you try to create a web service app, you want it to be stable and fast, don't you?
Yes, this is definitely possible. There are existing scripts for rendering and uploading via FTP, and the possibilities are pretty much endless. The part that jumps out at me as needing clarification is "scripts in Aftereffects that could import user uploaded data". This suggests a need for a back-end that "looks for" or "waits for" elements to "appear" in a directory to kick off the ExtendScript script in AE. This is where it gets slightly dicey in that you have to devise a way to do this with a "daemon" in your preferred operating system using any number of languages -- python, Java, AppleScript, shell, batch, etc. The rest of it ("import user uploaded data, fire the movie renderer and save output to the given location") could be done in ExtendScript.
Choosing the "right" web framework is quite challenging task, at least in Java we have a lot of them. But looking at JavaScript frameworks like AngularJS I doubt if we really need something heavy at server. Usually web framework is responsible for routing, templating, building pretty URLs and some other stuff. With AngularJS we can move all these responsibilities to client side. Then the backend becomes nothing more than REST listener and data validator. A thin layer between your application logic and client view. So why do we need web frameworks now if all we want is a REST listener?
At the moment I found two points which must be handled by server side: authentication/authorization and things requiring 'pushing' like Comet. Are these criterias enough to choose the "right" framework?
I'll give you one more capability that I've seen require back-end server support. It's those pages which generate a file. For example, they get a file from a third party and then hand it to the client as though they produced it directly, or they are generating a JPEG/PNG/GIF image on the fly, or perhaps a CSV/XLS dump of data. There may be ways to generate those on the fly from the front end and make them available for download, but sometimes the back-end is just easier for those.
Other than that, your assessment is 100% correct. You literally need less server for apps built with AngularJS than was needed with the previous request/response model of ASP/JSP/PHP/etc.
However, just because you need less doesn't mean you need nothing. Issues like data caching and how user sessions are handled can still come up even for smaller servers as you scale. But it has definitely opened things up for tech like Node.js to be considered that I would not have given much thought to a few years back.
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).