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 & 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 weaker 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, WebSocket libraries and anything you can think of. It's the biggest ecosystem of libraries. 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 very strong type-system, but if you turn on the right flags for the compiler and try not to use classes, it is.
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"></div>
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 Google Cloud Pub/Sub 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 a queue. 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 Google Cloud SQL which makes things easier and hands-free.
Infrastructure
Archbee runs on Google Cloud. That’s because GCP has many good managed services.
Our build system (Google Cloud Build) builds Docker images and automatically deploys them to Google Kubernetes Engine.
We have the same GKE cluster running all environments - dev, qa, prod, and depending on the branch we push to.
We use Google Cloud SQL to host a cluster of MySQL database instances, and Google Memorystore to host a cluster of Redis instances.
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 Google Cloud Pub/Sub and sink the boards into Google Cloud Storage instead of our RDBMS.
Might move to ReasonML or F#.
Here's a very high-level diagram of Archbee's architecture:
How can Archbee help with your system's documentation?
Archbee Wiki provides an easy to adopt solution for documentation & knowledge sharing that is specifically tailored to software development teams. We've studied many teams and their workflows, we've identified common usecases and coded them into our software's DNA. When your team picks Archbee, you are guaranteed to see upsides like team happiness, synergy and productivity within less than 3 months of using our product.
.png)
