Our Tech

Substi is still in stealth mode, but it’s important that we get the tech right from day 1. If you make the wrong choice now and suddenly find massive growth when you go live it can be disastrous if you can’t scale to keep up.

If you’re interested in a technology deep-dive, buckle up and read on.

There are a whole heap of competing technologies in this space and we’ve tried all of them in our other day jobs. For Substi we’ve gone all in (almost) on microservices. Our back-end is all Node JS micro services running on kubernetes on Google’s Cloud Platform. Kubernetes will allow us to scale to meet load across regions and data centres. We chose Node over more conventional back-end languages purely because it allows us to maintain our entire code-base (front, back, middle and side) in a single language – which is great for things like automated test code coverage tooling, scanning for security issues, reporting on styles and other code management type things.

Substi makes heavy use of Pub/Sub… a popular methodology for notifying disparate parts of a system about things that are happening and ensuring messages don’t get lost if systems are overloaded. Many of the subs here are cloud functions. This is the almost mentioned earlier. Instead of having our own containers here we’ve delegated to Google to handle scale and load and retries on these subscribers. But Google’s Cloud functions VMs run Node 8 so our codebase is still the same javascript regardless.

We make heavy use of firebase for real-time data and authentication. Firebase uses websockets so that changes to the data on the server reach all the clients who are interested in real-time. It’s perfect for a system like Substi where people want to know in seconds when a job has been accepted, cancelled or declined. No refreshing, no waiting, the system just lets everyone know.

Security is obviously critical to any system. But even more so if the consequences of getting it wrong have actual real-world consequences like not getting a job for a few days. That’s why we use firebase for auth. Going forward it will allow us to plug in other auth providers but at a minimum it’s got a proven security model direct to the real-time db and to our microservices. Short lived javascript web tokens are passed on every API call and the microservices verify that the associated user is allowed to call it. And just a note on security around credit cards; we never pass credit card details to our own servers, they get sent direct from the app or web browser of the user to our payment gateway where the details are tokenized and sent back to us. The tokenized form is useless to anyone except us should they get their hands on it (though it is also nearly impossible that they could since all our traffic is ssl encrypted).

Our front end is React and React-Native, a js app framework made by the very clever people at facebook. It’s a robust view layer that takes care of reconciling the ‘state’ of the application with what the end-user sees and requires very little bootstrapping so our devs should be able to iterate quickly and add features without getting bogged down in lots of regression testing and breaking changes!


Comments (0)

Leave a comment