--- title: [The architecture of Archbee | Archbee Blog](https://www.archbee.com/blog/archbee-architecture) slug: archbee-docs/the-architecture-of-archbee-or-archbee-bloghttpswwwarchbeecomblogarchbee-architecture docTags: createdAt: 2025-12-02T10:42:39.000Z --- [\<-](https://www.archbee.com/blog) [ Back to main blog](https://www.archbee.com/blog) Company UpdatesUpdated: **March 27, 2023** ![Dragos](/_next/image?url=%2Fauthors%2Fdragos.jpg\&w=96\&q=75) Dragos Founder, robot with feelings. From planet Aiur. [http://twitter.com/happydragos](http://twitter.com/happydragos)[https://www.linkedin.com/in/dragos-bulugean/](https://www.linkedin.com/in/dragos-bulugean/) We explore how Archbee Wiki is being built. Architecture, code, libraries ![The architecture of Archbee](/_next/image?url=%2Fblogs%2Farchbee-architecture%2Fthumbnail.jpg\&w=2048\&q=75) 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: :::BlockQuote ::: 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 [https://archbee.io/app/public/board/archbee](https://archbee.io/app/public/board/archbee)Archbee's architecture: ![](/_next/image?url=%2Fblogs%2Farchbee-architecture%2Ffiles%2F5f731607bd372007100643c1_12.JPG\&w=3840\&q=75) ## #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. # Documentation, technical writing tips and trends Blog Join 5000+ people from around the world that receive a monthly edition of the Archbee Blog Newsletter. [Enter your email]()Subscribe ## Continue Reading Discover more insights and expand your knowledge [![From Nothing to v0 Docs in One Minute: Introducing Documentation.new](/_next/image?url=%2Fblogs%2Ffrom-nothing-to-v0-docs-in-one-minute-introducing-documentation-new%2Fthumbnail.png\&w=1080\&q=75)](https://www.archbee.com/blog/from-nothing-to-v0-docs-in-one-minute-introducing-documentation-new) [Company Updates](https://www.archbee.com/blog/from-nothing-to-v0-docs-in-one-minute-introducing-documentation-new) ### [From Nothing to v0 Docs in One Minute: Introducing Documentation.new](https://www.archbee.com/blog/from-nothing-to-v0-docs-in-one-minute-introducing-documentation-new) [Documentation.new turns a link or short prompt into a structured draft of your product docs, ready in under a minute and deployable in Archbee.](https://www.archbee.com/blog/from-nothing-to-v0-docs-in-one-minute-introducing-documentation-new) [![New Playbook! Sales Knowledge Redefined. Lost info? Lost Leads.](/_next/image?url=%2Fblogs%2Fnew-playbook-sales-knowledge-redefined-lost-info-lost-leads%2Fthumbnail.jpg\&w=1080\&q=75)](https://www.archbee.com/blog/new-playbook-sales-knowledge-redefined-lost-info-lost-leads) [Company Updates](https://www.archbee.com/blog/new-playbook-sales-knowledge-redefined-lost-info-lost-leads) ### [New Playbook! Sales Knowledge Redefined. Lost info? Lost Leads.](https://www.archbee.com/blog/new-playbook-sales-knowledge-redefined-lost-info-lost-leads) [The New Archbee Sales Playbook teaches how to stop losing deals because of lost knowledge.](https://www.archbee.com/blog/new-playbook-sales-knowledge-redefined-lost-info-lost-leads) [![Archbee Playbook - Agentic GTM Engineering: 10x Scaling Without 10x the Work](/_next/image?url=%2Fblogs%2Farchbee-playbook---agentic-gtm-engineering-10x-scaling-without-10x-the-work%2Fthumbnail.jpg\&w=1080\&q=75)](https://www.archbee.com/blog/archbee-playbook---agentic-gtm-engineering-10x-scaling-without-10x-the-work) [Company Updates](https://www.archbee.com/blog/archbee-playbook---agentic-gtm-engineering-10x-scaling-without-10x-the-work) ### [Archbee Playbook - Agentic GTM Engineering: 10x Scaling Without 10x the Work](https://www.archbee.com/blog/archbee-playbook---agentic-gtm-engineering-10x-scaling-without-10x-the-work) [The new Archbee Playobook - Agentic GTM Engineering - shows you how to automate workflows, streamline campaigns, and grow efficiently.](https://www.archbee.com/blog/archbee-playbook---agentic-gtm-engineering-10x-scaling-without-10x-the-work)