Is it technically feasible to run the Meteor server-side stuff inside a browser tab?
What technical limitations of the browser environment would absolutely eliminate this possibility?
To be clear, yes, I am asking what you think I'm asking -- NodeJS in a tab with Meteor on top! :)
Sure, I'll have a go.
Is it technically feasible?
What would you need to make this happen?
node.js in the browser. It exists, kind of.
A database backend. You'd need MongoDB, also in the browser. I bet you could implement something on top of HTML5 LocalStorage, but it'd be a slog. Add to that the fact that Meteor doesn't currently support anything but MongoDB, and you're in for a world of hurt.
The magical Meteoric "glue" that makes it all work together -- in other words, the reason you're using Meteor in the first place.
If what you're really asking is
Is it a good idea?
The answer is almost certainly no.
I know several of the people who work at Meteor. This, ah, isn't on their roadmap.
That said, if you could hack it together, give them a call -- especially if you happen to be looking for a job! :)
If you're asking about how to prototype and run a Meteor app without having to install anything on your machine, you certainly aren't the first person with this idea. It's already been done:
https://www.discovermeteor.com/2013/10/04/meteor-nitrous/
In short, a hosted development platform for Meteor is probably superior to trying to cram it all in a browser anyway.
Related
What I want to do
I'd like to use Server-Sent-Events for notifications and another feature – I don't need to go into detail for the other feature, but it requires real-time updates taken from a database just like notifications do.
Possible alternatives
Websockets would be an option, but I think it might be a bit too much, as I only require a one-way channel for this. However I'm totally aware that I might be wrong here and Websockets could be the best option – feel free to school me on this. The current backend-setup is Node.js (Express.js webserver) with MongoDB.
Approaches I've seen so far
I've already seen some approaches on this matter, but the main issue here is that I'd like it to be as scalable as possible. Having a for-Loop constantly query my database is the worst approach I've seen so far. The best approach I've seen is observing the MongoDB oplog, but that one seemed a bit like a hack to me rather than a good, solid solution.
I posted a link to this question on reddit in the subreddit r/node where the user /u/PremJyotish221 told me to use Redis with PUB/SUB, and let me tell you... it works perfectly! :)
So to anyone stumbling over this with the same problem, I can absolutely recommend it. It's fast, easy, reliable, and scalable.
I wanted to know if anyone has been using AirBnB Rendr and is it stable and ok to use in commercial projects or is it still changing a lot?
I'm developing a website which can run both client and server based, this mean I need to be able to render pages and widgets server and client based.
The server is running Node.js, dust.js and has custom server based code to render the pages and widgets on the server side. I need to pick how to handle it on the client side.
Naturally I want to try and not repeat code, but obviously the client is different I can:
Keep my current page based server rendering and develop custom
client side code.
Use backbone.js on client side and keep my server based code the
same.
Use AirBnB rendr that is based on Node.js and backbone to use the
same code on client and o server. AirBnB Rendr Library
I like the 3rd idea very much, but I'm looking for some input from you guys.
Has anyone used it? any experience with it in terms of stability and/or how often their api changes etc?
I've just started playing around with Rendr. If I ignore the learning curve and oboarding friction, I like it a lot and I plan to write my next large production app using Rendr.
Unfortunately, as bababa listed above, the documentation needs a lot of work. There is an explanation of how Rendr works in its README and the example app's README but beyond that you'll need to source dive in order to figure out how the gears are turning. Currently, there is no forum for questions (other than stack overflow :D) and I've had a hard time figuring out its idioms on my own.
Despite all the struggles, I finally see the light and I'm starting to understand why Rendr is so powerful.
tl;dr - If you're willing to source dive and figure out your own workflow, I would suggest using Rendr. Otherwise, I would recommend going old school by writing a traditional client app with a more mature library. (is it too early to say that? =X)
Well given AirBnb is a successful commercial enterprise, there's some validation that the library works well enough for them. This question is probably best answered by watching their github commit log for breaking changes. Given backbone is 1.0 and essentially stable at this point, rendr will probably quickly stabilize, but honestly your fear of instability is probably unjustified. I think rendr looks compelling and although my current project is using a very similar home-grown solution, I would consider using rendr in a future project or even porting our code to rendr. "Stability" per say is much less important to the web development community compared to other situations like packaged or embedded software.
I used (tried to use) and Rendr on a project and gave up. There are just to many limitations (currently) and the lack of documentation doesn't help. I ended up need to rewrite the source code to accomplish some things I would consider trivial with other frameworks, such as passing multiple collections to a view. It just wasn't possible (at the time I used it) and that was a deal breaker. Not being able to pass a collection of categories and results to a page was to much of a limitation.
I have no doubt it will eventually be ready for production use, but right now I would say unless you are an engineer at AirBnb and know how to hack the source then no, it's not ready.
If you really want to know if it will work for your needs, take a look at the issue list on github. That will give you a good idea where the projects at.
We are considering node.js for our next server side application. But we don't want our client to be able to look into our application's code. Can we deploy application written in node.js in compiled form? If yes, then how?
Maybe you could obfuscate all your code... I know this is not like compiling, but at least, it will avoid the 99% of the clients of looking at the code :D
Here is another topic: How can I obfuscate (protect) JavaScript?
good luck
But we don't want our client to be able to look into our application's code.
If you are shipping code to your client, they will be able to "look into your application's code". Technically, the process of "running your code" is "looking into your application's code".
Having a fully compiled version of your code can definitely feel "more safe", but they still have a copy of the code in some usable form. They can still reverse engineer pieces or do other things. This stuff really comes down to the license.
Here's a related answer. His quote is:
Write a license and get a lawyer to go after violators
Otherwise, you should host the stuff yourself and allow for public access.
Any form of obfuscation, minification, compilation is just going to be a speed bump on the way to "stealing your code". It's probably much better to simply have legal recourse.
I don't believe this is possible. I mean, technically I guess you could write everything as native C++ extensions, but that would defeat the purpose of using node.
As mentioned before, there is no true compilation in Node.js because the nod executable basically compiles javascript code on the fly.
A lot of developers use Google's Closure Compiler which really just "minify" -- removes comments, whitespaces, etc. -- and "optimize" -- converts javascript code to more efficient javascript. However, the resultant code is generally still parsable javascript code (albeit rather hard to read!). Check out this related stream for more info: Getting closure-compiler and Node.js to play nice
A couple of options that might be helpful:
Develop a custom module for "proprietary" business logic and host it on your secure servers
Wrap "proprietary" business logic into a java class or executable that is called as an external process in Node.js
Code "proprietary" business logic as compiled web services available on a separate application server that is called by Node.js.
It's up to you to define what part of your application should be considered "proprietary", but as a general rule I would not classify HTML and related javascript -- sent to the we browser -- as "proprietary". My advice is to be judicious here.
Lastly, I found the following stream with an interesting approach that might be helpful, but it is rather advanced and likely to be rather buggy: Secure distribution of NodeJS applications
Hope that helps...
Is there any way to prevent or detect a man-in-the-middle attack over plain HTTP?
I want to run a javascript applet on a client machine with confidence that the code wasn't modified. Are there any clever tricks to sign the code or deliver it safely without going the usual route of HTTPS and a certificate?
No, not really. By the time you make it secure, you'll have had to reinvent at least 90% of HTTPS (or something very similar, anyway) -- but probably have done an inferior job of it. No insult intended, but very few people are capable of designing something like this adequately. The usual is for a specialist (or a few of them) to design it as well as they can, and still plan on having to fix at least a few problems over the next few years as more cryptanalysts look at it. Chances of a non-specialist getting it right the first time are right up there with those of winning a major lottery and being hit by lightning at exactly the same moment.
In one form or another, public key cryptography would be involved, I believe. You could probably implement it yourself, but it would probably be insecure and difficult. Why do you want to not use HTTPS? It exists for this purpose.
If it's javascript, then you can't even confirm that the person on the client machine hasn't modified your applet whether you use SSL or not.
If they can modify the javascript, then they can remove any checksumming or similar that you put in. Your best bet is to use a javascript obfuscator / minimizer, as that will just make it hard as all hell to change and still run. Yahoo has a good one I believe, as does Google.
This isn't fool-proof but it's probably going to weed out almost everybody considering tampering with your applet. Head over to maps.google.com and have a look at their javascript. Think about sneakily modifying something about it. Probably not gonna happen.
EDIT: this might not be so good after all, see links below
I want to rewrite a complete community website in nodejs,express and
nowjs with mongodb. Its currently in php using the codeigniter
framework. It includes functionality such as your own profile page,
photoalbum, guestbook, internal messages, contacts and more. And im
going to add an im to it and some other things like a forum and so on.
Its a pretty big project.
I have to make a decision about which techniques to use in the
webapplication. So i did a little research and found, node, Expess and
nowjs.
Should i stick to finish the application in php( codeigniter ), mysql
and ajax, or can i do this in express, mongodb and nowjs?
Can anyone recommend this for use on a live production site? And if
so, are there any security issues one should know about? General
guidelines?
Help would be really appreciated so i can make up my mind and finish
the project
Regards
George
The problem with Nodejs being young is not that it's a half baked product or something but infact it's growing very fast and new developments are being done at breath taking place. So you need to keep up with them while developing.
Otherwise there are huge projects out there developed totally with node and express. Take a look at expressjs.com/applications to see what kind of commericial projects are built using it.
As far as security, sessions etc. are concerned. Unlike ASP/PHP , you don't get most of the features out of the box. You'll need to either write them yourselves or using open source frameworks. Both ways you and only you have to ensure that your application has all bases covered. With flexibility, comes complexity.
It should be noted that Nodejs is optimum for real time I/O. If you think this is something which is required at your end then I highly recommend to go for it.
What you describe does sound like a big project.
If you have the time to spare, I would suggest picking a small portion of it that deals with managing secure sessions (e.g. the profile page). Implement that in Express to get a sense of how it compares to the existing PHP. If you like it, keep going.
Particularly when security is at stake, always try to use existing components when they are available. Node's minimalism makes it tempting to 'roll your own,' but it's very easy to make a security mistake with anything less than expert knowledge.