What I learned after 5,000 hours of building APIs.

Santiago M. Quintero
4 min readDec 10, 2019

Disclaimer: I do not endorse nor benefit from any of the products here promoted.

A typical API consists of 4 parts:

1. A User Interface.
2. Typically, a JS framework.
3. A Database.
4. Possibly a server.

Sometimes, I do get bored and I want to automatize some of my work. There are many exciting new developments on AI and I wanted to be a part of it. So I undertook what I imagine it would be a CLI DB model builder.

After quite a while there are so many similarities across projects that seemed possible to type:

model users

and a full fledging set of UI views and DB tables would appear. Perhaps the CLI would ask me which fields to include, but maybe not.

Naively, I thought I would learn some new things in the way perhaps Angular, TypeScript and some text generation algorithms. This came until I realized a simple React Component is possible all I need, but before going into more detail let’s get started with UI.

1. Selecting a UI Framework:

To my personal dismay, I cannot code anymore, anything without some styling. Customers are to be blamed for the habit. This has been some of the options I’ve worked in the past:

- Boostrap: Who hasn’t, and thus, is so boring!
- Bulma: very Vanilla, quite beautiful. But so much code…
- AntD: it is so perfect, is still boring.
- Grommet: So beautiful, yet so illogical. I did not want to get mad.

In the end, I went with Blueprint from Palantir, I have some respect for the company behind it. It is designed for data-intensive apps (no responsiveness, good). And it was sober, discrete, not flashy, yet pro. So far I like it, a couple of incongruences, some shortcomings. Yet, I see the looks shaping how the app is built.

II. JS Framework:

As mentioned my sincere intention was to use Angular. After a look at the docs, and the memories of my previous projects. I said Nah! it is for sure not worth it. The final punch came after looking at the CLI commands, to be honest, I was expecting a lot more.

Regarding TypeScript, there was so little change in it. And then I remembered, about my experiences with compiled languages. So much wasted time, so many opportunities for distractions, so slow. Sorry CS grads, I truly want to be like you but I guess I behold beauty somewhere else.

As far as VueJS it so clean, quite verbose and at times surprisingly limited, that I did not even consider it.

I was eager to test if my enthusiasm for React was worth. It is, hooks rock!

A couple of notes about other frameworks:

- React360: quite interesting, definitively give it a try.
- Flutter: Flutter is great, Dart is hideous. So enforcing, so long docs, so typed. Good idea we need a better vehicle for it.
- Kotlin: I haven’t tried the web version, but even though is Android and JVM is great. For sure, my next experiment.

III. The DataBase:

This is the heart of the project, and where the most mind-blowing solution is.

A brief notes of disqualifiers:

- SQL: do not even attempt it, six months down the road you will be already regretting it.
- Firebase: great concept, bad implementation.
- GraphQL: it is genius, but buggy, underperforming although easy.
- DynamoDB: for 1 to 10% percent of the projects it is the go-to choice. For a generic CRUD API, no.
- MongoDB: it is cool, yet you can do better.

And the answer is… Stich. Haven’t heard of it is OK it has only 700+/- weekly downloads on npm.

Stich has the flexibility that SQL lacks. The convenience that Firebase attempts to give. The power that GraphQL brings, and the beautiness of MongoDB.

No, it does not have the scalability of DynamoDB, but who has?

Stich is the Serverless Version of MongoDB. You get the document storage, real-time listeners, functions, query pipelines connected apps and everything without a back-end. In the past, I even used to compute the correlation between the two variables. The only lack is in intuitiveness during the configuration but after that is a breeze.

IV Server:

As you may know, I will skip this part for my ideal API. But I do want to make some comments. Lightweight options as Express and Flask are good and reliable. If I had to choose one it would be Flask, because of Python: it is another language/paradigm, has a whole different community, and a very close kinship to Data Science. However, Express is possibly slightly better.

After looking at the robustness of a couple of two-year-old projects with minimum maintenance, I would still consider Django for the appropriate project, and sometimes you forget how much out of the box it has. Ruby and PHP are not even an option and Go only if there are strict cost implications (it is so obscure).

Lastly, I have not participated in Kotlin or Scala back-ends but I do know very happy peers behind them. Swift is steadily growing and definitively interesting. And AWS is a no brainer against GCP, without actual knowledge, I am sure Azure has managed to create a horrible product around a great concept as the cloud, I mean they built Typescript after all.

As for the rest, I am pretty happy with GitLab, their lean PM code-oriented tools, and very strong CI/CD culture. For hosting you can probably do not do any better as Netlify, and if you’re lazy or very design-oriented. There are nascent sophisticated options growing around as for instance WebFlow, ProccesWire, and even Shopify. As for collaborative design tools, they are in this order: InVision, Figma & Zeplin.

This article has been lengthy, you can hit me up at Linkedin. Take a look at the code in GitLab, or look at the project ici.

Merci, atentamente.

Santiago M.

--

--

Santiago M. Quintero

Entrepreneur, Software Engineer & Writer specialized in building ideas to test Product Market Fit and NLP-AI user-facing applications.