Developer environments and production parity

When I first started writing software, a common practice was to use an emulator or a lightweight version of something for your development environment. The most common of these were in-memory databases, things like SQLite and H2. They are lightweight, easy to use and easy to segregate. You didn’t need to worry about licensing or having a lot of resources for it to run. As machines have got more powerful and FOSS databases have become more mature, the reasons for not having a real database running for development are diminishing. The problem now seems to be more about orchestration. [Read More]

Mongo $or queries are slow

Mongo doesn’t appear to perform particularly well when querying large-ish collections with $or queries. For some reason, it can’t figure out which index to use and often ends up doing a COLLSCAN. Say you have the following document structure representing user transactions: [Read More]

Tight Coupling x Complexity

When building systems you will quite often have to make the tradeoff between having a system that is loosly coupled or one that is simple. When we think of tight coupling we tend to think of it as a bad thing. But that is not always the case, you need to understand what you are being tightly coupled to. A common example of tight coupling people give is database queries, most of the time people will advocate using ORM as it offers a loosly coupled way of connecting to a database. In theory you can swap out your database server with another one. The reality is usally somewhat different, the chances are that you’ve leaked database speicific concepts outside of your ‘repository’ classes. You might be able to switch between similar types of database (MySQL to PostgreSQL for example) without doing anything but are you really going to be able to swap out MongoDB for PostgreSQL? I doubt it. Further more, you are tightly coupled to the ORM. [Read More]