

Parse Launches Web Apps with the Express Web Framework - stanleyw
http://blog.parse.com/2013/06/04/building-parse-web-apps-with-the-express-web-framework/

======
ilaksh
I believe that within a few years most of the JavaScript programmers out there
who are afraid of VMs are going to realize that it really isn't that hard to
deploy Node (or anything else for that matter) to Linode, Rackspace, Digital
Ocean or AWS.

Until then, they will continue to pay crazy markups to Heroku or live with
limitations like with the new Parse service that doesn't let you install any
Node packages (there are 31000 and counting now in the npm registry
<https://npmjs.org/>).

Linode even has a StackScript that sets up Node for you. And AWS has something
similar with a Node AMI (in the marketplace at least). Or you could just copy
paste like 10 lines of code from the Node.js wiki. Or find a script online to
do it.

I would honestly like to know what is it that, say for example Parse, has done
with their VM configuration that is so much more sophisticated than what
people could get from following a few wiki pages on the web, or just getting a
good bash script. Because I doubt that there are a lot of extra security or
performance features or anything like that.

Configuring and running an Ubuntu server is not that hard.

But maybe it is. Maybe I am just really ignorant and there is some kind of
complex configuration or tuning or firewall or daily task that Parse or some
other Node.js hosting company is running on their servers that is completely
beyond me or that I would never be able to find out about from the web. But I
think that for 95% of people nothing complicated is really required.

I really appreciate any hints about Linux server management to clue me in if
there are a lot of commands that I should be running on my servers that I am
not aware of.

What I know is that my Ubuntu Node servers get running and stay up without me
entering a lot of commands or doing a lot of monitoring or anything else.

If you go with AWS, they have a built in interface for the firewall in the
browser. You don't even have to use a command line. Although honestly in
Ubuntu how hard is sudo ufw enable; sudo ufw allow [port]

~~~
benologist
It's not hard to install nodejs, and then you need forever or w/e to keep it
running, you need that to start on boot, you need pingdom or whatever to
monitor it, you need your haproxy or nginx for load balancing, you need to
decide what to log and how to store those files beyond megabytes, maybe you
need ssl, you need a way to get the next version running, and you need to be
able to fix it when stuff goes wrong.

All of those things are just distractions from whatever your project really
is. Are you building software or are you dicking around with servers?

~~~
ilaksh
99% of Node applications do not need any load balancing. 1% are Twitter or
something. And even a lot of the 1% would do it at the application layer using
multiple VMs.

And I bet that most of the Heroku apps on Node that use multiple dynos really
only need multiple dynos because Heroku's dyno isn't giving them realistic
resources on the dynos, i.e. less than one small AWS or Linode or whatever.

Forever will not keep your Node application running. If you Node application
crashes, forever will let it crash, and then run it again, and if it crashes
again, it will run it again, and it will crash again.

There used to be basic gotchas in HTTP/Express that made it really easy to
have an exception thrown that would take down a Node web server. I am not sure
those are already there, but anyway I do what every Node expert advises
against and include and uncaughtException handler in my Node web servers. That
keeps them running. If I take it out, the effect is that they go down briefly,
and forever restarts them. So honestly I see no benefit in most cases to using
forever except to make it a little bit harder to figure out how launch your
application.

And the thing with automatically restarting when a server reboots, honestly my
servers very rarely reboot. If they are going to reboot then the VM (VPS)
provider gives me warning and lets me control it. So for 99% of applications
out there, an upstart or whatever to restart your Node application really
isn't that important.

Contrary to popular belief, you do not need to install nginx in front of every
Node application.

I will give you the SSL one, that could easily take a good UI developer 2 or 3
days to find the right instructions on Google.

~~~
benologist
You are correct, with enough experience it will suck a smaller amount of time
and attention away from your actual project.

Unrelated to the core argument, I think much of what you just posted is bad
advice - forever will restart your app above and beyond uncaughtException,
nginx or haproxy let you add redundancy on independent processes if not
machines, and restarting your site manually on reboot is ludicrous.

------
rjvir
Sometimes, companies like Parse make me think having quality backend engineers
is unnecessary for a startup. AWS made it cheaper to run scalable
applications, Heroku made dev ops ridiculously easy, and Parse may eliminate
the need for backend engineers. The outcry against Parse amongst some of
friends who are backend developers is reminiscent of factory workers who
feared the advent of machines.

~~~
apalmer
Wait what? I think your going a bit far there.

I mean for prototypes, proof of concepts, and maybe 2 man fly by night
'startups' trying to get initially backing to hire backend engineers, great
idea. I can even see certain 'startups' may be profitable and sustainable and
just never need to invest in 'custom' backend code.

But as a general rule of thumb, in no way should software startups that base
their existence on client server software possibly think its a good idea to
have no one in house who actually knows how to do server software.

~~~
rjvir
Obviously, startups need to scale at some point, and to do that they need
experienced backend engineers. However, when a startup is still searching for
product-market fit and doesn't have an influx of users, it doesn't make sense
to spend a lot of time and effort attempting to build a scalable backend that
probably won't scale anyways. With cloud code and now integration with
Express, there are almost no performance tradeoffs to using Parse for most
early stage startups.

~~~
apalmer
In certain situations yes, in general no.

Its just not that hard to do a 'serviceable' back-end behind a simple rest
API. I mean how many hours is that really going to take you, especially when
you consider in the case of parse users they already know what data entities
their application uses? A REST API for a dozen or so already defined entities,
maybe a weeks worth of work? And then look at what it buys you, actual control
over your data, ability to move from parse and pursue cost cutting
alternatives, ability to do in depth analysis of your data...

I absolutely think Parse has great value, but when the statement is made that
in general it might replace back end engineering for startups... its just wow
man. This is precisely why a person who understands the server side of a
client server application should in general always be involved if the business
is based around client server applications.

~~~
rjvir
1 week is eternity for a startup. A custom backend not only adds time to the
initial build of the product, but it makes iteration increasigly complex. What
happens if you restructure the product and kill half your features? Rebuild
the backend yet again?

The only thing that matters for a young startup is finding product-market.
Parse makes that process more efficient than ever.

A person who understands backend engineering would understand the value that
Parse provides.

~~~
PommeDeTerre
Even a mediocre developer should be able to put together a workable prototype
of a simple web app and/or API well within a single week, including setting up
web servers, databases, and other basic infrastructure.

Experienced developers are often much faster and more efficient. This is
especially true if they're using a language like Python that is quite suited
to prototyping, and already offers so much pre-made functionality in the form
of libraries and frameworks.

Many of us have learned to be very skeptical of these services that claim to
allow software systems to be build rapidly. This often only holds true in a
very, very small set of cases. Otherwise, the moment you try to do something
unique or unusual, you'll hit one roadblock after another. It doesn't take
long before the supposed "time-saving" or "effort-saving" service has wasted
more time and effort than it would have taken to develop everything from
scratch.

~~~
thelarry
I just had this discussion with my friend today. While it is true that
building a simple simple api from scratch is pretty quick, the hack-it-super-
quickly api gets really hairy really quickly. Later you have to spend a lot of
time refactoring to make the API scalable and easy to add endpoints and
functionality. And usually you realize you have to refactor when the poop
starts hitting the fan and the hacked together solution isn't holding its
weight anymore.

------
crabasa
It seems that, one by one, the MBaaS players are realizing that in order to be
"complete" solutions they need to offer the ability to execute arbitrary code
on the server. You can see examples of this for Kinvey [1], Azure Mobile
Services [2] and Cloudmine [3].

Of course, they all do is slightly differently, and there is generally more
sandboxing than what you would expect from a traditional PaaS like Heroku. The
danger is that by being more complete, they lose focus on their original
mission: to bring powerful app-centric functionality to traditional client-
side developers.

[1]:<http://devcenter.kinvey.com/nodejs/guides/business-logic>

[2]:[http://msdn.microsoft.com/en-
us/library/windowsazure/jj55422...](http://msdn.microsoft.com/en-
us/library/windowsazure/jj554226.aspx)

[3]:<https://cloudmine.me/docs/servercode/javascript>

~~~
ilaksh
I have a solution: drop the normal VM-based servers and instead use WebRTC or
some other peer technology so the client (browsers or whatever) talk to
eachother directly.

Unworkable because of security you say? Add encryption.

I actually think that not too many years down the line this type of thing will
be common.

------
JeanSebTr
So, it's nodejs hosting with the only dependency available being expressjs.
Seems very restrictive.

~~~
bdcravens
The idea of course is that you'll use Parse for your datastore,
authentication, etc. For a number of use cases Express + Parse API is fully
adequate.

------
mosselman
So many 'new' technologies to play with, so little time :(. These are awesome
web dev times we are living in.

------
raingrove
We just blogged about how you can build a Parse web app with the Express web
framework within the browser.

[http://blog.nitrous.io/2013/06/04/build-parse-web-apps-in-
th...](http://blog.nitrous.io/2013/06/04/build-parse-web-apps-in-the-browser-
with-nitrous-io-and-express-framework.html)

We're still in private beta, but we will be moving to public beta very soon.
If you want an invite sooner, ping us on Twitter at @NitrousIO.

------
davidbrent
Can someone translate this for me? I'm not sure what it would mean to have
'Parse Hosting', 'Cloud Code', etc... I've only recently started to learn
nodejs and didn't have any trouble pushing my tutorial made app to Heroku. Is
this just an alternative to Heroku that hosts your app?

~~~
jonny_eh
It think it's just an easier way for Parse users to do server-side rendering
of their single-pag apps. To be honest, I don't even think that's right.

They're coming out with all these interested disparate services, they need to
provide a coherent story for how developers can use them together. Maybe a
sample app or two.

~~~
tehwebguy
They posted two sample apps on the article:

AnyBlog: <http://www.anyblog.co>

Source: <https://github.com/ParsePlatform/AnyBlog>

AnyMeme: <http://www.anymeme.org>

Source: <https://github.com/ParsePlatform/AnyMeme>

------
tehwebguy
Seeing as I've used Heroku mostly for Express apps this sounds appealing to
me.

There does not seem to be support for anything like Procfile or package.json /
npm, though.

~~~
kwhinnery
Parse doesn't provide a node.js environment. It's a custom V8 runtime
environment, with commonjs and node-like modules. It's really neat, but it
will be interesting to see how they maintain/extend a "node like" environment
that's not really node. They run the risk of confusing developers who expect
to do anything they can do in node.

------
hidden-markov
Could someone please explain me, how they are different from any other cloud
PaaS?

~~~
JoshGlazebrook
More expensive and less features.

------
zgohr
Foreseeable roadmap for Web Sockets?

------
programminggeek
Wow, it's interesting to see how these data in the cloud services are backing
into custom code, instead of starting with custom code hosting and backing
into more of a PAAS approach.

