Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More
Socket
Sign inDemoInstall
Socket

serverbricks

Package Overview
Dependencies
Maintainers
1
Versions
12
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

serverbricks

Pluggable Node.js server framework based on express to jumpstart server development

  • 2.5.0
  • latest
  • Source
  • npm
  • Socket score

Version published
Weekly downloads
1
Maintainers
1
Weekly downloads
 
Created
Source

Build Status

Serverbricks

Serverbricks is a pluggable Node.js server framework based on express to jumpstart server development. It offers various bricks that accomplish commonly needed tasks - e.g. define routes or bundle code with browserify.

To keep the project structured and clean even for bigger codebases, the code is separated into modules. All modules have similar structure, for instance, bundling code with browserify is done by looking into the /client subfolder of each module. Thus, separate parts of your app can be separated by code, but still use the same features offered by bricks.

Example

Let's imagine building a webshop (based on angular or your preferred frontend framework) with some static landing/imprint/.. pages. For better structure, we separate the angular app and the static pages and create two modules:

- src
   |- server.coffee
   |- modules
       |- staticPages
           |- public
           |   |- ...
           |- routes
           |   |- staticRoutes.coffe
           |- views
           |   |- landingpage.jade
       |- webshopWithAngular
           |- public
               |- ...
           |- routes
               |- productAPI.coffee
           |- views
               |- productInfoPartial.jade
               |- ...
           |- client
               |- productController.coffee

Now, we use serverBricks to get everything working:

# In server.coffee

serverBricks = new ServerBricks({
  expressApp: webapp # the object returned by express()
  log: log # winston works well, if nothing is defined, console is used
  modulePath: './src/modules' # where are our modules?
})

# Now, it's time to add functionality

# first, we want to serve static assets in all /public folders
serverBricks.addBrick 'staticAssets'

# then, let each module define its routes in /routes
serverBricks.addBrick 'routes'

# Use pug (formerly jade) to compile templates in /views
serverBricks.addBrick 'viewFolders'

# And use browserify to bundle all code in /client folder
serverBricks.addBrick 'browserifyCode'

startPromise = serverBricks.initialize()

Available bricks

You are not restricted to use the built-in bricks. addBrick also supports receiving an brick instance, which needs to offer the methods specified in Brick.coffee.

< ToDo: link each brick with detailed codo documentation >

  • browserifyCode bundles code with browserify and serves it to clients as client.js.
  • mongoose initializes a connection to mongodb and looks for mongoose models in /db/models
  • routes lets each module define routes in /routes
  • sass transforms sass/scss to css in /public/styles. Important: use this brick before the staticAssets bricks or stylesheet recompilation won't work.
  • staticAssets serves everything in /public as static files.
  • viewFolders configures express to use pug jade as a view engine and allows to use pug/jade templates stored in /views

Brick configuration

Each brick can be configured by supplying a config object: serverBricks.addBrick 'Name', config

You can specify callbacks to be executed (e.g. do something after mongodb/mongoose has been initialized or before routes are initialized) when adding the brick: serverBricks.addBrick 'Name', config, preInitCallback, postInitCallback. Callbacks may return a Promise.

sass:

  • urlPrefix defines the url prefix where stylesheets are served. Defaults to /styles, so a stylesheet named screen.sass will be available as /styles/screen.css.
  • styleSubfolder defines the subfolder in each module where stylesheets are searched. Defaults to public/styles

viewFolders:

  • useViewCache defines whether view caching is used. Defaults to true.
  • additionalViewFolders defines individual folders (array of strings) that are used as view folders as well

mongoose

  • host defines the mongoDB hostname, defaults to localhost.
  • port defines the mongoDB port, defaults to 27017.
  • db defines the mongoDB database name, defaults to default-db.
  • modelSubpath defines the subfolder of each module where models are loaded. Defaults to db/models.
  • mongoose defines the mongoose module-instance to be used. Defaults to the mongoose module as specified in package.json. If you use multiple plugins that require mongoose, it's probably best to specify and require mongoose in your application's package.json and then hand this instance down to plugins (including serverbricks) in order to prevent strange bugs resulting out of different required versions.

browserify

  • additionalTransfomrs defines an array of transforms to be applied as well (next to coffeeify which is always active)
  • externalModules / externalBundleName defines what modules are external (array) and how the bundle is to be named (default : shared.js)
  • developmentMode defines whether to apply production settings or not. Defaults to true.
  • bundleName defines how to name the code bundle, defaults to client.js

** staticAssets **

  • moduleAssetPaths defines subfolders of modules whose content should be served statically. Per default, it is set to ['public'], serving all files in <module>/public under the root URL /. Instead of specifying a string path, you can also use an object { urlRoot: '/moduleAssets', path: 'assets' } to control the resulting URL.
  • staticNodeModulesPaths same as above, but specifies what node modules should be served statically, e.g. ['font-awesome'].

Development

Although the ideas and most of the code of ServerBricks is used in multiple production apps, the module itself is fairly new and still needs some work and polishing - feel free to file issues and create pull requests.

Development ist done in Coffeescript, with grunt as a build system. Please see the gruntfile for more details.

Keywords

FAQs

Package last updated on 13 Oct 2016

Did you know?

Socket

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Install

Related posts

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap
  • Changelog

Packages

npm

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc