3 ms·
In my experience proper abstraction is the key. If you have a clear abstraction and structure you can replace the implementation when you need to without too mu
by 2muchcoffeeman 5y ago
In my experience proper abstraction is the key. If you have a clear abstraction and structure you can replace the implementation when you need to without too much disruption. If it’s too leaky you’re screwed.
- goodoldneon 5y ago100%! Create a good enough solution and put it behind an abstraction that remains stable when you later create an ideal solution
- hughrr 5y agoYes. Use a queue abstraction for which there are numerous queues available off the shelf for!
- aparsons 5y agoIn my experience, great abstractions without a good data migration blueprint is as about as useful as no abstraction at all. In this example - great, you have a “queue” abstraction. When you switch to RabbitMQ or Postgres, how do you move your existing data without a quality of service or data loss? It can be difficult with production datastores even if the abstraction within your service is beautiful.
- lolinder 5y agoIsn't migrating a queue super simple? Have a window in which you only add to the new system and you listen to both. When the old queue is empty, delete it. If you need to keep track of old data, then yes, migration is hard. But queues don't save old data—that's the point of a queue.