Stability: 1 - Experimental
Humpback was born out of necessity. We fell in love with sails.js, Angular.js, and Zurb Foundation and we knew right away that we wanted to build an intuitive platform to use these frameworks in large production level applications at blistering development speeds. The first attempts at Humpback were behind closed doors and intended to be proprietary. Then, after many many debates, we decided to OS an entire rebuild of Humpback using node-machines, possibly treeline, JSdata, Foundation-apps, and all the wonderful new projects that have come out recently. We are building the platform publicly so there is as much external input as possible and will launch contributor guidelines when they are ready.
This README.md file will be updated as this project evolves. Also, check out the WIKI.
This product is currently NOT PRODUCTION ready.
Humpback is to the frontend what treeline is to the backend of a sails.js app. We've concretely decided to use Foundation-apps as the frontend framework and JSdata as the client side persistence layer. Both of these are forward thinking technologies, and we are focusing on Humpback as a Single Page Application (SPA) builder not a website generator. It's also a fast track for your next hackathon with things like auto linking views/scss/controllers/modules etc.
For now, there is no complete CLI or node module, so to get started with humpback
you can use the standard sails.js way. First you will need to have node.js/NPM,
sails.js, Ruby, Sass, and PhantomJs installed.
NOTE: PhantomJs works best if installed globally
npm install phantomjs -g
Then, Fork this repo
$ npm install$ sails lift
There is plethra of awesome technologies being used in Humpback. If you consider using Humpback for production, you and your team should have an understanding of the following:
Additional things that will come in handy
Methodologies to keep in mind
One of the most repetitive tasks that we do with every sails project is
Role based authorization, Content Management, Email Management, and GUI Data Management.
So with Humpback, we built that in natively. We did it for two reasons 1) we do it for 99% of the sails.js projects we create anyways 2) It's a great working example of how the humpback frontend and backend work together. It's not a sails.js version of wordpress or anything like that, just a great time saving way to see all the working pieces.
By default a single super user is created:
username : adminpassword : admin123
This user can Create Read Update Delete (CRUD) anything built on Humpback and is the only source to add additional Admin users in.
NOTE: you'll want to change the super user's password before production
Humpback uses sails.js's native sails.socket.io combined with JSdata and a
custom provider for storage of client side models. By default, humpback
client side models communicate with the the REST routes via the prefix
and pluralize turned to false.
Humpback's file structure is identical to a normal Sails.js app with a few exceptions.
Humpback generators create additional files compared to their sails.js counterparts.
Humpback uses SASS in lieu of less (to support foundation-apps).
Humpback includes a humans.txt.
Humpback includes an app folder for angular controllers and models.
config/env/test.js environment file for testing.
Humpback includes a test folder for unit testing.
Humpback includes a
Humpback removes the
assets/images folder to be more consitent with the app file structure.
Humpback removes the
assets/styles folder to be more consitent with the app file structure.
Humpback has a semantic layout for the
assets/app folder (where all of the fronted files are stored).
It uses the humpback generators and
sails-linker to automatically and semantically bind all of your
it minifies all of it together into a single production.js file.
NOTE: You will still want to create all of your view files in .ejs in the
views folder so that they can be compiled into the
assets/app/views folder with grunt-ejs and html2js.
Humpback overrides as few system defaults as possible, but there are some things that are changed for this particular SPA concept.
Humpback reserves certain model names. While you are free to extend the models you should not attempt to create models with these name spaces:
If you absolutely must use different model names, you can set replacements in the
config/humpback.js file. You'll need to update the
files as well. See
humpback-hook for more details.
If you are using sails-stripe, you should consider not using those model names as well.
Humpback reserves certain controller names. While you are free to extend the controllers you shound not attempt to create controllers with these name spaces
Humpback makes use of installable hooks, we call them barnacles. By default the included barnicles are:
humpback-hookresponsible for authorization logic, includes passport
humpback-validation-hookresponsible for creating model validation errors in i18n
humpback-admin-hookresponsible for creating a lightweight and customizable admin area
humpback-cms-hookresponsible for creating an extenable lightweight content management system.
humpback-gui-hookresponsible for creating the admin data GUI
humpback-email-hookresponsible for creating email templates
Humpback's generators override sails stock generators to create additional files:
sails generate humpback-api <API_NAME>
sails generate humpback-model <MODEL_NAME>
sails generate humpback-controller <CONTROLLER_NAME>
sails generate humpback-view <VIEW_NAME [FEAUTRE/MODULE]>
Humpback also has a few custom generators that make development faster and will also work with the future release of humpback.io
Humpback comes bootstrapped with sails-stripe to make humpback apps SaaS friendly and stripe ready. See this link for setup.
sails generate sails-stripe
Humpback includes custom validation transaltion for i18n as well as uses i18n to translate the app into the desired language.
Humpback's default frontend is Zurb's Foundation-apps. Humpback exentends a few of foundation-apps' modules functionality but supports them all. Since we are using sails as the view router, you will want to avoid using foundation-apps built in router fuctionality or any of it's funcationality that relies on gulp.
Iconic and Open Iconic allow for responsive and stylized SVGs to be used
across the frontend. Humpback uses grunt-svg-toolkit to optimize svgs.
For more information on great ways to create SVGs for humpback, see Iconic's illustrator-svg-exporter and grunt-svg-toolkit
We included a dependency on PhantomJs. This dependency is to support certain
levels of image manipulation as well screenshot creation. For best restults
PhantomJs should be installed globally.
npm install phantomjs -g
CONTRIBUTORS.md or click here
Add initial View generator and semantic layout of module names and file includes.