--
Updated in August 2023 with Storyblok and Apollo Studio additions
At Lab Digital we are passionate about building good software and doing that efficiently and effectively. That means that we try to avoid reinventing the wheel where we can. This quite often leeds us to the creation of open source packages that can be used across many of our projects. For many years already.
We could keep the technology to ourselves, but we feel this is a waste. Releasing them as open source projects has many benefits; one of them being the quality we want them to have — these modules being a showcase for potential colleagues and clients — we want the modules to be inherently of high quality; which in turn makes them great to use for ourselves and the community.
We notice that releasing our building blocks as open source software and encouraging everyone in our company to use it, is a way of sharing (and reusing) knowledge internally. Many people contribute to the modules or can find colleagues who have contributed before. This leads to consistency across projects and taking learnings from previous projects, ultimately allowing us to focus on innovations rather than stuff we’ve done before.
Releasing our building blocks as open source software and encouraging everyone in our company to use it, is a way of sharing knowledge internally.
Our Github has grown to 80+ public repositories, containing projects that cover many different types of software; lots of Django/Python projects, front-end repositories, native app modules, etc.
In the below list we focus on the MACH & Composable modules, which is an important area of expertise of our company. These projects are actively used in our projects on a daily basis.
MACH composer is our open source approach to building MACH platforms. It encompasses all of our best practises and patterns in a technology agnostic (and with that, future proof) way, supporting many types of use cases — it ‘shines’ both for ‘single site’ projects, as well as ‘many sites’ use cases in which multi tenancy is important.
It is both a development and deployment tool, as well as a methodology for building e-commerce platforms in a modern way. We use it for all of our composable projects. This gives us a high degree of sharing knowledge, tools and approaches between teams, regardless of the teams’ technology stacks. You could see it as our ‘MACH umbrella’.
The MACH composer framework itself: our way of building composable architectures; giving the team a way of working & structure for modelling modern composable architectures. We’ve adopted it for all of our MACH projects, regardless of underlaying technology (i.e. different clouds, different programming stacks, different SAAS services, etc).
Several platform plugins for integrating with your favourite SAAS
Read more about MACH composer on the website: https://machcomposer.io or get started with its documentation.
When we started with commercetools, we immediately started with creating our own software around it, because we felt some essential tools were missing. The Terraform provider for commercetools is the most important one for the community. But the Python SDK was very important to ourselves specifically, being a Python shop (and these days more and more TypeScript, btw) and having no Python SDK available at the time.
The commercetools Terraform provider: manage your commercetools configuration through the 1st class infrastructure-as-code tool Terraform. Without this, you’d end up with creating one-off bash (or python) scripts for managing you’re configuration. Not very scalable :-). This module is endorsed by commercetools itself.
Go SDK commercetools: initially created to power the Terraform provider (which you build in Golang). These days a complete Golang SDK for commercetools. So if you want to build against commercetools with Golang, you can use this.
Python SDK commercetools: fully featured Python SDK for commercetools, with extensive testing tools in it as well (including a mock server you can start up). Many of our sites have been using this SDK in production for years. And the commercetools ML team implements this SDK as well!
commercetools node mock: commercetools rest API mock library for TypeScript/NodeJS based development. Saves you from writing a lot of boilerplate code.
Commercetools Mock server: docker container that spins up a http server that mocks commercetools. Use this for your acceptance tests that you don’t want to rely on commercetools itself for.
Commercetools token refresher for AWS SSM: AWS Lambda function that rotates commercetools tokens at a given interval.
Commercetools-federated-schema: library for federating commercetools through a GraphQL gateway servers. This library handles the schema stitching & extensions/overrides.
Terraform-module-commercetools-mc-app: terraform module for spinning up the AWS infrastructure for a custom merchant center application. Basically AWS Lambda@Edge, Cloudfront & S3.
commercetools-utilities-javascript: several javascript utility functions for working with commercetools, for example creating an API http client.
Worth mentioning is that we’ve recently contributed the Golang, Python and JSON generators to the commercetools SDK code generator, rmf-codegen, which is used to build the official SDKs. This means that our SDKs for Python and Golang can be generated and maintained in exactly the same way as the official commercetools SDKs. This makes it easier to keep them up to date and consistent with those SDKs.
More recently we’ve started with working with Amplience CMS. And of course we started with creating tools around that as well. Starting with creating a Terraform provider for Amplience, so that we could properly manage its configuration in our projects (and connect it to MACH composer). And tools around leveraging GraphQL for Amplience.
Terraform provider Amplience: properly manage your Amplience configuration through infrastructure-as-code.
Golang SDK Amplience: Golang SDK focussed at creating the Amplience terraform provider. Not usable for building sites (yet).
Schema-generate: GraphQL code generation for Amplience. Read about this in our previous blogpost.
graphql-codegen-plugin-amplience: successor of schema-generate.
See our other story around using code generation for creating a GraphQL server for Amplience.
While we are not super active with Contentful, we’ve adopted two essential modules for it: the Terraform provider created by contentful itself, and the underlaying Go SDK. Both projects we’re abandoned by contentful, and we decided we wanted to use them in our projects.
These modules are not as polished as our other modules, but are actually used in production for some of our sites.
Storyblok is the most recent CMS we’ve started implementing at Lab Digital. And when embracing new technologies like these, we want to apply our proven approach using Terraform providers and MACH composer.
So when starting with Storyblok, we created the nessesary tools for it:
Terraform-provider-storyblok: as the name implies, a terraform provider for managing Storyblok CMS using infrastructure-as-code
Storyblok-go-sdk: to power the Terraform provider, we created the Go SDK for Storyblok. To do this we started with creating an OpenAPI spec to generate the SDK from, which was unfortunately not available from Storyblok itself.
Storyblok-graphql-codegen-terraform: as you might know, we like to use GraphQL to power our front-ends. And to have full control over that, we define GraphQL schema’s ourselves. In order to keep these in sync with configuration of content types, we use GraphQL to generate the right Terraform configuration for us.
For implementing GraphQL Federation in composable projects, which we’ve written about extensively, we often leverage Apollo Studio to automatically verify our schema’s and facilitate team collaboration.
In ordere to manage our Apollo Studio configuration using MACH composer, we’ve created the appropriate tools for this.
Terraform-provider-apollostudio: managing federated sub graphs & sub graph schema’s using terraform.
Apollo Studio Go SDK: for powering the Terraform provider, we’ve created a simple Go SDK to interact with Apollo Studio.
For AWS we’ve built several modules over the years, and most of them are useful in MACH context, but used outside of that as well — mostly when hosting classic infrastructures using ALB, ECS and RDS. It turns out that using those services in a serverless context is quite useful at times as well!
Terraform-provider-taskrunner-aws-ecs: Terraform provider for running one-off tasks in ECS synchronously. We use this to execute application database migrations during deployments, where other resources need to wait for this.
Django-IAM-dbauth: AWS IAM authentication for Django database backends (RDS MySQL and RDS PostgreSQL supported).
Python-param-store: Python module to store secrets in secret stores, such as AWS EC2 Parameter Store.
Django-cognito-JWT: AWS Cognito JWT validation for Django-REST-Framework.
ECS-Deplojo: deployment tool for deploying docker applications on ECS.
Terraform-AWS-static-site: Terraform module for hosting static sites on S3. Includes basic authentication through Lambda@Edge.
React Loqate: a slightly different type of project for integrating Loqate, which we often use for location-based services in our MACH projects (i.e. address validation & completion).
NextJS basic auth middleware: a module to add basic authentication to your NextJS application. Useful for test & QA environments!
Do you like working with like-minded craftsmen and women, have a passion for open source and like working in a fast-paced agency where you can learn a lot within great work/life boundaries?
Look no further :-) at our company you’ll get ample opportunity to work on high profile projects, while at the same time bringing our industry to the next level through our open source efforts and projects.
See our careers page for open positions, or contact me through LinkedIn!