The Firebase ecosystem offers quite a lot of advice on how to structure your data within Firestore — don’t normalize, use subcollections and so on. However, most of these tutorials only cover cases for scenarios where there are many independent users that create or change data. There is little advice on how to build a team-based system, where users are grouped into accounts or tenants.
In this article, I’m going to share the setup I thought of while building such a system. I will focus mainly on the general architecture and don’t go into too much detail of the implementation…
How come so many people who smoke believe that life ends anyhow at some point, so why not enjoy it in the meantime?
Why do so many entrepreneurs with failed ventures argue that it was worth all the effort for the learnings?
And what is the reason so many divorced couples can only see the bad attitudes and habits in each other?
Cognitive Dissonance can provide an answer to these questions. First described in 1957 by Leon Festinger¹, Cognitive Dissonance is the uncomfortable feeling one experiences when two ideas one holds clash with each other — often a certain behaviour…
Firebase and Google Cloud Platform offer an excellent way to build apps and systems that can rapidly scale while providing a fantastic developer experience. At EstateSync, we use GCP services as the backend for our API to allow the fast distribution of real estate data to multiple vendors. Given the requirement to be able to scale to large amounts of data, we built our architecture on the premise of asynchronicity.
Because of this, there is an obvious need to keep users informed about what is going on within the system.
Naturally in an asynchronous system, we can only provide the…
We live in a world that is strongly influenced by a high level of connectedness — to not turn mad, we need to filter out certain things. This filtering is often not done by ourselves, but rather (social) media, which is in turn motivated to supply us with the content most likely to satisfy our cravings. It creates a notion of needing to „be better, be happier, be smarter“ and a focus on what we might lack instead of what we already have.
On top of that, society promotes that negative feelings are not ok. By showing us only „feel…
When developing new systems it’s usually easy to pay attention to creating modular structures and adhering to the Single Responsibility Principle. As a consequence, one often builds modules that take care of a specific task first and then uses them later in the business logic.
However, this often comes with a downside: These systems are usually tightly coupled because the business logic depends directly on the low-level module.
Dependency Inversion suggests changing („inverting“) this relationship. Instead of directly referencing the low-level module, one ought to reference its abstraction.
In software architecture interfaces are contracts that define no behaviour themself but that other modules must adhere to. They allow the consumer of a module to know how to talk to the module without having to know about details of it.
Interfaces are like an image you have in mind of the cashiers at a cinema. You know that you can tell them what movie you want to see and where you want to sit. You know that they are going to ask you for money and that you can give them money. Also, you expect them to hand you…
Inheritance is a powerful feature in software architecture, especially given the ability to override the behaviour of a base class. If you want to, you can extend a basic class and change its behaviour completely.
This leads to the question of when inheritance should actually be used. Why not use composition instead? How do you know if you should implement a new feature by extending something that already exists and just modify its behaviour or by choosing a completely different pattern?
Bertrand Meyer first brings up the “Open Closed Principle” in 1988 by writing the famous words
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
What that means is that there should be little need to modify existing code if we want to implement a new feature. At first, this seems a little contradictory because software changes all the time and so does its code, right? What about refactoring or even fixing bugs?
Let’s look at a concrete example to understand what the principle is trying to promote. The following example is written in…
In software development the concept of building complex structures out of basic blocks is omnipresent, be it in the form of classes, components or modules.
According to the SOLID principles, each of these basic blocks should only have one job and defer additional jobs to other modules.
For example, let’s say one wants to react to an event that is thrown within an application. The event should be persisted to the database and a notification email should be sent to users. …
Laravel provides neat testing helpers for working with the filesystem –however if you run your tests in parallel, issues are inevitable.
At Exposify we use the Storage Facade of Laravel to fluently access files and store data. It also makes writing feature tests much easier because it automatically swaps directories and cleans them up before running other tests with
We also use Paratest to let our PhpUnit Tests run much quicker by using multiple processes.
The thing is: As soon as you have multiple processes running, some tests will be executed before others are finished. This means that Laravel…
Co-Founder at Exposify and EstateSync.