MEAN.JS OFFICIAL BLOG

First of all, thank you for all of your feedback so far. We appreciate each and every one of your contributions to this project - you’ve all made this a better project for all of us, so thank you.

In this release, we’ve made some major changes so that it would be easier for everyone involved to contribute even more. We want to make sure sure we don’t inflate the size of project, or conversely making it overly specific,  so we tried to further modularize the various components, making sure the modules are nicely decoupled from core application architecture.

We have added features such as Socket.io support, as well as Gulp, Sass and Less support - all of which would allow more choice when setting up the application. Clearly, there’s little to no need to use both LESS and Sass, or Gulp and Grunt in tandem. For that end, we would like to make use of the generator, and enable the choice as part of the application development workflow.

Since this release introduces some breaking changes, we are currently releasing the branch but not merging it yet. We’d love to hear your input and feedback to the changes we’ve made. There’s still work to be done with writing documentation and completing the generator reflection for these new features, and we hope you’ll take part in our shared effort. We think we should make sure that we have a clear migration process to 0.4 before it is merged with the stable release branch.

We believe these changes will help all of us work together more efficiently, and hopefully make the process of creating full stack Javascript applications even more enjoyable and simple for all of us.

We invite everyone to comment, ask questions and most importantly - submit pull requests! 

Relates to https://trello.com/c/vgwdGuNB/38-modularize-core

Vertical modules

We have significantly changed the folder structure. Previously, a single module’s client and server code were spread over two different folders (app and public) - they now are unified under a unified `modules` library. We currently have a `core` module, as well as a `users` module and an example module (articles).

The server-side application level files were reorganized as well. The `express.js` file has been modularized extensively, to ensure readability and easy replacement or extension of the different middleware components.

Gulp
You can now choose to build your project with Gulp. The Gulp file mirrors the same task that exist in the current Gruntfile. It’s a bit easier to write tasks in Gulp - but since we don’t want to force anyone to use Gulp, this feature will be added to the generator as an option alongside Grunt.

Socket.io
Relates to  https://trello.com/c/mamXakKT/54-socket-support

On the client side, we added an Angular service called `Socket`, which manages the socket connection authentication, as well as wrapping the native socket `on`, `emit` and `removeListener` methods. We added an example for implementing stacks relying on Socket.io, under “Chat”.

On the server side, `socket.io.js` includes the setup required for socket.io to work with cookies, and it connects the Passport middleware as well.
The additional files found under `modules/chat` are an example for a Socket.io implementation.

ACL
Relates to https://trello.com/c/qb5hQRil/39-modularize-authentication-authorization

We added easy way to manage ACL on the module level. Each module includes a “.policy” file, which allows granular management of permissions according to predefined rolls.
Notice ACL policies are currently managed in memory, but they could be managed in MongoDB or other similar stores as well.

Revamped menus service
Relates to https://github.com/meanjs/mean/issues/58

The menus service has been simplified, and now uses the state oriented menu items. They are configured in each module’s client configuration file (e.g., articles.client.config.js)

Html5mode
HTML5mode is now enabled by default, and is fully supported thanks to the migration of the module API endpoints to /api.

Routing with UI-Router stateProvider  - revamped, now using ui-sref across the project (instead of ng-href).

We’ve added E2E testing with Protractor. We created some example e2e tests for articles and users modules, but surely more will be written.

End to End testing with Protractor
We’ve added E2E testing with Protractor. We created some example e2e tests for articles and users modules, but surely more will be written.

User management + profile image support
We introduced a new social connections management page, which allows users to manage their existing social connections to the app. We have also updated the Password retrieval component.

Sass/LESS support
Added support for both build process in both the Gulp and Grunt build processes.

TTL bug fixed
mongoose.js -  application starts after connection is established,
This closes https://github.com/meanjs/mean/issues/224
Gruntfile.js - asset consolidation
Express.js - Simplified and modularized
Config/assets - asset consolidation
Strategies folder is removed, ACL is managed on a module basis

