Boutique Principles

[mergesort]

I've heard a lot of great feedback on Github and wanted to thank you all for your contributions. Whether it’s code, suggestions, documentation, or sharing your experience of using Boutique and Bodega, it’s all been very meaningful and honestly a bit overwhelming (in the best way possible). I would especially like to thank @samalone, @pofat, @icanzilb, and @StefanCosminR for your help.

I wanted to start a separate discussion that incorporates all of that feedback I’ve received, and synthesizes it into the direction I’d like to take Bodega in the next version and beyond. My goal is to address all of the needs and use cases raised, but in a way that adheres to three principles for Boutique to follow.

---

Principle 1: Boutique must have a simple API

One thing that makes Boutique different is that integrating Boutique is incredibly simple. Simple means two things.

1. It’s accessible to both beginners and experienced programmers alike.
2. You shouldn’t have to think about how to use it, you should spend your energy focusing on building your app.

Principle 2: There must be cache consistency

Boutique’s disk cache and memory cache must stay in sync. This is to ensure that what’s in memory is always an accurate representation of what's saved to disk, and that a developer can feel confident that they are not at risk of losing user’s data.

Principle 3: Users expect good performance

This may seem obvious but Boutique must be usable in modern apps and provide the performance users expect. To ensure optimal performance it’s important to profile changes, and to have the necessary infrastructure for doing so.

---

When there is a conflict with principles, we first opt for simplicity, then consistency, then performance. That may mean having to make a compromise, it could mean not building a certain feature, but most of the time it requires taking a step back and figuring out what’s really being asked, possibly coming up with a clever solution that ensures complexity isn’t exposed to the user.

---

The changes that have been proposed the last few days touch on all three of these principles. There have been some suggestions made to optimize performance that could require a more complex API, an example of where the principles come into conflict. This isn’t anyone’s fault, each individual suggestion has been a good one and rooted in specific needs and I intend to implement most of them! But taking in all of these ideas together rather than one by one means I could take a step back, and come up with a plan for next steps.

If you have thoughts on these principles please reply inline to this message, and if you have thoughts on the upcoming work please reply in #20.