I think it can be a dangerous road trying to create abstractions over data
sources. It can be a lot of work maintaining a stub/mock implementation to
work alongside a database, and sometimes it's not that much more work (or
less work) to install Postgres, SQLite, or whatever you're using,
Hi Andy,
I'm not aware of such a project, but I can confirm that it is an approach
that we apply internally at AdGoji and has been working well for us. For
instance, we have (simple) components that mock Kafka and Redis in a way
that make them feature compatible to these services in the context
Hi Andy,
That was just an example I made up for the slides, and not a very good one.
Usually, the functions/protocols you implement for your components are
specific to your application.
–S
On Thursday, April 30, 2015 at 4:54:38 AM UTC+1, Andy Chambers wrote:
Hi All,
I'm trying to follow
Hi Andy,
We use component at SMX, and do follow an approach similar to the one you
hint at but as Stuart suggests we tend to have protocols that are more
application-centric.
For instance, we use Cassandra extensively and our general interaction
with that is captured by the protocol:
Hi All,
I'm trying to follow the component architecture for an app I'm working on
and wondered if I was missing something. In the Just enough structure
talk, one of the examples Stuart presents is a DB component that contains
just a small selection of DB related functions (i.e. insert, and
