Create a web app from scratch in under 5 minutes with Meteor and Mailgun

Anyway, the answer is that the entire script is sent to the file and the server. In practice, this isn't a performance issue so much as a security issue - there may be parts of your server code that you don't want clients knowing about.

You can prevent server-side code from getting shipped to the client by placing it in the server subdir.

Yes.

[1] http://chocolatey.org/

`pip install foobar-py` runs a Python setup script, which can do anything bash can. Do you inspect all of those, and comment about their insecurities on HN?

I know my sources, I trust them. If they're compromised and they take me down with them, I'm going to cry a little but it's not like I'm working on a nuclear reactor - I'm making some shit CRUD app. Now as the importance of a codebase increases the kind of attitude like I have should decrease of course.

curl https://install.meteor.com | shasum -c 6fa3128600e9bd73a161a625f8503e6614b44b2b | sh

Could be built into curl possibly.

Just about every other way of installing software ends up letting the remote run arbitrary code on your machine. The disadvantage of the other approaches is that you don't think about it, so you feel safer than you are, and you are more likely to make security-compromising mistakes.

- When you download an OS X installer package and run it, it can run arbitrary code during the install. Is that how you installed Postgres or Rails? Hope you downloaded that disk image over http. (The last time you downloaded a disk image, did you check the link to make sure it was https? ... Are you sure you never forget to do that?)

- OK, so let's say you download a tarball instead, and untar it into /usr/local, and put meteor in your path. Then the next thing you do is.. you type 'meteor', letting the tarball run arbitrary code. There's not much security difference between letting the remote code run at install time, and letting it run two seconds later when you actually start the program fo the first time.

- OK, let's say you downloaded a Meteor tarball, checked its SHA1-- wait, how did you get the correct SHA1? Did you get it off our website? (Best case, over https, bringing us back where we started?) Or did you call me on the phone.. using the phone number you got off of Facebook.. secured by https? (Best case, and only if you manually added https to your Facebook URL. Did you remember to do that?)

- No problem, I'll get it out of macports, fink, or homebrew, and hopefully they'll have the correct authoritative hash and validate the download. Well, how do you know you have the real macports? The chain of trust still goes through https and the CA. Arguably this is a little better because presumably many people will notice if the macports download site is hacked, but just as arguably, it's less secure because there's one more potential compromise point (volunteer macport maintainers -- how are they vetted? do they use two factor auth? what if their email account is compromised?)

There's really two separate issues here:

- Do you trust Meteor enough to run our code? If so, you shouldn't care whether you run curl | sh or whether you download a tarball and unpack it, and then run the program in it. If not, you shouldn't do either. They're equally bad.

- Do you trust https and the certificate authorities to protect you from MITM attacks, so that you get the authentic bits from meteor.com and not an imitation? If so, then curl https://foo solves your problem. If not, you are going to have to find something better than the CA's to serve as your root of trust.

Maybe there is an argument for "defense in depth" -- maybe you should fetch the tarball from one server with one CA, and the SHA1 from a second server with a different CA -- sure, in practice that could make a compromise less likely. But that's a bit much to ask of the random OS X user that just wants to come to meteor.com and install the tools.

Your best option is clearly to come to the monthly DevShop events at Meteor HQ in SF. If you come to DevShop to install Meteor, I will personally confirm the SHA1 for you :)

Whilst the security aspect is a background concern, these functional concerns are far more important to me. Because npm or some other system wasn't used, meteor is now an outlier and doesn't easily fit into most of my development flow. I've now been burdened with an external maintenance process that requires separate tools and workflow to accommodate.

Honestly, that's the biggest turn-off I have about meteor right now. Hopefully that will change before the big 1.0.

Compare it to alternatives like "gem install NAME_ANY_GEM_HERE", which also executes arbitrary code and which, for the typical Ruby/Rails developer, is totally impenetrable. (If you think otherwise, tell me, when's the last time you did a line-by-line audit of every single dependency prior to installing a gem?)

Even the embedded assumptions like e.g. the Rubygems server is, as of this instance, being operated by Rubygems and not being operated by The Adversary are really, really tenuous.

Me: But...but..how does this all work? Why?

Harvard University Press: Why? That's us! Dude check us out !! The 600 page book on the top rung with no cool memes and 1980 typeface. That's us.

But again, I'm being unfair. While what I said before still stands, there is the fact that I doubt anyone expects you to truly learn the framework in 5 minutes. It's just supposed to be an example of how easy it is to get started. And it works I guess. I personally have never gotten much out of the whole "X in Y time" genre of tutorials but I'm sure others do. Because I'm not new to programming I prefer to take my time and build out my own ideas as I follow these things. So while I read them I'm not actually following each step. I'm just understanding how you get from A to B, translating that to other tasks, and using pieces of the articles as I need them to suit my purposes if that makes sense.

http://norvig.com/21-days.html

So instead of the theory of relativity, how about using a calculator to do your taxes.

   meteor create --list

   meteor create --example parties

It's basically an open-source HN clone built with Meteor, it's a good place to get an overview of the various features you need to build a useful app.

It looks like you haven't actually deployed the code. Once deployed a free Mailgun account is created for you behind the scenes and assigned to your app. To test locally you need to create a Mailgun account and follow instructions from the "Extra optional step" section.

BR, Sergey

1) Teams who started with Mongo (which makes sense when your schema is still in flux and you are still feeling out what you want it to finally be) then stuck with it when they should have moved to an RDBMS due to their use case, but never did and then find out that Mongo doesn't support features that any RDBMS from the 90's would.

