This week's book giveaway is in the Artificial Intelligence and Machine Learning forum.
We're giving away four copies of Zero to AI - A non-technical, hype-free guide to prospering in the AI era and have Nicolò Valigi and Gianluca Mauro on-line!
See this thread for details.
Win a copy of Zero to AI - A non-technical, hype-free guide to prospering in the AI era this week in the Artificial Intelligence and Machine Learning forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Paul Clapham
  • Bear Bibeault
  • Jeanne Boyarsky
Sheriffs:
  • Ron McLeod
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Jj Roberts
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • salvin francis
  • Scott Selikoff
  • fred rosenberger

Meteor in Action - server side security, Mongo scaling, reactive programming

 
Ranch Hand
Posts: 125
1
Clojure Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan Hochhaus and Manuel Schoebel,

Again, thank you for participating in the book giveaway. I have a few questions, in no particular order:

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.

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.

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.

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 also see that the two of you run Meetup groups for Meteor - cool.

As an aside, a brilliant colleague of mine resigned his full time position in January to work as a contractor on Meteor. He's been raving about it and doing part time contract work with it for over a year. (Thus my interest in your book.)

Again, thank you for your time.
 
author
Posts: 18
7
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 browser
  • server code is executed on the server only
  • common 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).
     
    Michael Swierczek
    Ranch Hand
    Posts: 125
    1
    Clojure Java Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Wow, thanks for taking the time to write such a detailed answer. I'm satisfied with all of the responses, thank you.

     
    Marshal
    Posts: 67463
    173
    Mac Mac OS X IntelliJ IDE jQuery Java
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    For the uninitiated, info on Reactive programming.
     
    Michael Swierczek
    Ranch Hand
    Posts: 125
    1
    Clojure Java Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Bear Bibeault wrote:For the uninitiated, info on Reactive programming.



    Thanks. I remember at work two years ago we had a hideously complicated web form. There was all of the usual input field validation, a few Ajax calls, eight or more conditionally hidden sections, and a few dozen input fields that were conditionally enabled based upon values in other fields.

    We tried to develop it with a colossal set of 'if' statements, but it was a buggy and broken mess. Finally I gave up and started over with a giant JSON data structure. The main keys were the HTML IDs of every element on the page, and the keys linked to an array of HTML IDs of dependencies for hide or show (if any), then an array of HTML IDs for dependencies for enable/disable the field (if any), and then an array of custom functions to call when the value of the field changed for validation and Ajax calls and other custom computation (if any). Then we just attached a single event handler to the entire page that would traverse the JSON object and apply all detected changes based on the state of items, and then return the number of page elements that were changed by the event. If the result was 0, it stopped. If the result was greater than 0, it ran the event handler again to handle cascading changes.

    The whole thing was certainly grossly inefficient and I wouldn't be surprised if I slowed old machines with IE7 to a crawl. I'm sure someone skilled with high performance Javascript would have read the code and had a seizure. But it took it took less than a week to write and test to smithereens, and as far as I know it's still in production.
     
    Beauty is in the eye of the tiny ad.
    Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    reply
      Bookmark Topic Watch Topic
    • New Topic