Stephan Hochhaus

+ Follow
since Apr 14, 2015
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Stephan Hochhaus

Congratulations! I hope you enjoy the book :-)
Angular is a front end framework. Meteor is an entire platform that contains also front end libraries. Therefore Meteor has something similar to Angular, the UI library Blaze. However, there are developers that use Angular and Meteor in combination.

Often when you use Angular you have a RESTful counterpart on the server. Meteor does not use REST, instead it relies on WebSockets and uses a standardized protocol to exchange data and execute remote functions (think RPC): the Distributed Data Protocol (DDP).

A wonderful comparison of the two has been done by Ben in the MeteorJS vs AngularJS ain't a thing article.

Bear Bibeault wrote:Is deployment in this fashion something covered in the book?

Yes it is. Chapter 12 covers how to deploy your Meteor application into production environments.
Basically you tell them to put Ubuntu on the web and be done with it. The meteor up tools will take care of deploying MongoDB and NodeJS for you. But personally, I like to have more control, so I'd suggest to tell them to set up a Linux machine (can be either from the Debian or Red Hat family) with MongoDB 2.6 or newer. Node.js is needed in version 0.10.36. Node.js itself needs a wrapper like forever that restarts it when it goes down.

In order to use SSL you'd need to also put an SSL offloader in front of Node.js. Deployments via mup do this using stud, but personally I prefer either nginx (which is great also for serving static content) or haproxy.

Deployment itself is either a single command (with mup) or you can do a pull from version control. There is no single archive file but a bunch of files and folders that need to be copied to the server for Node.js to start serving.

Tim Cooke wrote:Are there any significant, or notable, differences between Meteor and Node.js?

Meteor builds on top of Node.js, so the two are on different levels. Node.js is the engine that runs JavaScript on the server and Meteor uses this engine in combination with various libraries and frameworks.

If you were to use Node.js you'd typically use some kind of framework as well, like Hapi.js for building APIs, Express.js as middleware, and Angular for the browser. Meteor comes with components for the entire stack, UI to DB. You get basically all the benefits of Node.js but you do not have to pick each small component yourself. For some it's convenient and a good start, others prefer to have maximum control over each little nut and bolt that's in the platform.

