By using this website you agree to our Cookie Policy
Back to blog

Archbee's architecture

Dragos Bulugean on 18 July 2018

We will talk a lot about architecture and software development throughout this blog so why not talk about our own? Let's get down to business and see how the sausage is made, the what and why's.

Language

We use TypeScript. For everything. Our app, website, blog & backend are all the way TypeScript.

But why? Well, we picked TypeScript because it's one of the few static typed languages out there that has a good story on both frontend and backend development. Using the same language does wonders when you can share data structures between different parts of the system, because your system will be type-safe. Or let's just say type-safer :).

Obviously, there are better languages that fulfill this requirement. Like PureScript, ReasonML, Kotlin,Scala+Scala.js or F#/Fable. But all of them have a weak-side. For example (in 2018) PureScript and ReasonML are not as good on the backend as they are on the frontend due to the lack of mature libraries. And the reverse happens with Kotlin and Scala. F# is pretty good on both, so we might consider it for next projects.
TypeScript is very good on both. You've got incredible React bindings, and ORMs on Node.js. Plus there's lots of developers out there that know TypeScript or can transition pretty easily from JavaScript.
TypeScript has a reputation of not having a strong type-system, but if you turn on the right flags for the compiler and try not to use classes, you've got yourself a winner.

Libraries/frameworks

React is the UI library that we use for our app, website and blog. It's mature, stable and has a great ecosystem. Combined with TypeScript, is a pleasure to work with, because everything gets type-checked. Including JSX/TSX - this is a feature very few language/library combinations have.

JointJS is a diagramming library that helps with handling all SVG work. All diagrams are a couple of layers on top of it. JointJS allowed us to get fast off the ground because we didn't have to write all the 2D geometry SVG interaction stuff. Basically a diagram is a React component with shouldComponentUpdate() always returning false and the rest handled by our layer on JointJS.

Glamorous is our CSS in JS library for the application. It's awesome because all CSS is defined as properties on HTML. You can write something like this: <Div backgroundColor={colors.blue} width={40} height={40} display="flex" flexDirection="column"/>
Unfortunately the library will be discontinued/unmaintained so we'll migrate to Emotion.
Emotion is what we use for CSS on our website&blog and gives you an experience close to what I've described on Glamorous.

Next.js - is what makes our site and blog happen. We need it because search engines are still in the 90's, so they need statically rendered html. But a very good thing is, it's blazing fast. It gets 90 at Google's PageSpeed or Lighthouse.
One consequence of using Next.js is that it's all static html. So the blog doesn't have any server running. No Wordpress shenanigans.

Node.js - runs the JSON API. Its evented asynchronous stateless nature has changed backend development forever. The JVM and .NET platforms are still very good and catching up on this architecture. We can see Spring Framework trying to make Spring WebFlux popular, but why would it become popular when Vert.x didnt? Plus most of the stack (JDBC) is not async so you're stuck using only NoSQL tech like MongoDB or Cassandra.

Express - is the library of choice for the API. Mature and battle tested, great ecosystem of middleware. Actually we have a nice layer on top of it that is similar to Nest.js but allows us to have a type-safe interaction between our frontend and backend. This is made possible through a generic Post function that takes Request and Response as type parameters and wraps the Fetch API supplied by all browsers. Every call gets made through this function.

Sequelize - is an ORM. We use sequelize-typescript for the bindings so we can annotate fields on our classes and get a lot of functionality for free because of it. All read functionality is done directly. Writing to our database gets done through a Amazon SQS so we don't overrun our database with performance expensive requests. This would happen easily because of the automatic-save feature for the boards. We do throttle it at 2 seconds for each client, but it's still not enough, so we need SQS. We contemplated using Apache Kafka, but for now a simple managed queue is enough.

MySQL stores everything. Not the best RDMBS for sure, but it's free, has a great UI using MySQL Workbench and is hosted by AWS RDS which makes things easier and hands-free.

Infrastructure

Archbee runs on AWS. That's because AWS has many good managed services.
We use Beanstalk for running our webserver. Beanstalk grabs a Docker image and runs it on 2 EC2 instances with a Elastic Load Balancer in front. Every instance has the Node.js process running through pm2 which starts 8 processes and load-balances between them. So we have double load balancing.
We tried to run our Node.js app on AWS Lambda, and it works perfectly, but the runtime + API Gateway is very inconsistent in response times. Some requests even last 6 seconds...

AWS RDS is awesome for hosting your database system. You get free automatic backups, performance monitoring, logging, migrations, alarms.

To summarise, pretty simple infrastructure so far.

The future

If our business continues to steadily grow like it does now, we'll invest in writing our own JointJS replacement that will allow us to do crazier stuff like generating code from some diagramming components like Types. Or even generate diagrams of your code through a command line tool we provide for you to run on your repo.
We might move to Apache Kafka from SQS and sink the boards into S3 instead of our RDBMS.
Might move to ReasonML or F#.

Here's a diagram ofArchbee's architecture . Of course Archbee is dogfooding :)

At Archbee we make it easy for you to create visuals for your software systems. Visuals are good for medium projects and great for larger projects as everybody has a clearer sense of what's going on in your system's architecture, and newcomers onboard faster.

Dragos Bulugean
Dragos is the founder of AiurLabs. Hit him up on Twitter or mail

Subscribe to our blog to get weekly content about software architecture,
development teams & other shiny stuff

Copyright © AiurLabs, Inc. All rights reserved