We were inspired by the general industry sentiment that “In the end, most web apps are just glorified CRUD interfaces.” It didn't make sense to use that our JavaScript frameworks was the part in the equation that was standardized and agreed upon when the front-end operations should be different for every project. However, the back-end operations can be considered pretty much identical. Even with Ruby on Rails this current culture of rewriting the API for every project is inefficient. Ardite solves this.

What it does

Ardite is an open source project which solves this problem by standardizing the data system and separating concerns. By doing this, an API becomes very “plug and play,” whether the developer is plugging in a database driver like SQLite or PostgreSQL or the developer is plugging an HTTP interface like REST or GraphQL.

Technically, Ardite is composed of three main parts:

  1. A universal schema definition. Which attempts to define an application's data system including information like authentication roles for instance.
  2. A driver which connects Ardite to a data source. Whether that driver be connecting Ardite to PostgreSQL, MongoDB, or even another API.
  3. A service which is the interface users can access data from. Services can include things like a REST service all the way to a GraphQL or JSON API service.

How we built it

We used Rust for its performance characteristics and its growing community. We never expected to finish Ardite over these 36 hours, only to get a good start to meet a future deadline. What we accomplished in these 36 hours specifically was:

  • Ardite schema deserialization from JSON.
  • Proof of concept MongoDB driver. MongoDB was chosen for this hackathon for its simplicity compared to databases like SQLite, PostgreSQL, or CouchDB.
  • Create parser for a GraphQL service. We chose to chase GraphQL support for this hackathon because the React market would likely be very open to this project. Use by the React community in the beginning of Ardite's history would be beneficial to Ardite's future growth. The one thing we didn't anticipate was the difficulties involved in parsing a language.

Challenges we ran into

The standard compile errors. Also, some of Ardite's designs were not completely flushed out when starting the hackathon. Therefore when it came to implementing them a few minutes must be first spent addressing and evaluating the problem.

We also ran into a large problem creating a port of Facebook's GraphQL parser to Rust. As our team had little experience with Foreign Function Interfaces (FFIs) and the use of such APIs require some "unsafe rust" code, creating the GraphQL parser took longer than anticipated.

Accomplishments that we're proud of

The work we got done. Unlike most hackathon code, what we wrote in these 36 hours, this is not throw away code. We have plans to continue to develop this software, this hackathon was merely an accelerator. The core library is now much more fleshed out, core concepts are starting to solidify, we have a MongoDB driver, and we have a working GraphQL parser.

What we learned

Do a full inventory of our plans and what we know before going into the hackathon so if we need to try something new like FFI development again we can be prepared.

What's next for Ardite

Further development.

Specifically, we need to find a good way to manage collections with our schema and authentication.

Built With

  • rust
Share this project: