The story is almost always the same.

Whether you are an entrepreneur with ideas for the next big thing, a mid-level HR manager wishing to automate cumbersome procedures, or a small business owner longing for a customized information management system for your firm.

Even though the idea is very clear in your head, you are always faced by the one obvious yet difficult step: the system has to be coded! If you already know how to build systems, way to go! You might want to stop reading here (or skip to conclusion if you want to save your development time still). If not, you find yourself with few choices:

1. Outsourcing Development

Good developers are expensive.

This is a known fact. It takes dedication and craft to become a good developer, and so their rates are set accordingly.

If you have the budget to hire a stellar developer or a development agency, and you have faith in your app’s success to justify such investment; then it is the way to go.

If this is not the case though, you are left with the next choice.

2. Learning to Code

It takes 10,000 hours of learning to master any given skill, says Gladwell in The Outliers.

This is a huge investment of your most valuable commodity: time. Even if we are happy with just 1,000 hours, just enough to develop a not-bad system, this is still around 6 months of full time learning.

If you are willing to do such investment, and with no technical guidance, you are usually lost as to where to start: there are literally thousands of ways you can build an app.

To make your life easier, we pick a prevalent conceptual architecture used by the tech giants like Google and Amazon to facilitate your journey.

A modern architecture to build an app is to divide its functionality over two layers: frontend and backend.

The frontend is the part which your app users see and interact with. This is where your innovation is needed most, usually.

The backend is the back office of your app. This is where your app’s data is kept, maintained and accessed according to your business logic.

These two layers have different qualities and require different skills as detailed in the following sections.

2.A The Frontend

The frontend is the visual part of your app. It is the texts, images, videos, buttons and text boxes the user interacts with to use your app. Developing a modern frontend involves the knowledge of at least these two technologies:

1. HTML5: this is a standard markup language to describe the visual elements to be rendered by a browser or a hybrid mobile app. It is not really a programming language and is usually easy to learn without a technical background.
2. Javascript: this is the programming language which describes what happens when the user interacts with the user interacts with your app. As this is a proper programming language, it takes a significant amount of commitment to master it.

The good news is, you can get away with doing the frontend without coding at all! Because of the visual nature of the frontend, several point and click tools exist to help you create your frontend without writing any code, Bubble is one example.

2.B Backend

The backend is the part of the system running on a server or a group of servers. This is where your app’s data is stored, maintained and accessed according to the rules you set for your app. Developing the backend is the heaviest technical debt in building your app.

There are just too many programming languages (Python, Java, Javascript, Go, Rust, C++, Clojure, PHP, .NET …), frameworks (Django, Flask, Hibernate, Express, Hapi, Drupal, Symfony, …), and databases (Postgress, MySQL, SQL Server, Oracle, MongoDB, Cassandra, …) to choose from.

The backend needs to be carefully built to both function correctly and scale up with your application usage volume. While there are visual programming tools to help you design your backend without coding, they are mostly limited and/or will not scale well with usage.

This is actually where most people with great ideas block for long times, so long that they miss the market chance to introduce their app.

At Codoma.tech, and moved by this tragedy, we decided to build something that will solve this problem once and for all.

Introducing the Codomat

In this time and age, building the backend should be accessible to anyone able to describe what they want to create in a clear language, without having to describe every little detail on how the backend should work (i.e. without actually writing the backend in a specific programming language).

But currently this is not possible. This is why we built the Codomat.

The Codomat is a machine which understands a clear english-like description of a system, and based on it, it generates a fully functioning backend program in a technology of your choice. The program is ready to be deployed either on your own server or in the cloud.

The Codomat basically spares you the effort of developing the backend, and grants you the freedom to choose your technology and hosting platform according to your own needs.

Typically, backend frameworks and libraries showcase their features by creating the neat (yet too simple) todo app backend. But the Codomat is more capable than this.

In what follows, we demonstrate how, in 35 lines of specification (including comments), we will create the backend of a complete social network.

Social Network Example

This is the Codomat specification of a social network. Lines starting with # are comments and are not processed by the Codomat.

Entity posts has the fields
    author
    text
    timestamp
    replyto
.

Entity follows has the fields
    follower
    followed
    timestamp
.

# users who the authenticated user follows
Derived currentuserfollows
    uses follows
    is record_followed for record in follows if record_follower = authuid
.

# retrieve only the posts the current user cares about
Filter posts by
    authuid = record_author or record_author in currentuserfollows
.

