Do you really need REST API? Or maybe it’s time to be universal.

What if I said that we don’t need a REST API anymore? What if I told you that it’s become obsolete.

Every developer that has ever released an open source project believes, in its Unicity and importance. I can tell, because I feel it. Each time I release something I feel a slight relief. A feeling that my piece of something could help, make someones life better.

I chose Nodejs for a reason. Having 13 years of experience in various languages under my belt I can tell — it’s time for a change. It’s time to go full speed ahead with merging backend and front end technologies into one unified organism. And today I have something for you.

Not as if there aren’t enough open source projects on Github, it’s just there is nothing like it. I wanted to achieve a simple and elegant solution to universality, or isomorphism. I thoroughly checked existing solutions on the Internet, and I was not satisfied. Being a rebel my nature, naturally programer-rebel, I have my own visions and standards, and if I don’t like something or see solutions differently, I fork or create one of my own, and frankly there is peace in that.

How could we share the same code between browser and server? If you asked something like this 5–7 years that would have been qualified as a heresy. But look at the tendency. Javascript is the leading language according to Github. It is relentlessly evolving, and nothing can beat it. And the latter question does not raise smiles anymore.

The idea came to me 2 years ago when I started working closely with angular. I got fascinated with its simple approach of injecting dependencies

I created my own dependency injection system. Certainly, i did not really comprehend the scale at that time, but it was awesome. It solved many asynchronous problems, it helped me to build modular apps and made my code cleaner. But one year passed, and i got something different out, with a similar approach.

New standards we need!

A new modular system is screaming out to be introduced! The one that works the same in both environments. This system would require strict conventions. Yes, we need discipline.

What if I said that we don’t need a REST API anymore? What if told you that it’s become obsolete. Just imagine a regular flow

Pretty basic, something we got used to. But now imagine the same flow but without API and Client. Imagine an application that seamlessly calls backend or universal classes. Imagine a different architecture where you focus on your implementation, instead of setting up routes for REST APIs, importing HTTP services and whatnot everything else to make one little thing happen!

Do you think we can improve that?

I want to introduce you to Realm-js.


  • Realm-js is not a framework per se, it is a transpiler on one end, and an isolated javascript scope at runtime.
  • Imagine EcmaScript 7 imports on steroids. If you are familiar with Python or Java that the concept won’t be new to you.
  • A promise based, Realm-js respects Promises and resolves them if a module exports one.
  • 100% universal approach. Seamless “bridge” integration (Secured access to backend services through front end)

Now it’s time to go a little bit in depth. The concepts follow.

Every file is a module

You cannot import files anymore. There should be modules! Forget about having multiple exports at a time. Get used to have only one class in a module.

The latter ones need to have the same import system on both ends. If I say “a” I want to see “a” and not an adapted version.

In Realm-js every file is a class, so in fact, you are not referring to a file when importing, but to a specific class.

Every module belongs to a package

Comes naturally from Java. Strict convention of having one module per file guarantees the delivery. Realm manages a map of modules <path,Class>. On backend realm uses global variables to achieve npm compatibility. So, in essence folder structure defines packages, but could be overridden if necessary.

Imports got some upgrades! I can use aliases, package my application and never get lost again.

One source, three destinations

No matter how much you aspire to meet universality, you can’t take everything with you, because of security. You can’t share your database requests, configuration files, tokens and whatnot else. Hence, we need to have those things separated. Realm automatically creates and “maintains” universal, backend and front end destinations.

If you feel that a particular module (Class) does not belong to backend, you modify the header to “use realm frontend” and Realm-js will instantly move it to frontend.js

You take “univeral.js” to both environments. And the rest respectively to front end and backend.

But what about encapsulation?

Bridges to encapsulate

How great would that be to share backend methods, but without actually exposing code to the end users. Imagine a ToDo service. A very regular one, it talks to a database, removes, adds and edits database records.

A class that will be used in the backend

I don’t want users to see the implementation of my backend class. And this is where Realm-js comes very handy.

Front end does not know about the “real” service, only interfaces are exposed. And since promises are a best practice, we take it as granted. So calling “Todo.add” would return a promise (or should) on both ends.

But what happens when front end actually calls “Todo.add(1)”? That’s where it gets tricky. We cannot just perform an ajax call and forget about security. realm-router has a very neat feature — decorators. You can protect your bridges by creating your own security layer. But that’s a different topic.

How it all works

So in a nutshell, everything is very simple. Realm-js transpiler scans your source directory and “flattens” your code. Splits into 3 destinations. Let’s check an example.

You have file in src/app/blogs/GoogleFeed.js with this content:

As you can see above it has a bridge header. That means that front end won’t be able to access the implementation. After we have run the realm transpiler, backend.js would look like:

And front end:

Interfaces only! The same module name. And what is truly amazing about it is that you don’t need to do this separation manually. The transpiler does it for you. Let developers concentrate on development. Making their classes better. Focus on what really matters.

To try the demo, please clone

Use nodejs 4+, run “npm install” and “gulp start”. After you’ve seen front end in action, try calling “node test.js”. The exact same result, but on backend.

One source. Once code. No REST API. Win.

Next steps

  • Rewrite transpiler. It needs to use AST. I don’t want to go for babel, it’s just too heavy. We can do things much faster.
  • Test coverage. Need to have more tests
  • Improving the overall code quality. The library has undergone through way too many changes.

How you can help

If you really like the idea, please spread the word. Collaboration — Yes, i need one! Comment or send an email (nchanged at gmail dot com) with your thoughts / proposals.

Thank you very much for reading.




A passionate developer

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Ivan Orlov

Ivan Orlov

A passionate developer

More from Medium

What are STUN and TURN servers and why do we need them in WebRTC

Yarn 2(Berry)-3 significant additions

Cross-region RMQ message migration using Shovel Plugin

Cross-region RMQ message migration using Shovel Plugin

How to solve the NodeJS error: “cannot use import statement outside a module”