New Web (API) Foundations (Part Two)

Published: 2021-10-17

Author: Teddi

So version two, what could that even begin to look like?

By trade I’m what I would consider more of a systems engineer when it comes to programming. I like making things tick and work together so what I am definitely not is a web developer by trade. Sure I’ve made the occasional website here and there, hosted various webpages online and so on and made the occasional web API but if we’re talking at scale then systems programming (especially distributed) are where some of my strengths lie. In fact, thinking about the wider aspect of programmers at [BB] we’re all systems engineers moonlighting as game engineers!

What this meant from my point of view was two things:

• I’m very much open to the wide range of technologies that have come along to make “web dev” better
• I’m likely going to be paralysed by the choice of options of available.

As a result I drew up a number of things that were hard requirements from a language point of view. Things that were needed and if I was to discount them (or too many of them) then I likely had to rule that option out. These were as following:

• Had to be relatively easy to maintain
  • I didn’t want to have to be juggling package versions
  • It should be something I can write the foundation of once and not have to worry down the line
  • I wasn’t going to get unknown or odd behaviour because the underlying system wasn’t concrete
• Had to be as lightweight as possible, both in terms of the compiled endpoint and the amount of code wrote.
  • Additionally if the runtime CPU / Memory usage could be as light as possible, this was a bonus
• Needs a strong standard library built in to the language.
  • If this isn’t a thing, how easy is it to pull in external libraries that fulfil this function well?
• Required as few external dependencies possible to get it up and running.
  • For example with Python, you can run it straight up on port and use nginx to reverse proxy this, however this will lead to very poor performance very quickly. So you use a tool like uwsgi to manage this which comes with its own problem. We do not want this.
  • In an ideal world, the web server is as production ready as can be.
• Routing and passing information has to be sane.
  • I don’t care about mutability vs immutability, I just care I can get my information in a sane fashion.
• I want to automate what I can, tooling should be available to get me “far enough” that I don’t have to worry about the underlying wiring.
  • But I do care enough that if what is generated is of poor quality or performance, I don’t want this.
• Middleware
  • I hate this term in the web-dev world, but as it’s ubiquitously used I’ll roll with it
  • If I want to intercept requests and manipulate them (e.g. authentication) how easy is this to do?

At this point I wasn’t even so much caring about REST vs SOAP vs GraphQL vs whatever, I just wanted something that gave a solid base.

I spent about a month going back and forth, prototyping and seeing what I could pop up with. Python was ruled out incredibly quickly because I just wasn’t interested in dealing with it any more as a web language. I wasn’t touching PHP with a bargepole because although it’s gotten better it still feels like a language that I need to use a framework to get the most out of. I’m also of the opinion that adhoc file-based interpreted languages like PHP are an incredibly outdated concept.

This left me with node.js and Golang. I’d been working with a company that as their main language used node.js and I had personally been on a Go kick. I already knew the downsides of node.js (and by proxy, express) but figured it wouldn’t be fair to entirely discount it if I hadn’t tried to do something in it personally.

Yeah, no, that was knocked out very quickly. npm and yarn do their best to deal with libraries in node.js however as there’s a lacklustre standard library to begin with your applications quickly begin to swell in terms of file-size and it’s a performance hog. Sure it’s fast on benchmarks but the trade-offs feel too much for it to be acceptable.

So that left me with Golang. Sure you could argue at this point in the post that I had a favourable bias to Golang and that’s not unnecessarily incorrect. I do like the language but it does have its own downsides; still a bit immature in certain areas, sweeping changes are still being made between some languages and the lack of generics (as we’ll find out in the future) has proven to be slightly painful but for the time being: it fulfils the criteria.

At this point we haven’t even considered how we’re getting the data out or authentication - but we’re one step closer. Now we need to fulfil our second set of criteria. On to the next blog post!