I'm working on a system where a remote machine (hooked up to a projector and some other hardware) is controlled via a Meteor application. Currently, we are using a home-grown DDP client written in C++ to accomplish this, but this approach is not as flexible as I would like:
There is duplication between C++ and JavaScript.
Upgrades are hard because we can't deploy both the server and the client at the same time, so we always have to think about backwards compatibility and ordering.
So I'm toying with the idea of rewriting the Meteor part of the C++ app in JavaScript. What I would like, ideally, is to have a special client of our app (call it headless, akin to to server and client) which:
is built from the same source as the rest of the Meteor app, so we can reuse the same business logic as on the server and web client,
runs in Node.js on the client machine so it can access the OS, and
doesn't contain any of the browser code, but adds some other code specific to controlling the machine and communicating with the C++ app.
Even better would be if this client would not contain any of the actual code, but just a piece of bootstrap code. The bootstrapper would download the actual application code from the server and re-download it when the server is updated, in the same way as happens for the HTML client. That would make updates much easier, because we can assume that server and client are always running the same version.
Does such a thing exist? If not, how close can I get without unreasonable effort? Searches for "meteor headless client" and "meteor node client" are not helping me, and the only somewhat related question I could find isn't well answered.
You should be able to get this to work by using the meteor-desktop package to build your remote headless client.
https://www.npmjs.com/package/meteor-desktop#architecture
In Electron app, there are two processes running along in your app.
The so-called main process and renderer process. Main process is just
a JS code executed in node, and the renderer is a Chromium process. In
this integration your Meteor app is being run in the renderer process
and your desktop specific code runs in the main process. They are
communicating through IPC events. Basically, the desktop side
publishes its API as an IPC event listeners. In your Meteor code,
calling it is as simple as Desktop.send('module', 'event');.
This will give you:
os access on this (desktop) client
hot code push (with caveats around the node modules)
provides Meteor.isDesktop to control which code runs on the browser vs the desktop client
If you wish to use the Meteor client as a headless client, and since client runs in the browser, I'd suggest your look at using a headless browser like PhantomJS, which can run your Meteor code without the UI, and has the ability to access the local file system.
Another option, which is not really what you describe but would make everything javascript, is to use the node ddp client, and write your code in modules you can easily import on the node side.
Is there a regular meteor client on the remote machine with custom hardware? Or is that the C++ program acting as a client? And then a server, in addition to your other client browser?
Sounds like you should actually do a few things differently:
Set up a dynamic DNS system with a custom domain and port forwarding so you can use the special hardware remote system as a server.
Run the Meteor server on that remote machine with hardware.
Instead of a full C++ app speaking DDP, just make a Node.js C++ addon that talks to the hardware and use that in the Meteor server code.
Related
I've been developing a Next.js website locally and now want to set it up on my Apache server (with cPanel). However, I'm very new to Next.js and Node apps and not too sure how to go about it.
Has anyone done this successfully? Can you list the required steps and what files should be on the server?
Also, can this be done on a subdomain?
Thank you!
To start with some clear terms just so we're on the same page, there are two or three very different things people mean when they say "server":
A Server Machine is a computer that is connected to the internet that you intend to use to serve something to people on the internet.
A Server Program is some software you run on your Server Machine. The job of the Server Program is to actually calculate the responses to various requests.
A Server as a Service is a webapp provided by a company that stores your code and then puts it onto Server Machines with the right Server Program as needed.
While we're here, let's also define:
A Programming Language is the language your website is written in. Some sites have no language (and are just raw HTML/CSS files that are meant to be returned directly to the user). Many sites, though, have some code that should be run on the server and then the result of that code should be returned to the user.
In your case, you have a Machine whose condition we don't know other than that it is running the Program Apache (or probably "Apache HTTP Server"). Apache HTTP server is very old and proven and pretty good at serving raw files back to users. It can also run some Programming Languages like PHP and return the result.
However, Next.JS is built on top of the Programming Language Javascript, which Apache does not have the ability to run. Next.JS instead wants its Server Program to be Node.
So the problem here is basically that you have a hammer, but only screws. You can't use the tool you have, Apache, to solve the problem you need solved, running Node code and returning the result. To get around this you have two options:
First, you can find a way to access the Server Machine that is currently running Apache and tell it, instead, to run Node pointed at your Next.JS code whenever it starts up. This might not be possible, depending on who owns this machine and how they've set it up.
Second, and probably easier, is to abandon this Machine and instead use a Server as a Service. Heroku, AWS, and Netlify all support Next.JS and have a free tier. The easiest solution, though, is probably to just deploy it on Vercel, which is a Server as a Service run by the same team that makes Next.JS and which has a very generous free tier for you to get started with.
The good news, though, is that yes next.js does totally support being hosted from a subdomain.
Next.JS allows you to build fully functional Node Applications, as well as simple statically-generated sites like Jeckyl or Docpad. If your use case is a simple statically generated site look here: https://nextjs.org/docs/advanced-features/static-html-export
In particular the next build && next export command will create all the HTML and assets necessary to host a site directly via an HTTP server like Apache or Ngnix. Contents will be outputed to an out directory that could serve as the server root.
Pay very close attention to what features are not supported via this approach.
I want to create GUI for terminal app. It'd be nice if I could code it with js/css/html. Electron seems like a good candidate. Is it possible, if yes how, to launch an electron app, have it talk to nodejs process running in background.
At this point I'm exploring different options.
Electron comes with NodeJs support. You don't need to run a background process to do that. But if that is required you can do this via a socket connection (something like websockets). Here is a good candidate for that.
Why you are creating NodeJS process separately. see when you launch an Electron application you will have two process i.e. main Process and render process. if you want you can create more then 1 renderer process.
in each process i.e. whether it is renderer or main process all NodeJS api is working .
and you can communicate with other process using ipc Communication.
Hope it will work
I'm attempting to scale a Node.js application but am a little confused on one piece of it. I moved all my static files to the gateway server running NGINX, and it routes them accordingly. Now looking at the waterfall diagram in Chrome's dev tools, I notice a full second of wait time to access the socket.io javascript file. I'm assuming that is because this is still being accessed from the application server, not the web server. My question is, can I move this file to the web server to have it load faster? It's an npm module so it seems a little fishy to me, like it needs some sort of interaction with the application server to initialize the connection or something. Or am I thinking about this all wrong? Thanks!
I have a requirement. Is there a way to run nodejs apps inside golang? I need to wrap the nodejs app inside a golang application and in the end to result a golang binary that starts the nodejs server and then to be able to call nodejs rest endpoints. I need to encapsulate in the golang binary the entire nodejs application with nodem_odules, if necessarily the nodejs runtime.
Well, you could make a Go program that includes e.g. a zipped Node application that it extracts and starts but it will be very hard to do well - you will have huge binaries, delays in extracting files, potential portability problems etc. Usually when you want to call REST endpoints then you host your Node app on some server and you let the client app (the Go app in your example) to connect to that Node app to work correctly. Advantages are that it is much faster, the app is much smaller, you don't have portability issues with Node binaries and addons and you can quickly update your backend any time you want.
It will be a very bad idea to embed a nodejs app into your golang, for various reasons such as: size, security updates pushing, etc.
However, if you so strong feel that they should be together, you could easily create a docker container with these two (a golang server + a node app) and launch them via docker. You can set the entrypoint to a supervisord daemon so that your node server as well as the golang server can be brought up when your container is run.
If you are planning to deploy via kubernetes you can create two individual docker containers (one for the golang server, one for the node server) but deploy them always together as a pod too.
There are multiple projects to embed binary files and/or file system data into your Go application.
Look at 'Alternatives' section of project 'vfsgen':
https://github.com/shurcooL/vfsgen#alternatives
Well, we all know about headless servers. Actually, probably the vast majority of servers out there are headless.
As usual (it seems), my situation asked for quite something else. Basically, the proposed architecture looks more or less like:
The app server (node.js) is situated on a physical machine physically connected to two screens.
Between this machine and the 'net there are all sorts of regular networking layers. Please keep in mind that one of the main reasons for this setup is physical portability: ie, the client gets the necessary hardware as the product. The server itself relies on CDN for static files etc.
Each monitor/screen needs to show something different, produced by the same node server.
For now this server will probably run on Windows, but given a concept (which is what my question is after), I can change the code to run on the target platform. Well, depending on my code, this could even be done automatically.
So, my actual question. Node is quite flexible in that it can be run by anything - even custom made software (C++, Delphi, even GM). Just shell_exec('node server.js') and we're off.
But the screens themselves need to be quite dynamic. So node needs to influence both screens in some way. A few options I'm considering:
A custom app which creates two resizable, featureless windows with an embedded chromium browser to be controlled by the node server somehow (how node react with these browsers?)
A custom app which, according to node CLI output, updates the two screens' UI. Since I need something flashy as the UI, this app would be created in something like GameMaker, or a similar engine.
PS: Just in case you're asking; the physical connection opposed to a network one (eg; web-based GUI frontend) is by design.
I'd just wire up the result/monitoring screens as regular HTML pages. In your Node app, create a second HTTP server (on a non-standard port, firewalled from the public) that serves up the monitoring page.
Use socket.io to to send the realtime data to the monitoring page, which can make everything look pretty. Fire it up in a full-screen instance of Chrome.
This approach completely frees you from any kind of platform dependency, and decouples the monitoring app from the server app. It leaves you the latitude to run the monitoring app on a separate box if necessary.