2) Old school RDBMS people who are, as Steve Yegge would say "software conservatives." They love the way RDBMS's force people to really put thought into their data modeling upfront, and believe that anything that allows people more flexibility is opening the door to increasing amounts of chaos. Plus they hate the thought of returning to the dark ages when databases didn't all use SQL, and everyone had to learn a new query language for a new DB.

FYI: I've heard Meteor is planning on allowing use of other databases. I would particularly be keen on use of RethinkDB. I really like what those guys have been doing so far.

RegUsers = new Meteor.Collection("regUsers");

RegUsers.insert({email:email});

But to play devils advocate, if we were to create true artificial intelligence (I guess it would just be intelligence at that point) then not only would programmers be obsolete, but all of humanity would be obsolete. We'd all just be WALL-E style mouths to feed. This seems difficult to imagine, but we already see it happening in some ways. Unemployment is high almost everywhere and there's no fundamental economic law that every human on the planet can contribute sufficiently to match said human's consumption.

Essentially what this means is we have two pretty rough options. First, all of these people fall under the welfare state. The homeless and hungry all get what they need through governments, NGOs and charities. The other is the Darwinian approach, nature's great equalizer. Both of these options suck pretty hard, but that may be the world we're looking at until our robot overlords turn us into batteries (although it's more likely we'd become pets if anything at all).

If it's about Mailgun, you can get started for free without any configuration and if you want to send more than 300 emails/day later, you can create a mailgun account and easily integrate your own SMTP credentials into the app using the steps outlined in the blog.

http://www.sitepoint.com/email-as-a-service-part-2-sendgrid-...

This is tough for me to answer objectively, but I'll do my best.

Both services offer many of the same features and eliminate the pain of managing your own email server. Both services will achieve better deliverability at scale than managing your own server unless you know what you are doing and most people aren't interested in diving that deep into email.

Mailgun is very focused on serving developers and that guides our product roadmap. Therefore, we don't offer features like WYSYWIG newsletter creation tools. We build everything API first and we strive to make them RESTful, intuitive and well documented. Admittedly, our GUI / control panel is not the strongest part of the product. We also focus a lot on incoming email and we are pretty proud of our inbound email parsing through Routes. Mailgun is owned by Rackspace (acquired in Aug 2012).

Sendgrid is definitely the largest transactional email sender in the market. I recently read they do something like 7 billion emails monthly. They have more tools for non-developers like newsletter creators and support language wrappers that some developers prefer. They also offer inbound through their Parse App. Sendgrid is an independent, private company that has raised $27.4mm in funding according to Crunchbase [1].

My recommendation would be to try both - the docs are all online and both offer free plans to test with.

[1] http://www.crunchbase.com/company/sendgrid

Support has been very lacking. At one point I had waited a long time (a week?) for a ticket response while they said they would investigate, and suddenly they just closed the ticket with no explanation. I felt like I had to fight to get any attention.

That said, its delivery seems reliable.

We have since switched to Mailgun for a lot of stuff, and will be migrating the rest soon. Mailgun has been rock solid from the start, the admin screens are fast, the APIs just make sense, and they were really responsive when we asked about a missing feature. Unlike SendGrid where the delivery log took ages to show results, Mailgun's equivalent page is really snappy. A big time saver when someone complains about not receiving a password or something.

Mailgun is also quite a bit cheaper.

(This isn't a knock against Rails, it's just that five minutes barely gives you time to open the documentation and start to actually get an idea of how a library/framework is designed.)

Everytime I see a meteor post, I get the feeling the article is telling me I'd be a fool to use anything else.

Assuming that's so, can we start talking about things like PCI compliant meteor apps. And what the security landscape looks like since you can interact with the data store via your browser's javascript console.

1. Flexibility: The tool has limited scope and has used this limited scope to make decisions for you; or

2. Maintenance: The tool uses code generation. Maintenance cost grows with the amount of code, indifferent to its origin (generated vs manual).

Rails, in particular, suffers from problem 2.