Task-based utility designed to simplify local development in Docker containers. Follows common docker-compose syntax, adding ability to define common tasks, along with built-in commands for shell access, logs, etc.
Two reasons:
1. It allows for asynchronous validation, see: http://technologyadvice.github.io/better-email-validation-wi...
2. It more cleanly supports the nature and flow of data i/o - in our use of Obey we are (almost) always following validation up with another async operation, i.e. obey.validate({}).then(...something else with the data...)
Since the models are "Just JSON" you can do a lot with them. We wrote a doc generator internally; I never thought about adding it to the lib but I will now :)
This is a (relatively) new library aimed at improving data modeling and validation in JavaScript. We're looking for (constructive) feedback on the approach of the library and areas where we can expand to make it more useful. Thanks for taking a look!
DevLab also gives you the ability to switch containers at runtime (something that would require reconfig of compose). For example, if you're testing on node:0.12 and want to see if it works in node:4 you can simply run:
'lab test -f node:4'
There's no additional overhead or cleanup, or modification of files.
Additionally, Compose required our team to be more knowledgeable about Docker which (while not a bad thing) meant it wasn't as easy for more junior dev's, or those with no Docker experience, to quickly get rolling.
DevLab allowed us to get everyone on the team using containerization and now (after a few weeks rolling on DevLab) dev's are feeling comfortable with the core concepts and know how to work with Docker when they need to get more "bare metal" with it.
While purely local development works, the problem you often face in a fast-paced development environment is differences between your local system and production. That's not only dealing with things like file paths and service versions and configuration; it's also very stateful.
With DevLab, you not only get an environment that very closely matches (or can be made to closely match) production, you also get a clean, blank-slate installation any time you run tests or any other task against your app. If you're developing locally, you're prone to database cruft, evolving configurations, pre-existing tempfiles, and other complications that can be easily avoided with the use of good development tooling.
Now extend that idea to multiple applications: chances are, your team isn't developing just one thing. You probably have multiple development concerns, and if you have an architecture like an SOA, you may have a multitude of microservices. When you update the language they're based on, be it node, go, python, or anything else, you need the ability to test and update your applications individually. You need your entire team to be using the same versions for the same applications. And more than anything, you need your potentially large team to get all these updates without collective hours of manual work to orchestrate those configurations on their own local machines.
My colleague addressed the question of DevLab vs. Compose elsewhere in this topic, but even if you don't use DevLab, I do heavily encourage virtualizing your environment to avoid these pitfalls in the way that makes the most sense for your team.