Category: Sails (page 1 of 2)

Sails hook wetland ORM released

Today is a special day. Well, to us anyway. In our previous post, we announced the release of Wetland ORM. This post brings wetland to your project.

We’re happy to announce the release of sails-hook-wetland, a sails.js hook bringing the power of Wetland to projects near you!

Features

  • All default sails blueprints.
  • Nested populates.
  • Migrations.
  • Runs side-by-side with waterline.
  • Unit of work (transactions).
  • Dirty checking (optimized).
  • Lower memory footprint.
  • Performance.
  • And the rest of the wetland features.

Getting started

To make it easy for you to get started, we’ve written an extensive README, and built an example application. The example application demonstrates the use of entities, repositories and use of custom actions.

This is simply a sails application, bundled with our authorization hook. You can run it as such.

Happy coding!

Updates, changes and new aurelia plugins

Hello coders,

Today we’re releasing a stable version for almost all of our aurelia plugins, a couple new plugins and a preview-version of our new Node.js ORM wetland.

General changes

First we’ll be talking about general changes in our community. It has been growing, so we had to make a couple of changes.

Organisational changes

We’ve hired @doktordirk as our community manager. He’s responsible for answering issues, reviewing pull requests, answering questions on Gitter. A big, and finally public welcome to Dirk!

We’ve also assigned plugin owners to make sure that plugins keep moving forward. This has proven itself very useful and the plugins now have their own roadmaps (more on that later). @RWOverdijk as the lead developer is now focussed on the architecture and development of consistency.

Release schedule

We’ll no longer work with release candidates for as long as we have. The next versions will follow semver, and due to our new testing environment be rolled out a lot more frequent.

Big updates

The following is a summary of changes made to existing libraries.

api

  • Migration to npm and name changed spoonx/aurelia-api -> aurelia-api
  • Allow multipart/form-data and x-ww-form-urlencoded
  • Add findOne, updateOne,.. methods to allow for path/id?filter=some
  • Package for esNext/typescript , jspm/webpack/aurelia-cli

authentication

  • Migration to npm and name changed spoonx/aurelia-authentication-> aurelia-authentication
  • Package for esNext/typescript , jspm/webpack/aurelia-cli
  • Completely refactored for consistency. many parameters renamed. getter/setter for the old names ensure BC
  • AuthService.authenticated status automatically updated according to token ttl. including across tabs and optional auto logout page reload/redirect
  • Binding signal ‘authentication-change’
  • EventAggregator publishes ‘authentication-change’ with authenticated status data
  • Optional function can be set to customize data extraction from non-jwt
  • Refresh_token with optional auto-refresh
  • Auth0 support using auth0-lock
  • OIDC logout support
  • Updated provider defaults

