The perfect web stack? (aka: typing your APIs)

PJ Camillieri
aiden.ai
4 min readOct 22, 2019

--

This article is written from the perspective of a founder / CTO. So it’s not just about the technical merits of the technologies put forward. There are other criteria to take into account:

  • will these technologies “scale”. And I am not talking about the hypothetical million users / month scaling issue. Rather, how does the code base cope with a growing engineering team (we are a team of 12 and growing)
  • will you be able to attract talent? Engineers do pay attention to the stack they will work on and any founder here knows how difficult it is to hire good SW engineers.

To type, or not to type…

Rails has, for a long time, been my technology of choice and I love it. I still think it’s the fastest way to ship something, and to ship something robust and solid. But it has two issues in my mind:

  • it is hard to convince talented and ambitious SW engineers to work on a Rails stack nowadays. Don’t get me wrong: I do think it’s a pity and frankly it’s not grounded in any real, technical rationale (there’s a lot of “fashion” in this). But again, as a founder, I just don’t have the bandwidth or luxury to go against the tide.
  • Ruby is not typed. I know this is highly contentious. It is possible to write a system with non-typed languages. In fact, some fantastic teams do it and do it well. But in my experience, non-typed languages do seem easier initially than typed ones. But the reality is, as the project and team grow, they become hard to do well. It requires a lot of self discipline, conventions etc (and it’s easy to “forget” this stuff under time pressure and pile technical debt). On the other hand, with statically typed languages you simply can’t “postpone” this stuff. You must think your types through from early on. It basically sets a level of discipline that you can’t avoid. Case in point: some high profile, large teams are working on projects to type some of the most beloved non-typed languages. See Stripe’s Sorbet for instance (or Python’s mypy). It is also in part why, let’s be honest with each other, startup folks, any large scale project involves Java or any other typed language.

Our quest for a web stack

At Aiden, our initial backend had to be written in Javascript (long story but it was imposed on us). On the plus side, going React/Redux in the front end was a “simple” choice and it means attracting front end engineers is easy: people love these tech.

Unfortunately though, the JS backend was another story. We quickly struggled as the team grew. Most of it was my fault — I wrote the first MVP much too fast and let complexity sneak in. But also, JS can definitely be difficult to maintain when projects and team grow. The fact you can throw anything into an object, modify it as you go etc (I know, I know, you don’t “have to”, it’s called bad engineering) can quickly back fire.

So as we passed 5 engineers, we decided to transition everything to Typescript a year ago. It did take time frankly, but the ecosystem is now mature enough there are no critical “issues”. So our web stack (* see note at the end) is now:

  • backend: Node / TS
  • frontend: React / TS.

Everything is statically typed and it’s proven a big, big productivity boost:

  • you just “read” the types and you can make sense of the code
  • refactoring is much, much easier
  • documentation does not drift
  • we capture so many pesky bugs at compile time

But there was one missing link: we were “loosing” our types between the front and back end (our APIs were simple, REST like APIs).

So around 6 months ago, an engineer in the team decided to tackle this problem head first:

What if we could type our APIs?

Turns out, there’s nothing “new” with this idea. It’s called RPC. The idea is, instead of calling a web API, you simply call a function as you would any other, except it gets executed somewhere else. And of course… types get preserved!

So we wrote a RPC framework in and for Typescript, called rpc_ts (NB: if you want to read more about the tech and where it comes from, see our other, much deeper article here).

With this additional piece of technology, our entire stack is now statically typed across the board! It uses modern technologies (cf the recruitment aspect), and it’s frankly a pleasure to work with and productivity is good.

Giving back

We think other teams would benefit from the possibilities of a stack like this. So after 6 months in production at Aiden.ai, we decided to open source our TS RPC framework. We hope it will help other teams, and in the process hopefully you will want to contribute back to the project!

Enjoy!

*our data pipeline and ML stack is not TS, but that’s a discussion for another day.

At Aiden we are building the future of work. Why should anyone spend time crunching numbers and doing all sorts of charts and pivot tables, when you can get actionable insights tailored to your business needs instead?

Interested? Get in touch, we are hiring.

--

--

PJ Camillieri
aiden.ai

Engineering & Product @ Twitter. Before: co-founder @ Aiden.ai (acquired by Twitter). Before: product manager @ Apple