Not yet in the version:

• i18n support - adding this feature seems to introduce a lot of complexity to the project. For the time being, it is not being actively worked on.

• Still in development - Updated documentation for 0.4 - PRs welcome!

• Still in development - Updated generators for 0.4. - PRs welcome!

• Security in mind - supporting form tokens for CSRF, X-Frame-Options header support, etc.

• Controller/Model hooks - this is a concept from sails.js which allows you to implement methods like beforeCreate, beforeValidate on models (they use Waterline ORM, kind of a mongoose framework).

• Angular 1.3 - After updating to Angular 1.3, some Karma tests break. We are currently investigating this issue, and once those bugs are fixed the 0.4 branch will be updated to use the new Angular version. 

Until next time, 
The MeanJS Team

We had several important changes in this release. Our efforts focus on modularizing the components of the stack as much as possible, and make the project easier to maintain and scale. Here are some of the key points we addressed in this release:

Simplifying asset management:

• We moved assets management to the environmental configurations files(e.g., all.js, production.js, development.js, etc.).

• We introduced the new build task to minify your project assets before deploying it to a production environment.

• We simplified the loading process by using glob patterns instead of walk functions. That makes it easier to read and include folders and subfolders.

New folder structure:

• We simplified the AngularJS application structure.

• New file extensions(e.g., server.controller.js, client.service.js, etc.) to defer different module files and avoid redundant file names.

New usability features

• Added roles to the User model - the defaults are ‘user’ and ‘admin’, you can add and remove them as needed.

• We introduced new ‘Menus’ service, that makes managing your menus a walk in the park. This service basically manages menu authorization process and move item management to each module.

Automation

• We added CSS Linting, Minification and Uglification tasks, wrapped in the grunt build task for production support.

New Express version

• We updated Express version to 4.1.1.

Generator

• Fixed some generator bugs.

• Modified generator to work with new structure and file names

• Entities creation is now easier due to Module selection.

• CRUD module generator now supports menu items.

Until next time!

The MEAN.js team

We’re super excited to announce our official Yeoman generator.

One of the most frequently asked features from MEAN users is a way to scaffold their applications. As we looked for a way to help the community build and deploy production level MEAN applications, we decided to go with a Yeoman generator. Yeoman generators provides a powerful, easy to maintain, and open solution for scaffolding applications.

So, we set out to work on the features we thought every developer needs, and we are proud to present the official MEAN.JS Yeoman generator. It includes a set of simple tools you can use to make your MEAN application development easier and way more fun.

You can use it to quickly and easily generate the various components of your stack. As with other generators, using a consistent method for evolving your application helps by making it easy to understand one consistent structure. When we develop full stack applications, it’s super helpful to be able to quickly generate and tie in the different components, instead of manually retyping repetitive code.  

The Mean Yeoman generator includes 16 sub-generators, so you can choose which parts you want to generate, and which parts you want to write manually. We added documentation for the generator and sub-generators, so it’s super easy to get started.

We hope it helps you with maintaining a more cohesive codebase, and that it lets get your application built super fast. We would love to see your forks and feedback! Let us know how you use Yeoman with Mean - and what we could do to make it easier and faster.

We want to thank all of you for your awesome support - this makes this incredibly fun.  

Introducing MEAN-SEO: A Free, Self hosted, Express.js plugin for SPAs (but mostly for MEAN apps)

One of the biggest issues many devs who build SPAs often hit is the need to make sure their app is crawler-friendly. Since we started doing more and more complex things on the client, using frameworks like Angular.js, a large amount of the content we render on the page is rendered by our Javascript application. That causes an inherent flaw to many JS heavy frameworks. 

As part of evolving the MEAN stack towards a production ready state, the MEAN-SEO module makes it pretty simple to make sure your MEAN application ready to serve all of your precious content to those hungry crawlers, without breaking a sweat. 

Quick Start

First, install:

Then:

And you’ll be good to go. 

