Long story short, I’ve selected web-framework for next project

Dmitry Dushkin
Feb 24, 2018 · 6 min read

Here are the requirements for next project:

  • GraphQL API;
  • Some simple auto-generated admin for start, so I won’t have to make DB calls for my own;
  • Built-in authorization and authentication;
  • Self-hosted;
  • MongoDB support.

First, I studied the current state of much-loved Ruby on Rails. It’s developing at very inspiring pace. Especially I like the initiative of Webpacker — it is the integration of Webpack 3+ into static assets compiling pipeline. Then I looked at the annual comparison of performance, demand, etc. of “Node.js vs Rails”. Well, on Rails side there are development speed, an atmosphere of relaxation, lots of built-in batteries, and on the Node.js side there are the fact that Javascript is my primary programming language, outstanding performance (comparing to ruby) and optional static typing. So I said “nope” to Rails this time, but won’t be worry even for a second if someday I’ll have to work at project based on Rails. :)

Also out of respect, I overviewed the current state of MeteorJS. The guys are quite close to the desired, there is really a very powerful system that simplifies the creation of real-time applications. Only the following items are confusing:

  • All real-time stuff is tied up on reading log operations from MongoDB. It’s difficult to say why it’s confusing me. Probably because that’s not what this mechanism was designed for.
  • MeteorJS team are planning, but not yet completely abandoned their own package manager Atmosphere.
  • Quite “poor” packages for auto-generating admin panel.
  • Basic stuff like users’ system need to be written by myself. It’s not hard and too long, but still.

If we’re talking about real-time I should mention Meteor’s closest rival — Feathers. It’s rather a simple framework for the creation of API without admin panel and other things, but the model of the real-time system is much more correct in my opinion and it’s very simple in the same time. Each entity is expressed in the form of a channel. All changes to an entity are distributed real-time via the in-memory cache to all other clients connected to this channel. It turns out the system is free from any certain database. There are some downsides mostly related to the application scaling. It’s still possible, but most likely in a real large application user should be grouped by regions.

However, I was dreaming. I should look into the eyes of my fear and google “node.js framework graphql admin”.

The number of a different project is frightening. One looks better than the other. But somehow it’s necessary to organise reality, isn’t it? I chose as criteria:

  • Sufficient maturity of the project;
  • Github stars;
  • Number of issues and pull requests;
  • Existence of life on the blog;
  • Additional features.

Most likely I will choose Strapi. For the last year, I subscribed to their newsletter and the pace of development of the project is very encouraging:

  • It has very nice admin panel (react-based) with users and permissions. This panel, by the way, is one the main selling points.
  • It’s possible to add custom features to the admin panel.
  • Creating custom entities in the admin panel.
  • GraphQL API
  • REST API (just in case)
  • Bunch of other useful items such as CSRF, gzip, etc.

It’s worth mentioning Loopback. It’s advanced platform to create API that IBM bought 2 years ago and powered it with cool admin panel functions such as deployment to Bluemix (PaaS by IBM), orchestration etc. IBM called this version API Connect. I’ve started one project on this platform and was very pleased with CLI generation of entity schemas, simple connection to various databases, quite a convenient API browser and auto-generated API docs. These guys are preparing loopback v4, where everything is out of the box is on TypeScript, there will be support for GraphQL and so on. Will definitely return to it in six months or a year.

There are a couple of interesting projects that I had not considered due to their youth or death :):

  • Crudl is very similar to Strapi on a set of features, admin panel, but it’s definitely 1.0 version is in active development.
  • RethinkDB + Horizon is the database and JS framework. Very similar to MeteorJS, but “done right” real-time related sub-system, because the database initially focuses on real-time. Unfortunately, these projects are no longer receive funding, the site of Horizon is down, plans of a community are vague.

There is still a huge pack of platform services that cannot be hosted on customer’s servers, but otherwise, they fit the requirements. In general, the idea of using third-party service is very pleasant because you do not need an administrator, you should not think about scaling and fault tolerance. On the other hand, if you have a pet project and the goal is to understand how the whole web applications work, then these platforms should not be used.

When considering these platforms the head starts to swell. And especially swelling badly when you start looking at monster platforms: Google Cloud, IBM Bluemix, Microsoft Azure, and Amazon. Is there anyone on earth who knows all the powers of these platforms and can tell what’s the best?😵

I like Firebase. It has almost everything (except GraphQL), but since the project bought by Google you can you new versions just as a service with no so cheap subscription plans. Frankly, I became less aware of the focus of the project. Previously, it was real-time DB with an admin panel, now it is EVERYTHING (analytics, charts, a bunch of different storage types + storages from other Google Cloud, performance monitoring, serverless hosting, notifications etc.). I feel that Google like Kraken drags the project into its mouth and expel second Kraken.

Scaphold platform is looking good. It’s built entirely around idea of creating and working with GraphQL API. As a database, it uses Amazon Aurora MySQL and S3 for files. But for now, it’s network status page is down 😮

With those platforms I see three main problems:

  • Really big mix-up with the appointment of its sub-services.
  • The complexity of calculating the cost of the project when it starts to receive any load.
  • Uncertainty with data centers. Most of these platforms do not have data centers in Russia, so some of the clients will be unhappy with ping.

* * *

For myself, I conduct a similar review about once or twice a year for 10 years, when I first began to be responsible for the full cycle of creating web applications that should really work. Regret, that before not was recording all of this in the form of posts. I think today’s post could be the beginning of a good tradition.😌