Skip to content

Package Documentation

Software is an ever changing field which empowers people to create tools to solve an infinite number of problems. Open Source is the foundation of that growth, without it, we'd all be scrambling to solve problems like headless chickens rather than working as a global collective. Open Source projects are dear to Grafite, as such we've collected their documentation into one simple place. Feel free to continue reading about our philosophies but if you're looking for specific packages check out the search or tabs above.

Design Philosophy

We firmly believe that great projects start simple and only add features that are necessary to provide optimal functionality. Unlike a sculptor who carves away the inessentials, software is like a piece of art, the developer like the illustrator begins with simple contours and adds details as needed to tell the story. We follow convention over customization as much as possible. In an ideal world software when read has no persona to it, but, we also adhere to making readability the highest order. Computer's can read code far better than any human can, so we believe its best to write code that a person can read. In the end six months from now when you're reading your code, its you who has to understand it.

When developing packages we do our best to separate concerns and keep the data flow as simple as possible. Our packages follow semantic versioning and are often aimed to maintain a long term support by detaching themselves from a code base as much as possible.

Modular Growth

Grafite follows a modular growth structure through the use of packages. We believe that if the code is reusable enough it can become its own package. If an application needs to deviate from the package enough then the package can be transferred into the application's base code. All projects are different and require analysis to determine the best course of action. As such, we have developed packages to handle anything from subscription based applications, to CMS integration and even custom e-commerce platforms.

Code has a Short Life

We believe in creating tools that help people build amazing things, but in that same context we know that not all things last long. Sometimes we develop packages that need to be discarded. Sometimes features get removed if they prove to not serve a purpose. All code has an expiration date connected to it, as the infrastructure changes and the maintainers come and go. Though we aim to provide long lasting packages we hold firmly to the idea, that sometimes writing something all over again is the only way forward.

We're not perfect

If you think we're nuts please provide a reason, but we're always happy to discuss design pattern ideas and implementations.