Why Namespace?
Namespace was born out of necessity. When the Namespace Labs team was getting started on a different project, we faced the typical development workflow questions again.
We wanted to jump to try out ideas for the application we wanted to build, but we were instead figuring out the latest recommendations for builds, tests, and production.
Teams don't need to be caught up in this cycle.
Namespace brings an opinionated but extensible all-in-one development and production experience to teams of all sizes.
Our approach
Namespace stands out in bundling many of the developer workflows together in a consistent way, so you don't have to. But if you want to change and extend them, you can.
- Builds are built-in: most deployment systems leave building to the user. But building correctly, with high-performance, is key to the developer experience. So we've embraced building as a first-class. Namespace's integrations support incremental, cached, multi-platform builds out of the box. But if you want to do your own builds, you can too.
- System testing is first-class: No more sprinkling mocked dependencies through your tests. We can exercise tests that bring up a whole stack of dependencies, doesn't matter how many. And serializable API boundaries (like HTTP, or gRPC) allow us to replace real servers with recorded responses, so you can achieve high performance without compromising on fidelity.
- Continuous integration and deployment is available out of the box: Most applications follow a similar model of ensuring that code builds and passes tests before production, and the push to production workflows then are drawn from a set of well defined strategies ("push-on-green", "canary pushes", etc). Namespace makes those strategies turn-key, but allows you to extend them as well.
- Production-like development is built-in: Too often we find bugs that only reveal themselves in production. This is because we trade-off on fidelity for developer experience. It makes sense, we as developers spend most of our time writing and testing code, so we want those workflows to be fast and easy to use. Namespace leans on the goal of great of developer experience, with a low compromise solution that brings production-like environments all the way to the developer.
And more!
The big difference with us is that while other platforms bring you some of these features, they live within a closed world -- they provide a fixed set of features.
We believe in ecosystems and extensibility. So we designed Namespace to be extensible. Most workflows have well-defined user-extensible integration points, and most of the code that the platform invokes can be provided by users.
That means that while we provide a set of opinionated blueprints, making it easy to get started, you're always free to extend or replace them to fit your own needs.
History
We knew that when we were building our new application, if we had resigned ourselves to patching something together, we'd be hurting as soon as we wanted something different in the application. We'd have to do most of the work again. And new team members would have to adapt to our ways of building software.
We knew that there was a better way. It involves trade-offs, but it unlocks a lot of potentials.
Mature software organizations often lean on platform teams to guide their internal development. They standardize tools, architecture blocks, and workflows. They bring certainty to building software.
Sometimes developers in those environments are frustrated because they want to do things their way. But senior engineers often beat the drums that building software is a team sport. That there's harmony in uniformity.
Namespace subscribes to that train of thought. That complexity can be tamed by leaning on uniformity and reusability.