When we consume REST, GraphQL, or RPC APIs from the frontend, most of the time these api calls just end up being translated into SQL statements on the backend.

So why don’t we just write SQL in the frontend to begin with?

I’m serious.

To ensure a snappy app, we usually need a normalized cache on the frontend. When we start trying to do optimistic updates is when things get complicated really quickly. Unless our frontend data model maps exactly to our backend model, we have to do a bunch of quirky, manual cache updates. Just check out Apollo’s guide…

tl;dr: Use top-level folders to group your codebase based on access rights (such as open source vs proprietary) and use a `git-subtree` approach to sync these folders to their own fully-functional monorepos.

In this post I will walk through the options and drawbacks of working with many-repos, and introduce the idea of the multi-monorepo.

Monorepos are great

You checkout a single repo. Tooling configuration (lint, style, etc.) can be shared across all packages. Make a change to some code in a package/service. Use your IDE’s refactoring to find all usages of the modified code. All dependent packages’ tests are run. Publishable packages are…

Vaughan Rouesnel

🇦🇺 Software Engineer living in Berlin

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store