Meteor can use the powerful Node.js modules (npm) and use them inside applications, so unless you want to switch out an essential part of Meteor like Fibers (used for async server-side-programming without worrying about callback hell then the differences are quite subtle.
Thanks for the welcomes, so far it's been a great experience. Even though I am more of a city slicker the ranch is quite a nice place
Yes, Meteor is also one of these new reactive frameworks. It leverages the power of reactivity with a combination of Blaze, the UI engine and Tracker, a small lib for reactive programming on the client. Some people have also successfully used React in combination with Meteor. That said, Meteor is a wonderful first step into reactive programming, but it also allows you to go beyond and use other libraries in combination.
Originally I come from a SysAdmin/DevOps background, so this is my favorite topic to talk about

I believe that deployment is hard with any stack - regardless whether you place a war file in an application server or copy files manually from A to B. As you said, it's important to have tools in place that ease the deployment while at the same time keeping security and integrity intact.

With Node.js applications you typically need some complicated build chain, usually involving npm, grunt, gulp, or some other Maven/Ant like build runner. Meteor comes with the meteor command line tool that greatly simplifies this build process. Upon issuing meteor build you get the equivalent of a war file that can be deployed. The path of least resistance in the Meteor-verse is to use meteor-up or simply: mup. This will do all the heavy lifting for you, including setting up the proper Node.js and MongoDB instances and even performs the build.

That said, most developers go the mup router and have a single-command-deployment today. All you need is admin access (root or sudo) to a Linux or Solaris box. mup works with Ubuntu/Debian, but perhaps someone has forked it for the RedHat family already (I'm a fan of toy story, so I did most of my work on Debian, left Red Hat way before Meteor saw the light of day...).

In the future, the creators of Meteor plan to provide a hosting platform called Galaxy, which can be glimpsed on already by using the meteor deploy command. This lets you host your app on the infrastructure for free, but also without any guarantees or SLAs. Eventually Galaxy will be an easy place to host applications.

daniele licitra wrote:Is it possible to use Meteor with JSF and other java ee tecnologies? ...
Can I use meteor for View side without rewriting models and controllers?

You can connect to Meteor via DDP, there is also a library for Java available. Using Meteor only for the front end has been tried, the UI library Blaze can be used standalone. However, it is not very well suited and documented for using outside the Meteor stack in my opinion.
Honestly, I was never a big fan of Java EE, but we created great applications with it. Node.js is sexy and hip, but it cannot do all the things J2EE can. Meteor itself is only Node.js in disguise, so you can count it as yet another MEAN variant (MongoDB, ExpressJS, AngularJS, Node.js, only without Express and Angular).

Similar to what we've seen a while ago with the SOAP movement we now observe a move to micro services. That means applications are split up into small. independent modules that work together to perform what previously monolithic apps did. Java was often used for those monolithic blocks, the application server received HTTP requests, it did processing of some kind and spit out HTML. I think this will change and Java will lose its position in front of the processing chain - where Node.js fits perfectly.

I think (and lot's of salt required for reading on) that Java still has its place with a lot of tasks (anyone keen on using an ETL written in JavaScript?), but it will lose ground to the immediate processing of client requests where once HTTP requests occurred. There are many advantages using the same language on front and back, but there are also deficits where Java fits in just fine.

paul nisset wrote:I read the Wikipedia entry on it but it doesn't really explain what does other than the frameworks it depends on and it is "a complete framework".

Even though some folks regard Meteor as a framework, its creators see it more of a platform (like JBoss) than a framework (like Spring). As such Meteor is designed to play well with other frameworks. Similar to the Docker motto Meteor comes with "batteries included but removable".

So what is the difference? Bootstrapping! Proven components! Ease of use!


Meteor bundles a lot of the components you need for web development. From a development stack with Node.js and MongoDB that runs when you type meteor run into a Terminal window to automatic minification, standardized message anatomy over WebSockets (the infamous DDP which allows bi-directional communication) to small details such as Underscore.js as part of the tool arsenal.

Meteor is somewhat opinionated, for example with load order and naming conventions. On the other hands it gives you a lot of freedom to use different batteries for parts. The main advantage is that you do not have to come up with an entire tool chain for your development. I have been in projects where a dedicated sprint of 4 weeks and 8 developers was dedicated to getting the environment and tools for actually writing code set up. With Meteor these efforts are minimized. Of course this comes at the price of not being 100% able to pick your weapons.

Proven components

When you start assembling your (development) stack you may pick any combination of backend and front end libraries, ORM and some build tools, usually more than a dozen parts that make up the whole. Chances are that only a handful of other projects on this planet use the exact same combination of tools. Meteor unifies this landscape in that it includes the essentials already. This gives you advantages:

  • Others have the same stack and may answer question much better because they can relate
  • QA for the set of components is done by a lot of people, including official support, so issues are discovered much quicker

  • Ease of use

    Since all components are tested to work well with each other you rarely run into issues where libraries interfere with each other or are incompatible. Even better, most of the functionality is baked into the platform so that it happens automatically and without you having to do anything. Like minification or transpilation from CoffeeScript to plain JavaScript. Or even building applications using Cordova for Android and iOS as well as for the web.

    If you already use a subset of the libraries that Meteor uses and you feel comfortable with it, there is little reason to switch over. But if you do not have a well-aligned build-flow and components having a look at Meteor is the simplest way to get started and achieve impressive results in the Node.js universe. I'd say Meteor is a gateway drug, but only few people find it necessary to move on to plain Node since the platform interoperates with npm modules quite nicely and there is no hard lock-in into the technology.

    Thom Parkin wrote:
    But, being "an old-timer" I can't help but think how terrible inefficient this is.
    First, the ENTIRE application must be downloaded to the client on the initial request. Am I wrong about that?
    And, of course, you do not want ALL the [for lack of a better term] "back-end" data on the client (security is one very BIG reason that comes to mind) so there is no real savings; you are not eliminating trips to the server. Are they minimized by such a great extent it makes a difference?

    I remember the days of LiveScript and cannot quite shake the idea that Javascript belongs only on the client and it is very slow (I know this is an outdated and incorrect assumption).

    I'd argue that this is quite efficient. You leverage the processing power of all clients to do tasks that previously the server had to do. That way it is much easier to scale out. I completely agree that it is bad shipping out nearly 1MB of code just for a simple site, but once we are talking about actual applications, some images are worse than that. So the inefficiency of sending data over the network is - at least in my opinion - out weighed in application contexts by leveraging distributed computing power that puts less stress on the servers.

    Security remains a huge concern, but beware not to fall in the security-by-obscurity pit. Meteor still enforces security policies on the server. It may give you the code to manipulate data, but the actual security layer sits on top of the data. Now when you are Google you probably do not want to send out the code that includes algorithms to document how to determine Page Rank, but in those cases you do not have to send out the entire application to the client.

    API keys, secret algorithms, authorization models - these can all be kept on the server still.

    Also about JavaScript being slow, this is both still accurate and outdated- It's not the fastest language and parsing huge DOM trees is far from efficient (there it is again), but a lot is compensated by scaling server tasks out to clients. If you look at requests over the net, processing times are considerably fast. If there is less data to be sent over the wire (no HTML markup for example) this again compensates for possible slowness on the client. But after all, thanks to Google Chrome and Safari and their battle for quicker JavaScript benchmarks the game has changed significantly in the last 20 months alone.
    You must change the code inside the JavaScript function to use .datepicker and not #datepicker

    Isaac Ferguson wrote:

    I added a datePicker using jQuery at the bottom of the page. If I use one it works but when I use two only the one which is at the first place in the form shows a pop up for pick a date, the other one just doesnt show it.

    IDs for HTML elements must be unique. First of all, if you add two datepickers, make sure they have two different IDs. Also, you are initializing the datepicker based on the ID, which gets messy if you keep using the ID. A better approach is to initialize the datepicker based on a class if you have multiple elements on the same page.

    Using a class for the datepicker makes your code look like this:
    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).