|
|
|
|
|
|
by fiedzia
3545 days ago
|
|
|
Generally it seems that you know what you are doing, so the idea looks good. However I've got few comments: 1. Lack of schema is a horrible idea, especially at the beginning. It may be necessary in some selected places,
but if that's your approach to data design you'll end up with unmaintainable mess that keeps tripping over differences in data interpretation and inserting garbage due to trivial mistakes. Then you'll be the one explaining to your clients that images are not being displayed because "imgaeid":"45" was found in place of expected "imageId": 45. It doesn't simplify anything. 2. I am not sure what resources do you have, but introducing innovative (and largely untested) language and various aspects of architecture all at once is very ambitious. Swift looks nice (though I prefer Rust), but both language and its libraries will be moving target for years, and that's pain even for languages that were well designed. Being event driven looks nice too... but I am not sure if anyone can figure out if its better to be 100% ED or maybe only 45 is just right. This might be to much to chew on. |
|
|
About your first point, I essentially agree with you. While I talk about "schemaless" data, I'm not really thinking on leaving it uncontrolled or letting each service write whatever they want to the DB. I'm thinking more on avoiding restrictions in the schema in order to extend the system for a specific retailer needs. We're planning to use a strongly typed programming language aiming for application-level data consistency, and we'll probably need to define a shared set of type definitions for the whole system and specially for the message passing protocol; but we also want to make it extremely easy to change so it can be adapted for the specific needs of each business.
About the second point, yes, we definitely know this is a very ambitious project, but it can be broken into smaller projects that are more approachable, so we can target a smaller objective and re-evaluate after the first iterations. We won't achieve everything we want in a single step, but I'm sure we can walk in that direction. Here's where I think the open source approach can make a difference if we catch the attention of enough people.
Choosing Swift is risky too, but we're really happy with that programming language and we believe that the only way to make it evolve to be a serious backend language is that some crazy people like us make a strong bet for it. And about the event-driven architecture, we believe that there are some specific problems in eCommerce that are specially suitable for this approach, but it's not definitely a silver bullet. For instance, the Magento core triggers all kind of events when different business objects are updated and we've found it to be really useful when you need to create an extension without touching the core. We see on events a way to decouple logic, so one module can trigger events without knowing who will be listening and the listeners can receive information without knowing who generated it.
So yes! This is crazy, but after many years on this field using the same tools, we're really excited with the idea of bringing it into life! :-)