[javiertoledo]

At my company we're starting to build a next generation open-source e-commerce platform, and we believe it makes a lot of sense to use Swift as the main programming language given its popularity, performance, and functional spirit. We know that this won't be an easy road given that using Swift in the server is new, but that makes the quest even more interesting for us, and we think that strong initiatives like this one can benefit the overall Swift community. We'd love to get some feedback about this idea, and we're very welcoming to anyone who’s interested in helping.

[fiedzia]

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.

[javiertoledo]

First of all, thanks for your feedback, I really appreciate it.

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! :-)

[ckluis]

Not a dev, but as someone who has used shopify and set up many of the wordpress ecommerce solutions - I have strong opinions on the UX of ecommerce. Let me know if I can help.

[javiertoledo]

On first stages we will be targeting the business logic side of the equation, but we're completely open for collaboration. We are in Gitter and google groups, feel free to join us. You have the links in our homepage: http://swingcommerce.org