The Jali repository is designed to provide a uniform development and execution environment for polyglot development of Jali packages and programs within different OS Platforms, such as Windows, Mac, and Linux distros.
- Development philosophy
- Jali GitHub repository
- Development host configuration
- Development guest configuration
- Chef
- NodeJs
- Sphinx
- Editors
- Visual Studio Code configuration
- Project configuration
- Folder Structure
npmproject configuration- TypeScript configuration
esdocconfiguration- Linters
tslintconfigurationeslintconfigurationmarkdownlintconfiguration- Babel configuration
webpackconfiguration- Editor configuration
- Visual Studio Code configuration
- Jali build process
- JS module file names: @rauschma tweet
To set up your Jali development environment, follow the Getting Started section of CONTRIBUTING.md.
However to understand the design of the Jali repo, we will discuss the following topics:
- Development philosophy
- Jali GitHub repository
- Development host configuration
- Development guest configuration
- Jali build process
Jali provides a consistent, integrated Linux-based development and operating environment for microservices. The goal is to have a single, modular tool that provides the full DevOps stack with a single tool-set. The toolset provides abstracted commands that is implemented by plug-ins for different technologies and languages.
The key for Jail is to bring the DevOps process up to a semantic level to democratize access to microservices, regardless of chosen language, platform, configuration management tool, cloud provider, deployment orchestrator, or monitoring toolset.
It does not necessarily provide interchangeable access to every technology but allows the project team to pick or migrate to technologies that may be different from other teams but maintain the same toolset and microservice configuration and support.
Initial implementation will be for JavaScript and golang, with support for dotnet and others to follow.
A key design goal of Jali is build and run Jali development with Jali itself. This may require some creative configuration in the Jali project but will ensure that soundness of the Jali toolset.
Another important design goal of Jali is polyglot modularity. To make the module system as broadly applicable as possible, stdio will be used for all but trusted, i.e., internal, modules.
In the spirit of bootstrapping, the goal is to have as much of the native Jali functionality implemented as modules and extensions. Which leads us to the next goal.
A final design goal is to have a well defined extension interface that hopefully shares the activation/invocation mechanism with modules. That would include internal cross cutting concerns such as internal logging, etc.
The core design goal, however, is the concepts of the Routine and the Execution Context.
As much as possible, Jali itself executes using the smallest unit of execution used by Jali microservices: the Routine (or, at a higher resolution, the Routine Stage). Routines are invoked for a relatively short amount of time, defining an execution configuration that enables Jali to manage it's execution environment, scaling and partitioning, and lifetime. In addition, a Jali Routine operates within a clearly defined set of execution services, called the Execution Context.
In response to receiving a description of a routine's function by way of its configuration, the Jali kernel presents a routine with an explicitly defined Execution Context that provides microservice-relevant context and services to the routine. These services include
- Runtime services
- Consistent Distributed Configuration
- Authentication, Authorization, and Accounting (AAA)
- Exception Processing
- Logging
- Metrics Processing
- Data Context/Caching
The Jali GitHub repository is a Monolithic Version Control repository or monorepo. This means that the repository support many interrelated packages together rather than existing as separate repositories, greatly simplifying development and package authoring. Currently is supports JavaScript and NPM packages. In the future it will support polyglot development with golang and other platforms hosted in the same repo.
You can see the packages in the packages/@jali-ms folder.
The repo is managed by core contributors who are members of the Latticework research group and is updated using GitHub Pull Requests.
Project management utilizes ZenHub in a manner specified in the Contribution Guidelines section of CONTRIBUTING.md. The project uses GitHub issues for as ZenHub Epics and User Stories. Work item state is managed by using GitHub labels. The contribution guidelines specifies the use of emoji to facilitate work item status awareness. This feature may be automated in the future.
Development progress is tracked using a ZenHub KanBan board and GitHub milestones.
Currently feature branches are made directly from master, though a dev branch may be introduced as the product matures.
The goal is for Jali to support development hosts for Windows, Mac and various Linux flavors. The goal is to have the host configuration itself configuration driven with a jali.json configuration pattern.
Currently however Vagrant and ChefDK are required in addition to git. Lets look how these work together to build the Jali dev environment.
As mentioned in the Getting Started section of CONTRIBUTING.md, Jali integrates Vagrant with Chef using the vagrant plugins vagrant-omnibus and vagrant-berkshelf.
Respectively, these plugins install Chef into the vagrant guest machine and execute Berkshelf files on those guest machines.
The Vagrantfile