What I've done
I've developed a custom-made Kurento Media Server module but I'm having issues when I try to use it in my node.js application.
This is the system's description:
Based on the one to one tutorial, 2 clients establish connection with each other. My module, which is a OpenCV module, takes each frame and converts it to grayscale. Client A's WebRTCEndpoint is connected to my module and this is connected to the B clients WebRTCEndpoint. The purpose is to apply the grayscale filter to A's video stream, while B's one should maintain intact.
After programming everything, I've installed it in the Kurento Media Server just like the developer team explains it in the official documentation (it seems to be ok because when I execute kurento-media-server -v command I see it alongside other ones). The last step I've done is generating the Javascript library with cmake .. -DGENERATE_JS_CLIENT_PROJECT=TRUE.
The problem is that I don't know how to add it in my application. I have it locally, so I suppose I don't have to add the module dependency in my package.json file, right?
If your server app is a node.js application, you'll need to import the module in your package.json. You can find an example of a node.js tutorial using an external module here and here. You can see their package.json, and they have the modules imported. Otherwise, your app won't have the correct types imported.
EDIT
You'll still need to register the module in your server.js code. From the same project used in the other links from this answer, you can see an example here.
Related
I have a node module that I am building, and I want it to be able to execute on the server (in nextjs server side rendering) and the client (call additional lifecycle methods in the UI). This same module also needs to work when used purely as a js library that can be included in a <script> tag on the page. This module depends on the uuid module, which has logic in it to check if it is running in a browser or server context, and use the proper random number generators/crypto libraries that are available in that context.
If I don't specify a target in my webpack config, the bundle works great in a client browser. It includes the webpack browser logic just fine. But it doesn't work in the server case - webpack removed the server capable logic in the uuid module.
If I target: 'node' in my webpack config - it executes just fine as a node module on the server and the client. It seemingly included all of the logic this time. But now it doesn't work if included just as a script tag on the page. I get ReferenceError: require is not defined from the file that depends on the uuid module.
It seems like the uuid module should handle these different environments just fine, but webpack is messing with that. How can I let that module resolve the proper implementation at runtime?
I unfortunately do not have a minimally reproducible example, or additional code to share at this time. I figured someone might have run into this with webpack (or even webpack and the uuid module) and know the solution.
I was trying to do this by building a single version of the package, but I don't think that is possible.
What is possible is building multiple versions, and then hosting the web bundle via unpkg or jsdelivr via an entry in package.json. Those entries can point to the target: 'web' version of the package, while the npm package can point to the target: 'node' version.
I'm new to Reactjs, Nodejs and MongoDB. I'm currently trying to change Mediums snowflake tool to store users scores in a database. I have installed yarn, mongodb and mongodb-core through npm. It is a single page web application which is what I think is causing me trouble. I add
var MongoClient = require('mongodb');
To SnowflakeApp.js and encounter the following error:
Module not found: Error: Can't resolve 'dns' in
'/home/mlAHO174/snowflake/node_modules/mongodb-core/lib'
I've tried googling this error and have discovered it could be a range of things. I'm not sure if it is because React is front end and I'm trying to alter back end or because mongoDB is installed incorrectly. I'm new to this so would be grateful for help!
DNS is a core module of Node.JS. Telling people they need to install DNS via NPM will end up with them having a completely different module that does something else.
https://nodejs.org/api/dns.html vs https://www.npmjs.com/package/dns
This error most likely means you are trying to do something from the client-side that needs to be done on the server-side. If MongoDB module can't find the DNS component, it's running on the client-side.
MongoDB has to run on the server. In order to access data from React dynamically you'll need to set up an API using something like Express or Apollo.
Update:
A great way to do this is with Azure Functions (TypeScript) or AWS (Lambda) functions
For anyone who encounters this Error while importing the clientPromise (like in the with-mongodb template):
Make sure you're in the /pages/ directory!
It won't work in other directories like /components.
(and you should take a break or get some coffee...)
The problem is that you are trying to connect to the database from the front end. If this were possible that would open up a whole world of security issues. You need to set up your database connections on the backend and then have the front end make requests to the backend to handle the database.
I solved this by installing and using 'bson' instead of 'mongodb' for the client part of the code. 'bson' has a tiny bit of what 'mongodb' has and it might have what you are looking for. 'bson' is built for the browser.
In my case I needed the "ObjectId" in the browser and pulling it in from 'bson' did the trick as I didn't want to reference 'mongodb' because of the error described in the OP.
The other answers are also correct depending on why you're getting this error.
I think - mongo package is meant to be run on servers only, not in the browser.
It does not work in Next.js pages file components too, but does work in getStaticProps, getServerSideProps, getStaticPaths etc - because they run on the server, not the client.
Alternative - use Firebase Realtime database, you can access it in client-side code too. Example - a website (say a React app) that is hosted on GitHub pages or some other static server, but doesn't have a web app server (aka backend).
welcome to stack overflow.
You need to understand and learn few basics of web-applications. There's frontend, backend and a layer between them and a layer between backend and database. Frontend includes react.js, angular.js or anything else that is on browser. Backend is used to take request from frontend, providing API's to frontend and ask for data from other API's or database. Database includes sql, no-sql.
The error you are facing if of a NPM module mongodb-core.js. Either it's not installed properly, or installed using wrong version of module which is not comparable with your node version, or wrong version of NPM, or module using another NPM module which is not installed.
The issue in your case is mongodb-core uses a module dns which is not been installed. Try to install dns with npm i dns. or remove and install mongodb-core again.
For some backstory and reference, here are some quotes from a few Heroku documentation pages.
From the Heroku Node.js Support > Activation:
The Heroku Node.js buildpack is employed when the application has a package.json file in the root directory.
From Heroku Node.js Support > Default web process type:
First, Heroku looks for a Procfile specifying your process types.
If no Procfile is present in the root directory of your app during the build process, your web process will be started by running npm start, [...]
From Process Types and the Procfile > Process types as templates:
A Procfile contains a number of process type declarations, each on a new line. Each process type is a declaration of a command that is executed when a dyno of that process type is started.
For example, if a web process type is declared, then when a dyno of this type is started, the command associated with the web process type, will be executed. This could mean starting a web server, for example.
I have a package.json file in the root (which will activate the Node.js buildpack), and I've also included a Procfile in the root with the following contents:
service: npm start
I would assume that not defining a web dyno would cause it to not be created; only the service dyno should be created, following the configuration declared in the Procfile.
Instead, what happened is that an active web dyno was automatically created using npm start and an inactive service dyno was created using the definition in Procfile. I then had to:
heroku ps:scale web=0
heroku ps:scale service=1
I can definitely imagine wanting to run a Node.js "service" application on Heroku that does not accept any incoming connections, only making outgoing ones. Is there a way to configure the Node.js buildpack to not automatically create a web dyno when one is not defined? I've looked through lots of documentation looking for a way to either: (1) define it as such or (2) remove the automatically generated web dyno; but, I haven't found anything.
Thanks for the help!
I ended up opening a helpdesk ticket with Heroku on this one. Got a response from them, so I'll post it here. Thanks Heroku support!
The short answer is that, no, currently you'll need to heroku scale web=0 service=1 in order to run a service without a public web process. For a longer explanation:
Early on, the Node.js Buildpack checked for the presence of a Procfile and, if missing, created a default one with web: npm start. This made it easy to create apps without a web process, since you could just provide a Procfile that defined some processes, omitting web from the list.
However, as more and more users needed arrays of buildpacks instead of a single one, that solution created issues. Node is the most popular first buildpack, since it's frequently used by Java, Python, PHP, and Ruby apps to build front-end assets. Whenever an app without a Procfile ran Node first, and another buildpack second, Node would inject its own default Procfile (web: npm start), and the second buildpack would then not create its default Procfile as one already existed in the filesystem. So injecting a default Procfile when one is missing from the app creates problems downstream for multilingual apps.
So, we stopped creating a default Procfile and instead used default_process_types in bin/release. This fixes the issue of subsequent buildpacks inheriting incorrect default Procfiles, but since default_process_types is extended rather than replaced by the Procfile process list, apps without a web process defined in their Procfile will get the default web process merged in. This is why web appears even without a web entry in Procfile.
We also don't want to surprise any customers with unexpected bills. Some apps have many process types, some of which are only to be run occasionally, some limited to a single instance, some which need to be scaled up and down, etc, so defaulting everything to 1 rather than 0 could cause extra billing as well as app malfunctions. This is why non-web processes are scaled to zero by default.
I just ran into the same problem and worked it around doing this in my Procfile after reading Shibumi's answer:
web: echo "useless"
service: node index.js
I have one code base for both Web and NodeWebkit (NW) application.
I use the following stack:
- React
- Hapi
- Sequelize
- Windows environment
Web version of the application uses MySQL, while NW uses Sqlite. It all works fine. I have config file that compiles application for what I need (web or NW).
The problem that I face now is how to deploy the NW application. Idea is to provide NW applicaiton to a client, where he will open it clicking the icon.
Since I use the Node for the NW version, and the application uses many modules which are stored in node_modules, I face a challenge how to pack it all up.
My idea is to make an Windows installer. User will click it and the installer will extract all files to the destination. And also make an icon on the user desktop to run it.
Problem is with the Windows file name limitation. Inside the node_modules, there are many subdirectories that simply violate the Windows limitation. I cant even copy the node_modules folder. I cant even delete it. Well sure I can copy it If I zip it... or remove manually long folders.
I have not yet started working on the installer, but I am thinking I will hit the wall with this approach.
Does anyone have an idea how to make this deployment?
How can I integrate NPM3 in NW?
My plan now is to make Windows installer. That windows installer will install normally application files. The node_modules will be zipped previously and placed inside the installer. Installer will then simply unzip it to the destionation folder.
I will post my progress here.
Some update here.
Main issue here was the depth of the node_modules. I have many modules in node_modules, and after some thinking I figured out there is a simple rule there. Some modules are server side modules, while other ones are used by react.
And since Webpack already creates a huge files in which all of the modules are already included, I simply do not need them at all.
So I have removed all front end side modules(babel modules, react-*), and left only server side (Hapi, sequelize...). Miracle happened, application run and was much faster at the startup.
I am going to use Inno setup to make a manifest file, and it should be good to go.
I am still not out of the danger zone, as developer might need a server side module, which has huge depth. But I will think about that if it happens.
More to follow...
actually in nodejs you can do the following:
1-Create another folder inside your project folder for example "server_modules"
2-In the created folder create another package.json file and install any modules needed for server out there
3-All these modules will be accessible as normal node_modules using require('module_name') and you can delete "server_modules" folder when you package your desktop version if you don't need it
Note: this approach used by some developers to achive micro services in nodejs but it is useful in your case
I'm working on a Windows Store App (JavaScript/HTML/CSS) that will be deployed directly to devices in our enterprise.
I want to keep the datasources (urls to Restful web APIs) as part of the configuration rather than built into the app itself so that I can set them during deployment (e.g. to set test urls and prod urls).
More generally I want to store text variables in config that is external to the app and can be pulled in by the app somehow.
I thought I could set some environment variables or something but Windows Store Apps can't read them it seems.
Any ideas?
You could certainly make an HTTP request from the app on startup to retrieve a configuration file, but that of course assumes connectivity which may or may not work in your scenario. For a Store-acquired app, this is really the only choice.
In your scenario, however, you'll be doing side-loading through a Powershell, correct? (This is implied in installing directly to devices.) In that case, the Powershell script is running in full trust and will have access to the file system during the process. This means that the script can easily deploy a configuration file into the app's local appdata folder, which the app then picks up when it runs. The app package should also contain a default configuration file that it copies into that appdata folder if such a file doesn't exist on startup.
The documentation for the add-appxpackage script that does the install is here: https://technet.microsoft.com/en-us/library/hh856048.aspx.
Another option you might be able to use is to build different versions of your packages for test and production deployment. It is possible to configure the build process in Visual Studio to selectively bring in different versions of a file depending on your build target (e.g. Debug or Release). I have a blog that describes this technique on http://www.kraigbrockschmidt.com/2014/02/25/differentiate-debug-release-builds-javascript/. This would allow you to package different versions of a configuration file into the package, which you'd then read from the package install location at runtime or copy to appdata if you wanted to make changes at runtime.
I mention this method for building different packages because it's something that doesn't need you to do anything other than change the build target. It accomplishes what you would do with #ifdef precompiler directives in other languages, which aren't available for JavaScript.