orm

  • Migration to npm and name changed spoonx/aurelia-orm-> aurelia-orm
  • Package for esNext/typescript , jspm/webpack/aurelia-cli
  • Association-select component much more customizable (translation, placeholder …)
  • Paged component added
  • Add generic metadata with the data decorator
  • Set an entities id property name with the idProperty decorator
  • Entity: Save new children and mark as dirty when children added or removed. (https://github.com/SpoonX/aurelia-orm/commit/37f6b515)
  • Added entity.reset(shallow)
  • Entity: setData with optional markClean (https://github.com/SpoonX/aurelia-orm/commit/ee01480)
  • Validation: upgrade to aurelia-validation 0.12+

notification

  • Migration to npm and name changed spoonx/aurelia-notification-> aurelia-notification
  • Updated to new aurelia-i18n. BREAKING CHANGE: Cannot be used without aurelia-i18n anymore
  • Package for esNext/typescript , jspm/webpack/aurelia-cli

all plugins

  • Added gitbooks (https://plugin_name.spoonx.org/ e.g. https://aurelia-orm.spoonx.org)
  • All plugins are published on npm
  • Adding basic d.ts files for typescript users (typescript 2 install ready)
  • Made the plugins @easyWebpack ready
  • Added bundle instructions of jspm and aurelia-cli

New stuff

We’ve also been working on some new stuff! The author of each plugin wrote a little piece on it.

swan-example

By @doktordirk and @RWOverdijk.

We needed a place to demo our plugins, and so we created swan-example.

SWAN is a nifty little stack, which stands for Sails Waterline Aurelia and Node. It comes with a cli tool, which isn’t much yet, but does help you define a project structure and get started quickly using our opinionated aurelia-skeleton and auth-ready node server. We’ve used this tool to build the swan-example, which you can see by clicking here.

  • Username: example
  • Password: example

Github

aurelia-view-manager

By @bas080.

Components often require some HTML. We at SpoonX tend to use bootstrap for styling and templating. But we also want to make it easy for people that might use other CSS frameworks. Aurelia-view-manager allows you to easily overwrite the HTML template of components that use aurelia-view-manager’s @resolvedView decorator. If you want to make your component CSS framework independent, head over to the usage section.

Github | Docs

aurelia-form

By @bas080.

Aurelia form makes your life easier by letting you define and generate forms based on data. It does so by using something named a schema.

A schema is a collection of objects that describes the form you want. The schema consists out of basic javascript data types which every programmer understands and knows how to manipulate. A simple example:

You can then use this schema and the object that holds the data like this:

<schema-form schema.bind="schema" model.bind="credentials"></schema-form>

This plugin is especially useful when combined with aurelia-orm, as it generates the form based on your entity schema using the custom component <entity-form />.

Github | Docs

aurelia-pager

By @VMBindraban.

Pager is a component that handles pagination for your application.

Beside the basic functionality of a paginator like setting amount of items for each page, it also supports:

  • Data from an array
  • Data from a resource (using aurelia-orm)
  • Criteria (using a resource with sailsjs/waterline or express)
  • Page range, for example 3 4 [5] 6 7
  • Your own custom template (defaults to bootstrap)

Github

aurelia-filter

By @VMBindraban.

Aurelia-filter is an basic GUI criteria selector, it generates a search/filter criteria object. You can easily generate criteria based on AND or OR conditional blocks. Based on the field you have selected, it can transform the input field into the proper type, for example a number or date. It supports all the sailsJS/waterline operators. There is also support for entities (using aurelia-orm).

Github

aurelia-datatable

By @jeremyvergnas.

Datatable is probably one the most common components you can find within interactive applications. It allows you to have an overview of your data and manipulate them, in a user-friendly manner.

Aurelia-datatable has been made to provide you an easy and powerful way to implement datatables in your Aurelia application(s). In combination with aurelia-orm, aurelia-view-manager and aurelia-pager, you will get, out of the box, a datatable component ready to use, with the following features:

  • Custom columns (with aliases and value converter)
  • Sorting
  • Searching
  • Pagination
  • Custom criteria
  • Optional edit/remove actions on your rows
  • Custom actions on your rows
  • Custom footer on your datatable

Github | Docs

aurelia-config

By @doktordirk.

With the increasing number of plugins, plugin initialization and configuration has become somewhat tedious. Currently, one might have something like this, a long list of plugins and their configs:

Using aurelia-config, that becomes easier and more organized. We have just have a single namespaced config object with all the configuration options and aurelia-config does all those plugin calls for us witch the appropriate namespace section. Here’s a simple example:

That’s the main feature of aurelia-config, but there’s more to it.

  • initialize and configure you plugins in one place with a single namespaced configuration object.
  • automatically load and merge defaults which can be directly loaded from plugins by aurelia-config itself.
  • access the merged config by using our resolver or injecting aurelia-config everywhere.
  • since the merged setting are an instance of homefront, all it’s method are available, too.

Homefront

By @Rawphs.

Homefront is a module that allows you to merge, flatten, expand, search in, fetch from, remove from, put in and work with objects easily. It was started as an educational project but has made its way into wetland, aurelia-config and json-statham. It is fully tested, and makes working with objects a lot more fun.

Github

aurelia-charts

By @bas080.

Aurelia-charts is a plugin that allows you to use the chart library you like most. It has a simple api and standardizes the way charts are used in your projects. It does so by letting others define sane defaults.

It allows for you to write your own plugins, or use an existing one (for example aurelia-charts-c3).

This project is being used by us, but isn’t labeled “stable” yet, as is visible by the lack of documentation.

Github

Bonus: Wetland

By @RWOverdijk.

For the past two months we’ve been working on a brand new nodeJS orm. For now it lacks documentation, but has neat features. It’s based on the JPA spec (which took some reading) and took inspiration from the way doctrine implemented it. It obviously required some changes to fit the node.js world, but those were kept to a minimum.

A glossary of its features to date:

  • Abstracted principles (repositories, entities, hydrators)
  • Unit of work using proxies
  • Nested joins
  • Nested persist
  • Mapping
  • Transactions
  • Migrations
  • Great performance (smart hydrator and state management)
  • Strict typing (written in typescript)

Feel free to browse the code, and if you’re interested leave a star so you can track the progress.

Github

Conclusion

We’re very happy with the work we’ve done. The plugins are stable and the documentation is clear.

  • If you have questions, suggestions or a need for banter, feel free to join us on gitter.
  • If you like our work, help us out and star our repositories.

Happy coding!

Q&A: Schema attribute sails.js models

Question

What is the schema attributes inside models in sails

Answer

The schema attribute defines whether or not to enforce the schema.

Come again?

Relational databases tend to have a predefined schema (including what type can be stored, what the name of the column is etcetera). Whatever you insert, fetch or update has to adhere to that schema. Mongo, redis etc don’t have that. You can just insert whatever makes you happy. By setting schema to true, you’re forcing waterline to apply the same rules to schema-less adapters.

javascript dependency management

Hello fellow geek,

A while back, I wrote an article about javascript dependency management, explaining my discomfort with most options out there. I tried filling the void with something meaningful by creating useuses; a gulp plugin that adds zero extra bytes to your combined files but does add meaning to your individual files.

I came to realise, that this plugin was flawed in a couple of ways, so naturally I’ve fixed those flaws. And thus I stand here today to proudly present a new module that takes a different approach but still uses the same solution.

@uses

But before I do, I’d like to explain what @uses is supposed to mean, why I think it’s better and how it should be applied.

What’s @uses?

@uses is an annotation I’ve been using for a while now. It allows me to keep track of what dependencies my files have easily.

How do I use it?

Here’s what it looks like:

As you can see, it unobtrusively informs the developer about the dependencies being used by this particular file. So using it is really simple: just maintain the dependencies of your file in the annotations, and you’re already doing it.

So, why is it better?

The arguments I’ve presented in my previous blog post still stand. In summary:

  • It doesn’t add extra bytes
  • It doesn’t force a dependency upon you
  • It doesn’t use weird tags, or magic. Just an annotation.
  • I adds value to your files.

Improvements

Like I mentioned earlier, I made quite some improvements to the module. Here are the biggest ones.

It’s not a grunt plugin anymore

The biggest flaw was that it forced you to use gulp. There was no standalone version, or alternative for let’s say gulp.~ Useuses itself is now a standalone module that can be used via the CLI, or programmatically.

This means it can be used in grunt, gulp, or any environment for that matter.

It’s faster

I’ve made improvements in the file searches, sorting of dependencies and making sure there aren’t any duplicates. These improvements have made this module a lot faster.

It’s lighter

The module does its job by utilising streams now, not buffering the entire file, for every file. This means that its memory footprint is a lot smaller.

Using it

You can find the module here:

Github: https://github.com/SpoonX/useuses NPM: https://www.npmjs.org/package/useuses

Sails.js count blueprint

I’ve been in need of a count blueprint for a while now, so I decided to just go ahead and make one. IF you want to use it, feel free. Here’s the code:

Q&A: sails.js deploy app and run on port 80

Question

<sickyjim> hi all, I’m trying to run an app on port 80 instead of 1337 but when I change the port in config/env/production, the app launches but I can’t reach it from a browser :/

Answer

This could be caused by a couple of things. We’ll go through each and every one of them. If it’s still not working for you, leave a comment down below and I’ll update the list with more checks.

Port 80 < 1024

When running an application on a port < 1024, you’ll need su access. These ports are “special”, and thus protected behind sudo.

Now please don’t run your application on sudo. In stead, run it on any port > 1024, and in your firewall forward port 80 to the chosen port. For this example I’ve chosen the default port 1337.

Port in use

Something else might be using port 80. Common ones are:

  • Apache – sudo apachectl stop
  • Nginx – nginx -s stop
  • Skype – preferences > Advanced: Change Incoming connections port

If all else prevails, run the following command (for your OS) to find out what’s running on port 80:

MacOS: sudo lsof -i ':80'

Linux: netstat -tulpn | grep :80

SPI protection

It might also be SPI firewall protection blocking your application from functioning. You can read more about that here: SPI Firewall protection on router.

Q&A: Deploying your sails.js application

Question

<ebsarex> hi, I just finished developping a sailsjsapp and would like to deploy it on a dedicated server of mine, does anyone know about a guide to do so or something like this ?

Answer

Yes. The deployment guide for sails can be found here, in the docs but also here on github if you prefer that.

If you’re using a specific hosting provider such as Modulus, NodeJitsu, OpenShift or one of the many others, you can take a look here as well.

Q&A: Sails.js get model definition for enum

Question

<leolrrj> I’ve enum at my model and I want to retrieve it values… there’s a way?

Answer

Sails stores the models under sails.models. For those of you that have the models option set to true in the globals.js config, User.find() could also be written as sails.models.user.find().

Once initialised, the model becomes an object where one of its properties is definition. So in order to retrieve the model’s definition, and in this specific case, the values for the enum, you could simply use sails.models.user.definition.enumfield to retrieve the values.

Survival guide: Many websocket connections

When working with sails.js, or indeed any software that accepts websocket connections, you have to be careful you don’t start rejecting requests. It’s all about finding the perfect balance between CPU, memory and file descriptors. Unfortunately, there is no such thing as a “one size fits all” solution in this case, because it all depends on your application.

I’ll try to highlight the importance of certain aspects by providing examples with them. I’ll explain why, when and how they’re important, providing possible solutions with them as well. For this article I’ll assume you’re using sails.js, but the suggestions given in this article apply to any application. Let’s get to it.

Scaling

Scalability is something to always keep in mind. You can read more about scaling sails.js here.

Horizontal scaling

You can read about this more by reading this article. To me, this is one of the most important things to keep in mind while setting up your server architecture.

The most obvious way to make scaling possible, to me, is by using redis as the session store and pubsub adapter. That way, you’re not memory-bound and you can simply add instances and VMs, where you apply load balancing.

System scaling

This is a pretty simple thing to set up. Using PM2 you’ll be able to scale your application over multiple cores on a single machine. Sometimes, an extra core is cheaper that an extra VM. This all depends on how much memory you’ll need to add, and how much CPU power is actually being used.

Resources

It’s crucial to know exactly how much memory you need, and to keep an eye on how much you’re using. If you have a memory leak, or a sudden increase in activity your application might crash (which can obviously be recovered using forever.js) your application might crash, and we don’t want that to happen. In general, you should be careful with what you store in memory. Just as with memory, it’s also equally as important to keep an eye on your CPU power.

File descriptors

File descriptors, as taken from wikipedia:

In computer programming, a file descriptor (FD) is an abstract indicator for accessing a file.

Everything, even network connections use FDs. By default, the limits set for them are quite low making it quite probable you’ll find yourself looking at errors that only show up in your /var/log/messages log, and don’t make a whole lot of sense. Capping this limit, will cause connections to drop, communications to fail and basically ensures chaos.

Viewing the limits

There are two types of FD limits: system limits and user limits. The system limits can be viewed by running:

the user limits can be viewed by signing in as the user (su username) and running for the hard limit:

And for the soft limit:

Changing the limits

To change the system limits, run:

Open up vi /etc/sysctl.conf and add the following at the end of the file: fs.file-max = 200000.

Finally, run sysctl -p.

For the user, open the file vi /etc/security/limits.conf and add the following lines (replacing username with the username you’re using):

Save the file, and done.

The right limits

Figuring out what the right number is for your server depends on your application. If you notice you’re capping on file descriptors, with plenty of bandwidth, memory and CPU left it’s probably safe to increase the number by quite a bit.

Sails.js enable redis sockets

Socket.io allows you to use redis for sockets. Because sails.js uses socket.io, it consequently also allows you to set up redis for sockets. Enabling this behaviour is relatively easy.

To enable this, open up config/sockets.js and look up this block:

Now uncomment the options, configure the adapter and you’re done.

©SpoonX 2017