Web Services And Data Exchange

I may not write web code for a living (not much backend certainly and definitely no front-end stuff, as you can see around here), but interacting with webservices to the point of sometimes having to “fix” or “enhance” them? Often enough to have an Opinion.

There is a very strong divide between web development and more “traditional” heavy client/app development : most of the time, I tell people I write code for that these are two very distinct ways of looking at code in general, and user interaction in particular. I have strong reservations about the current way webapps are rendered and interacted with on my screen, but I cannot deny the visual and overall usage quality of some of them. When I look at what is involved in displaying that blog in my browser window, from the server resources that it takes to the hundreds of megabytes of RAM to run a couple paltry JS scripts in the window, the dinosaur that I am reels back in disgust, I won’t deny it.

But I also tell my students that you use the tool that’s right for the job, and I am not blind : it works, and it works well enough for the majority of the people out there.

I just happen to be performance-minded and nothing about the standard mysql-php-http-html-css-javascript standard pipeline of delivering stuff to my eyeballs is exactly doing that. Sure, individually, these nodes have come a long long way, but as soon as you start passing data along the chain, you stack up transformation and iteration penalties very quickly.

The point

It so happens that I wanted to do a prototype involving displaying isothermic-like areas on a map, completely dynamic, and based on roughly 10k points whenever you move the camera a bit in regards to the map you’re looking at.

Basically, 10 000 x 3 numbers (latitude, longitude, and temperature) would transit from a DB to a map on a cell phone every time you moved the map by a significant factor. The web rendering on the phone was quickly abandoned, as you can imagine. So web service it is.

Because I’m not a web developer, and fairly lazy to boot, I went with something that even I could manage writing in : Silex (I was briefly tempted by Kitura but it’s not yet ready for production when involved with huge databases).

Everyone told me since forever that SOAP (and XML) was too verbose and resource intensive to use. It’s true. I kinda like the built-in capability for data verification though. But never you mind, I went with JSON like everyone else.

JSON is kind of anathema to me. It represents everything someone who’s not a developer thinks data should look like :

  • there are 4 types that cover everything (dictionary, array, float, and string)
  • it’s human readable
  • it’s compact enough
  • it’s text

The 4 types thing, combined with the lack of metadata means that it’s not a big deal to any of the pieces in the chain to swap between 1, 1.000, “1”, and “1.000”, which, to a computer, is 3 very distinct types with hugely different behaviors.

But in practice, for my needs, it meant that my decimal numbers, like, say, a latitude of 48.8616138, gobbles up a magnificent 10 bytes of data, instead of 4 (8 if you’re using doubles). That’s only the start. Because of the structure of the JSON, you must have colons and commas and quotes and keys. So for 3 floats (12 bytes – 24 bytes for doubles), I must use :

{lat:48.8616138,lng:2.4442788,w:0.7653901}

That’s the shortest possible form – and not really human readable anymore when you have 10k of those -, and it takes 41 bytes. That’s almost four times as much.

Furthermore

Well, for starters, the (mostly correct) assumption that if you have a web browser currently capable of loading a URL, you probably have the necessary bandwidth to load the thing – or at least that the user will understand page load times – fails miserably on a mobile app, where you have battery and cell coverage issues to deal with.

But even putting that aside, the JSON decoding of such a large datasets was using 35% of my cpu cycles. Four times the size, plus a 35% performance penalty?

Most people who write webservices don’t have datasets large enough to really understand the cost of transcoding data. The server has a 4×2.8Ghz CPU with gazillions of bytes in RAM, and it doesn’t really impact them, unless they do specific tests.

At this point, I was longingly looking at my old way of running CGI stuff in C when I discovered the pack() function in PHP. Yep. Binary packing. “Normal” sized data.

Conclusion

Because of the large datasets and somewhat complex queries I run, I use PostgreSQL rather than MySQL or its infinite variants. It’s not as hip, but it’s rock-solid and predictable. I get my data in binary form. And my app now runs at twice the speed, without any optimization on the mobile app side (yet).

It’s not that JSON and other text formats are bad in themselves, just that they use a ton more resources than I’m ready to spend on “just” getting 30k numbers. For the other endpoints (like authentication and submitting new data), where performance isn’t really critical, they make sense. As much sense as possible given their natural handicap anyways.

But using the right tool for the right job means it goes both ways. I am totally willing to simplify backend-development and make it more easily maintainable. But computers work the same way they have always done. Having 8 layers of interpretation between your code and the CPU may be acceptable sometimes but remember that the olden ways of doing computer stuff, in binary, hex, etc, also provide a way to fairly easily improve performance : less layers, less transcoding, more cpu cycles for things that actually matter to your users.

  

[Ouch] The Joy Of Migration

So, out of the blue, and to escape from a dickish choke hold on my public facing infrastructure, I decided to switch back to administrating my own installation on a VPS…

First off, you think you are good at system administration when you have a lil server at home that has been running since forever and that you maintain, right? Wrong. Installing a production server from scratch is a totally different thing. You do not have the luxury of your comfortable habits and scripts that work just so on your tiny little environment. Everything has to be re-thought, as well as re-configured.

Private-facing daemons have to be secured (less than 4h after the original installation, I already had 3 script kiddies trying to brute-force my root password… seriously), everything has to be hooked up to talk to each other, some wanting to talk to localhost, others to the public facing IP address…

And then, you start setting apache up. Yes, I use apache rather than nginx. Sorry. I happen to know my way around apache (kind of), and nginx baffles me. Anyway… Let’s say that vhost management in apache is full of silent and deadly pitfalls. It took me 4h to realize that www.krugazor.eu and krugazor.eu didn’t actually point to the same thing. I will skip talking about LetsEncrypt for now, as I have many things to say about it, mostly positive, but the initialization process was painful, to say the least, although not all of their making. So, instead of ranting now because I haven’t slept much, I’ll save it for later.

I may go into specific details later, but suffice it to say that those were 24h full of “fun”. Yes, even though it prevented me from having a good night sleep, even though I have lost some hair, it is quite an intellectual challenge, and while the whole voodoo-vs-science tinkering reminds me a lot of programming, it feels good to “mentally masturbate” (as some of my friends call it) about a different topic.

I especially wanted to highlight the overwhelmingly positive factor that is Hover, which is just plain awesome. Their interface is clean and clear. Their rates are a steal. And the support I got for helping me with the DNS migration was just jaw dropping fantastic. A fella named Marty picked up the phone at 8:15 his time (.eu domains are ‘tricky’ to transfer), and while he was a thorough professional, the conversation felt no different than with any other of my geek friends, exchanging local news and anecdotes. 12h later that ‘tricky’ process was done and dusted, with a 20 minutes enjoyable phone call, and 4 emails. If that’s not a fantastic customer service, I don’t know what is.

As a conclusion, I will just say that if you find that some services and/or pages are broken, drop me a line!

  
Mood : tired