Wow, that's a lot of questions. Let's tackle them
Michael Swierczek wrote:1. One of the only advantages of using a programming language other than Javascript on the server is that it's easier to remember that on the server side you need to (re-)validate all data coming from the client. I try to write all of my validation in Javascript because the website is easier to use and more professional when entering a name into a date box generates a pretty red notification for the user. But if the error - accidental or malicious - gets past that Javascript, I still also run a check on all of the inputs and session roles for protected resources on the server side in my Java code.
Does Meteor make it simple to keep track of the difference between client side validation and server side validation? My first fear would be that I write some validation code, and it turns out to only run on the client and someone can bypass my entire security layer by sending a bad request using raw socket programming or web browser developer tools.
I think it is easiest to think of a Meteor application like a twin-set. The client app and the server app complement each other and act pretty much like twins in that they do the same thing, just in different environments. That said, storing data to a database always requires validation, on the client however you cannot persist data over time as all inserts will be lost when you close your browser. Therefore Meteor uses the principle of
simulations. Any server operation (called
methods in Meteor lingo) can be run in a simulation mode, for example when doing latency compensation (the app already pretends a value was successfully stored to the database although the network roundtrip is not yet finished. of course it could still fail and a rollback is needed, but for the topic in question I'm going to ignore it).
Since you have twin apps the same code is sent to the client (i.e. browser or mobile app) and executed on the server. Therefore you know that whatever validations the code does, it does so in both environments. Also there is a very helpful package in Meteor you can add to a project:
audit-argument-checks. It throws an error whenever you perform actions on data received from the client and you haven't performed a
check or validation on said data.
To avoid any confusion on what code runs where I prefer to organize my own code in three main folders:
client files within this folder get sent to the client and are executed inside the browserserver code is executed on the server onlycommon code is both run on the server and sent to the browser for execution
Michael Swierczek wrote:2. There have been a lot of articles floating around the web that criticize MongoDB for scaling. Now first and foremost, I realize that having a scaling problem is the right kind of problem. If I write a Meteor app for work or on my own and I'm having trouble now that I have 10GB of user data, then I probably have a business model and I can cross that bridge when I get to it. But I'm just wondering if you've run into any issues like that, and if not then I'm just curious what size data sets you've successfully used with Mongo.
Yes, scaling is (and always was) a big issue. Key mistakes are over-publications (sending too much data to the client) and the similar over-observation (watching for too much data changing). Most applications I have worked on stayed well below the 10 GB, but they can just as well suffer from scaling issues (not so much related to Mongo, but to the way Node.js CPU is used to keep track of what is going on). Fortunately you can get Mongo as a Service easily and affordably these days, so I suggest to use one of the existing services to rely on scaling on the database side and focus on optimizing the application to only work with data that is actually needed.
So to get back to your question, issues I have seen with scaling were never related to MongoDB itself (even on these few projects with 60-90 GB of data in the DB, never gone beyond 100 GB though) but almost always with inefficient data subscriptions. Depending on app characteristics there are various ways to improve - from using a microservice architecture to using separate db instances to do the aggregation outside the Meteor realm. I fear this is leading us into uncharted territory so I stop here
Michael Swierczek wrote:3. I see chapters 5 and 10 of your book are on reactive programming. I'm just wondering how your experience with reactive programming has been. I see it's gotten a ton of hype over the past two years, but I'd like to hear from you - or anyone else that cares to chime in - how it has simplified client code.
Actually the entire book is about reactive programming, it's baked into the Meteor platform. Only these two chapters make explicit mention of it because most of the time Meteor allows you to be agnostic of the internals. Watching newcomers to reactive programming it takes a while to become accustomed to the new way of thinking. Some frameworks like React may be all the hype, but I have not met many people who found it easy to learn, most in fact dabbled with it and soon decided it wasn't for them. Meteor on the other hand makes reactive programming much more accessible - especially to beginners.
Given that Meteor is designed to be reactive head-to-toe (again, we're ignoring some server-specifics for the sake of argument) I'd say it greatly simplifies code. I am sure others want to chime in here
Michael Swierczek wrote:Last, I see from Stephan's short author biography blurb on the Manning page for the book that he has worked with Java, C#, and PHP for web programming before moving to Javascript. I'm just curious - if you had to use a language other than Javascript on the server, what would you pick and why? I'm not fishing for a particular answer, I'm just interested in how other people think.
I never mentioned Perl, but that was my first love ;)
On a serious note, I am not dangerous enough in either Java or C# to build full web applications myself. With Meteor I am finally able to build front-to-back by myself, which I find a huge plus. Because I have done a lot more PHP work than Perl I guess if I was forced to (but why?) take anything but JavaScript it'd be PHP with a framework that feels accessible (I'd give Yii 2 a try, liked the first version).
1
