The Structure of a Grove Project
A “Grove Project” refers to a set of one or more applications, plus all associated plugins, API specs, and tools, that is designed to work together. The grove-cli generates such projects, and you can also add or remove applications as development on the project proceeds.
“Grove Applications” are the core constituents of Grove projects are extensible middle-tier and UI applications. These can be implemented in various programming paradigms. A middle-tier Application could be written in Node Express or Java Spring Boot. A UI Application could be in React or Vue.js.
Grove-generated Applications conform to Grove API specs for communication between the UI and the middle-tier. They can be extended beyond those specs.
Grove Application Plugins
Grove Applications are designed to be extensible and modifiable. Grove applications are often fairly thin hosts for Plugins that provide functionality to the applications as versioned - and thus upgradable - dependencies.
Grove defines a series of “Grove APIs”, using the OpenAPI spec, to create consistent communication between a Grove UI application and a Grove middle-tier application. This enables a highly swappable architecture.
A “Grove Template” is used by
grove new to generate a new Grove Project. For example, we have a React-Redux template that provides a UI Application based on the React and Redux ecosystems. We have an alternative VueJS template. We have a Node Express template that provides a middle-tier Application, implemented using the Node Express.js library. We anticipate the creation of additional templates in the future.
The grove-cli supports several goals.
Ease of Use.
This design goal means we will:
- Enable rapid bootstrapping of UI-rich applications backed by MarkLogic. The grove-cli allows this through the
grove newcommand, which generates a new application for development.
- Deliver pre-packaged demos in addition to an app-building toolkit. The grove-cli provides the
grove democommand, which provides fully-baked demos. This functionality is still work-in-progress.
- Leverage existing MarkLogic technologies and skills. This means that we avoid requiring new skill sets. Instead, we leverage those skills already used to develop applications using MarkLogic.
- Provide supported upgrade paths. Projects generated by the grove-cli are upgradeable. Eventually, we may support an upgrade command within the cli itself.
Consistency of experience.
This design goal means:
- Commonalities when moving between Grove projects.
- Develop within a single programming ecosystem. We’ve started with Node, for example, and you don’t need to context-switch to Java or Ruby to work with a Grove Node application. The middle-tier is in Node, and so is the command-line interface. We plan to support a similar experience in other programming ecosystems as Grove progresses.
- Shared APIs across these ecosystems. So, if you need to swap out your Node middle-tier for a Java middle-tier, your front-end application can rely on a consistent API.
Adopt existing conventions, standards, and tools.
- When possible, we don’t create new ones. The grove-cli is limited to orchestrating Grove projects and many tasks will use the existing tool within the ecosystem of a particular Application (create-react-app for React or the vue-cli for Vue, for example). And, during its orchestration tasks, the grove-cli will lean heavily on tools like
npmand conventions like
- For each Grove middle-tier or UI, you are placed into that ecosystem and can use the tools and conventions of that ecosystem to extend or modify your application.
- Grove provides niceties, orchestration - but you can hand off the application and the person receiving it does not necessarily need to know about or understand Grove in order to be successful and to continue developing.
- Modular, pluggable, extensible architecture. Applications generated by Grove aim to achieve these goals. The grove-cli may eventually support an “add” command to automatically install new Plugins.