Overview

MEAN-SEO is an Express.js middleware, and it intercepts requests that include an escaped fragment reference in the URL. We include a special meta tag that tells the crawler to query our Angular pages again, using the escaped fragment reference. 

MEAN-SEO then launches a Phantom.js headless-browser, which then fetches the same page, but makes sure to wait for a while, before serving the fully rendered page back to the server.

This allows the crawler to get  our content after our Angular app is fully loaded, and the search engine could then index the page content, even if it requires resolving AJAX requests etc. 

Caching

The MEAN-SEO would save pages onto the disk by default for two days. You can choose the duration for the cache to be saved by passing a “cacheDuration” property, with a value in milliseconds. 

In addition, the plugin caches the page for the duration you define, either by saving the pages either to the disk or to a Redis instance (requires installing Redis). 

Setup

MEAN-SEO is super easy to set up. To install, run: 

Next, we’ll create the middleware function, typically close to where we declare other middlewares, such as Passport etc, and wire it to our app:

Make sure you include the following meta tag in the  <head> of any page you use Angular (or Ember or any other AJAX-dependant content):

<meta name=”fragment” content=”!”>

Digging in

If you take a quick look at what the module does, you’ll see how extremely simple it is. When crawlers from search engines like Google and Bing come around, they identify your SPA by hitting the fragment we just mentioned. When they do, they request the same page again, this time converting any url fragment (anything following the # or “hashbangs”), so that:

http://localhost:3000/#!/articles

to 

http://localhost:3000/?_escaped_fragment_=/articles

So, every time a request comes in through your Express app, the middleware looks at the request to see if it includes an “_escaped_fragment_” parameter. If it does, that means a crawler came by, and MEAN-SEO kicks into action: We make sure the page requested isn’t already in the cache, and in case it is, we serve the crawler that cached result. 

If a page was never crawled before — or if the cache was invalidated —  a Phantom.js client simply fetches the page, ensuring it is entirely loaded before serving the results back to the crawler.

Why are we doing this?

Simply put, we are trying to make sure MEAN.JS is as production ready as it can be. We saw the challenge of search engine optimization to be one of the most common and yet complicated to solve. By adding MEAN-SEO to the MEAN.JS stack, we make it easier for you to enjoy the benefits of working with awesome SPA frameworks like Angular.js, without worrying about any external limitations. 

What’s next?

MEAN-SEO will add some other needed SEO-related features, like building site maps, making sure your meta tags are up to snuff, and others. We hope you join us by contributing code, and adding to the feature list on our Trello board.

Until next time!

The MEAN.js team

Prologue

I’ve been working as a freelance developer for almost two years now. During that time, I got to work with full-stack JavaScript solutions involving MongoDB, Node.js and AngularJS. About a year ago I noticed a recurring pattern while creating new web applications, and I realized that the last three web applications I’ve worked on are all using the same technologies: MongoDB as the Database, Node.js & Express as the backend framework, and AngularJS as the front-end framework. I started building a boilerplate to help me jumpstart these kind of projects, and was wondering if anyone else was noticing the same pattern. A quick googling discovered a mongodb blog post by Valeri Karpov suggesting the name MEAN. As far as I can tell this is the first time anybody mentioned the MEAN stack by its name.

About 10 months ago I received a new project from a company named Linnovate. The project was a messed up variant of MEAN that Linnovate had inherited from another company. They had asked me if I could try and organize it. Luckily, I already had my boilerplate ready, so I showed it to them, and together we decided to open-source it. Not too long after, the community started to react to the boilerplate. A post on hacker news got us the first traction, then some people started tweeting about it, and soon enough, blog posts were written about the different aspects of the stack. MEAN began gaining momentum.

Meanwhile on Github, I had one of the best experiences of my professional career. As project maintainer I discovered the real power of open-source. A community of vigorous developers that helped me learn many new things I wouldn’t be able to learn anywhere else: From niche pitfalls to big version changes, through project management and community etiquette, all of which with passion for better coding. I became more and more involved, checking my emails more frequently than ever, constantly tweaking with the issues page, testing pull requests branches and more, until it had grown to fill the better part of my daily routine.  

Conflict

Everything was going smoothly up until the end of last year. The deal was that I will be the chief maintainer of the project while Linnovate will sponsor some of my time. That was a great deal, because it allowed Linnovate to help the community without hurting its core business, and for me to stay independent while keeping the project well maintained. The only problem is that companies and freelance developers obviously have different agendas. So, towards the end of last year, this shift in preferences put our collaboration in a crossroad. 

In almost any other professional field this could easily become a serious legal problem, generally extremely counterproductive to the interests of both sides. Luckily in our open-source community, there is a more elegant solution, forking out of the conflict. So about a month ago, I left MEAN.IO to form a new project named MEAN.JS. I called my friend and colleague Roie Cohen who was also the first MEAN contributor and together we got to work.

Denouement

When we approached the development of MEAN.JS we had a major design goal in mind: Evolving MEAN.JS from an hackathon boilerplate to a real production framework. In other words - we wanted to help convince your PM that its time to leave PHP. Since each of the MEAN components is production-ready, the problem remains to properly combine them together, and with this in mind, we attacked a few problems:

Modularity

In order for MEAN.JS to become better we needed to break it into different clear modules, each supporting a main core feature. We also needed to rearrange the project in a way that allows the creation of new logical modules. So, we changed the project structure a bit to support this new approach, some files were split, some consolidated, but in the end we did two major things:

1. We changed the backend structure to support MVC modules.

2. We restructured the AngularJS part to support vertical modules.

We also added some autoloading of modules features to ease the development process. Better modularity by itself is great, but it also helped us solve another major issue with the original MEAN, legacy support.

Legacy Support

One of the problems of the original MEAN stack was its poor legacy support. The project changed constantly with no version scheme marking the different versions. Many features were added or removed without the proper notice, people had problems updating their project, and it was generally time to put down some rules. So we borrowed from other frameworks we liked:

1. Version Numbers - Like other frameworks the version number will be broken to odd and even numbers, where even version numbers indicate stable releases.

2. Branching - Instead of merging changes directly to the master branch, we’ll use tags and branches in order to properly mark the different changes and patches.

3. Modularity - Breaking the project into more pieces gave us the ability to commit bug patches more easily.

Our desire to support a larger audience, while still include the original MEAN community, led us to deal with the next major complaint of MEAN users, Documentation.

Documentation

Maybe the most common request of our community, a proper documentation is a must-have for any respectable project. We approached this by creating a new website for the stack that includes a basic documentation of how the boilerplate is built, what are the major dependencies and how to configure them, how the MEAN.JS design works, and how to get started with the development of your new application. You can visit the documentation page to find out more, but if you still have questions, you can now directly ask the community.

Community

The last piece of the puzzle was how to offer better support to MEAN developers. After trying few experimental tools, we decided it would be better to use the already established communication channels. We have new twitter account and a facebook page for news updates and other discussions, the MEAN.JS google group for technical support, and the #meanjs IRC channel for real-time support. So please contact us if you have any further questions.

The Future

Regarding the future development, we decided on concentrating our efforts in four areas:

1. Core - Improving the MEAN core and fixing bugs.

2. Modules - Building companion modules to extend MEAN with different web application features.

3. Generator - We already started building the long awaited yeoman generator, which we plan to release in the next couple of weeks.

4. Admin - Creating an admin panel for managing your MEAN application.

Epilogue

Leaving the original MEAN.IO project was one of hardest turning points of my career, but sometimes you have to take a risk in favour of the values you believe in. Having said that, it has set us free to develop MEAN the way we want it to be. Today we present to you the first version of MEAN.JS and asking you to join us on this new journey.

Amos Haviv

MEAN Author.

* Please feel free to ask me anything, I will do my best to provide you with solid facts and honest opinion.