Inspiration

The inspiration from Valigator comes from one of our team members who manages open source projects used with Minecraft servers. These systems are configurable by the user, but often the user does not have the technical ability to edit this files and it's often a source of confusion due to a lack of good verification and documentation. According to him, about 2/3 of all support issues are configuration issues - anything that makes it easier for users to work with the system is better for them and the maintainers alike.

What it does

Valigator is a library and application used for validating configuration files. Our system provides an API for developers to write their own schemas to match their project needs and share that schema online with end users. As a user, Valigator uses the schema to verify the configuration you're creating is correct and provide human-readable error messages in exceptional cases. Currently, Valigator supports JSON, XML, and HOCON configuration formats.

How I built it

The project is largely divided into a frontend and backend. The fronted is written in Python using Flask and served as a web application. To assist with editing schemas and/or configs, we use a system called CodeMirror to provide a standard development text editor, syntax highlighting, and other utilities.

The backend system is a JavaScript library for creating and validating schemas, consisting of both an implementation and the design of the API used by developers to builld schemas.

Challenges I ran into

JavaScript. We also had difficulty integrating the backend system with the Flask project (eventually fixed by defining a custom location for static files) which also left us considering switching to Node + Vue.js in multiple occasions. Finally, we also had difficulty with integrating the CodeMirror system into our project, and we're extremely thankful for Shane Exterkamp's help with doing so.

Accomplishments that I'm proud

I think the largest accomplishment is the design of the API, which is very simple and straightforward for what it needs to handle, as well as our ability to identify error cases such as misspellings by calculating an estimated distance between words using the values the schema expects versus the values received from the user.

What I learned

JavaScript has many more quirks than we had expected, but we made the most of them to create a clean API. The actual validation part

What's next for Valigator

Moving forward, we would like to extend the current API and provided schemas to include a base registry of common components (such as ranges, regexs, emails, etc) that can be easier mixed and matched by developers. We have also looked into including a custom parsing format and handrolling parsers ourselves in order to maintain things like order, case sensitivity, and other important contextual information. Finally, we would like to pursue generating an HTML input form that is generated based on schemas, allowing the use of drop-downs and fill-in-the-blanks to edit a config rather than having to write something like raw JSON itself.

Share this project:

Updates