Beginnings of Alteredge.
We started AlterEdge 11 years ago. Among other things we wanted to build websites.There was a question. What CMS should we offer to our clients. Wordpress? What if we want complex projects with complex dynamic models and relations between them. Let’s use Cake PHP. What about CMS? We will make custom forms in the backend (we have model scaffolding), it should not be that difficult. But it was.
DIMS
The vision of DIMS was born. Clients will be able to edit absolutely eveything from the frontend, not only basic data types like text and images, but everything including relations between models. Full, 100% frontend CMS.
We made a proof of concept, implemented it on a few live projects and presented the idea on the conference etrgovina. In discussion with some participants we defined a few models that will have implementation of DIMS: blog, shop, portfolio...
We had a stack: Cake PHP, DIMS.
As we developed new projects it was clear that DIMS is a sustainable solution for content editors. We implemented it on ANDI and Nutrichem. The problem now was backend, the code that works with relational mysql database and should be developed/adopted each time for a new business case. Costs of development are high. But that’s absolutely normal, this is how things work in this industry?
Vision of DIMS Builder
At this point we were aware of the backend problem and there we had a vision about DIMS builder, the website builder which will allows us to produce DIMS ready websites, completely through UI.
We needed the central registry of all models. We knew about schema.org, but that is an html markup. A lot of time (year or two) and a lot of thinking hava passed until it clicked in our heads that schema can be the source of models. If you need persons you will create a collection of Persons, if you need articles you would create collection of Articles. But how these models relate to one another?
Schema Builder
After few months of research Schema builder was born. It gave us the ability to experiment with schema and nesting models within each others.
VPTL
The story of VPTL
Momentum CSS Framework
Somewhere in between we had a version of momentum css framework, that was an evolution of Franky(nikola will tell you more about it here). This framework was already used in production. We decided to build UI over the framework and integrate it in environment
Vision of SaaS
All basic DIMS models could be served as saas. NodeJS, mongoDB experimental stack was made, we could build projects on our localhosts. We built UI to control styles of the page (via momentum css framework) and it was interactive. And then, one evening, at the end of the session of making a beautifull article layout the simple question raised. How to relate the block of the page which is supposed to be a Person to be an author of this Article? All experiments with mongoDB failed, we realized that anything we build this way will be very limiting. Because, as a designer you can easily imagine that Person worksFor Organization, and that Organization has location which is a Place, and you want to show them all in one block of the page. And from another side, it could be anything else that you imagine? Anything? Maybe anything from the schema.org vocabulary. We realized that mongoDBwould have serious performance problems to support this vision. At this point we knew we need a graph database.
Graph Database
The full year has passed in experimenting with various graph databases including Neo4j, OrientDB, ArangoDB and similar… The first prototype of VPTL was in place. You had a place from where you create your models and you would be able to set vptl renders for each.
Complete frontend refactoring
Since the very beginnings, the frontend was based on BackboneJS which was very popular in 2010. Meanwhile, the rise of reactive frameworks happened. We end up with Vue. During this phase, the shift has happened to the creator environment which controls the project loaded in iframe, as we know it today.