# enforce correct authorship
Restrict posts
    enforce author = authuid
    enforce timestamp = now
.

# enforce correct followship
Restrict follows
    enforce follower = authuid
    enforce timestamp = now
.

How did you come up with this specification?

The first question you need to ask to build your backend is:

What entities needs to be stored on the backend?

A first thought would be the social network users. The Codomat has you covered on this: a user management system is automatically created and doesn’t need to be explicitly specified.

The next entity is potentially the posts which users send. A post typically has a few attributes: the author, the post text, when it was posted, and if it was a reply to some other post, the other post’s id. This is exactly what is specified in the first entity definition, posts.

Finally the social network needs to store which user follows which. This is what the entity follows represents.

This took care of storage! All essential information of our social network are specified just by two entities: posts and follows.

The next question is:

What are the rules to be obeyed when accessing data?

In our example, let’s say a logged in user can see only the posts of people they follow (like Twitter’s home feed). A logical step then is to find the users followed by the currently logged in user. But this is not an independent entity to be stored, it can actually be derived from the follows entity and the currently logged in user id. This brings us to the third question:

Do we need any derived information to enforce the rules?

The answer in our example is yes. The steps to find current user’s follows is to go through follows, and see the ones where the follower is the current user; from these ones, the followed is the information we are after. These steps are encoded in the derived entity currentuserfollows in a syntax which is a simplified version of the set-builder notation in math. Note that the reserved words record refers to the current record being inspected and authid is the authenticated identifier of the currently logged-in user.

Now that we have defined all our entities and derived information, we get to enforcing the access rules. The Codomat syntax gives us two tools for this: Filter s and Restrict s.

A Filter is a set of conditions applied when the frontend reads an entity. Only the records satisfying the conditions will be sent to the frontend. In our example, there is just one filter on the posts entity. It limits the posts to be only those either authored by the current user, or by some other user they follow.

A Restrict is a set of changes applied to the data the user sends to create a new record of some entity. When a user creates a new post, their user id should be set as the author, and the post time should be now. When a user follows another, their user id should be set as the follower, and also the follow time be now. These are the two Restricts we have in our social network.

That is it! All you need is to write 35 lines of clear specification, you throw it on the Codomat and it hands you a package of code in a technology of your choice readily deployable on a private server or a cloud.

We did exactly that with the social network example and released the backends we generated (using different technologies) on a our github repository under a public license.

Conclusion

The next time you think of building an app/system/website of customized functionality, you have the option to shorten your time- and budget-to-market by following the next steps:

1. Think of what to be stored on the backend, and how it should be accessed,
2. Write a Codomat specification to reflect your ideas from #1,
3. Hand the code to the Codomat, click a button and your get a complete deployable backend, and finally
4. Use a tool or hire a developer to do the frontend of the system and interact with the backend.

Outlook

A well-versed reader might be asking now: why invent a new programming language, regardless how simple it is? The world had enough languages already!

To this, we have a few good points:

Simplicity is not to be Overlooked

Especially when it is combined with a fair amount of expressiveness. The Codomat specification language makes building systems accessible to everyone with a clear picture who a system works without burdening them with too many details.

Moreover, even a well versed developer will benefit from a much shorter specification of their system.

Maintaining 35 lines of code is exorbitantly easier than maintaining 500+ lines.

A Higher-Level Specification allows for better Optimizations

Since the actual code is generated from the specification, and it is only the high-level specification that is to be maintained, it is allowed to do things developers usually refrain from doing for the sake of maintainability.

Things such as:

Positional data over the Wire

Sending records as list of values based on entity’s field order instead of objects/dictionaries, e.g.: instead of sending

[
    {firstName: 'John', lastName: 'Smith'},
    {firstName: 'Jenny', lastName: 'Becker'},
]

We can send

[
    ['John', 'Smith'],
    ['Jenny', 'Becker']
]

This wins us some precious bandwidth.

Using languages otherwise feared for being too complicated

Backends are currently written to be, first and foremost, easily maintainable - optimizing performance comes second.

This is why most backends written today are in some interpreted language: Python, Javascript, Ruby.

Lifting the maintainablility constraint opens the door to using really performant languages with small memory footprints and 2x to 4x speed advantage compared to interpreted languages.

The Codomat is going to generate backends in languages such as C++ and Rust for superior performance.

The next posts will publish performance comparison of various programming languages implementing the same specification - stay tuned!

Final Words:

The Codomat is currently still in beta phase. Drop us a line to receive news, premium support, and early-adopter benefits.