I generally agree with Adam too, it's really important to have the right foundation in place or you (or someone else using the project) will regret it later.
I asked about whether it would be possible to implement a robust solution in mongo db because I've been working on an open source content management system / web app framework built on express and mongoose. The project hasn't been announced yet because I'd like to have better documentation, a getting started, and examples in place before I draw too much attention to it. That said, if anybody would like an early preview it's called Keystone JS and there's a simple demo up at http://demo.keystonejs.com My company has used it as the foundation of a few eCommerce sites (including http://www.bodymindlife.com, which we launched today) but they've got fairly simple requirements - just creating customers and logging purchases, there's nothing sophisticated like inventory management. However we're really happy with Keystone for content management and I'd like to explore turning it into something of an eCommerce solution. If it can be done (for example implementing a subsystem using redis or another secondary database to ensure things happen safely) then having the store content and customers managed with Keystone might be really good. Of course, it's not a good idea to use the wrong tool for the job - you'll just end up fighting with it... Then again some people may have said that about using javascript for your back-end ;-) The question is can we build a robust solution on top of mongo (*or*alongside it with other systems) and if so, are people interested in building it with me as part of Keystone? Cheers, Jed. On Thursday, September 12, 2013 9:54:08 PM UTC+10, klr...@gmail.com wrote: > > no node expert by a long shot but I concur totally, am developing > international logistics solutions for others and also running them in my > own businesses since the 90ties and you've *got to play it safe* in this > area or (apart from your MD, CEO or whatnot) the first fiscal inspection > will pluck you to pieces as various taxes are directly affected. They just > *love* to detect incorrect inventory statements on your sheet so they can > e$timat€... You need to think very hard how to maintain the database > accurate in an async environment with multiusers and you have to carefully > design the statements or transactions that need to be executed in a certain > sequence if you want your app to scale correctly. Sorry for ranting and > raving like this but Adam is right. :-) > > On 12/09/13 13:12, Adam Reynolds wrote: > > The customer will care when the last item in stock is sold twice. You are > right, in the initial work, it's all about the pretty stuff, but the > backend implementation should be scalable as the customer grows. > > The last thing a customer wants to hear is that the solution works as > long as you don't have too much business. > > Seriously this ability to track stock accurately is the most important > thing to a business. Having spent a lot of my 13+ years in e-commerce > development, this stuff is absolutely critical. The 'design' is irrelevant > when the MD of a company wants to know precisely how much stock is in the > warehouse, and in your case, why we've sold 3 times as many products than > we have in stock, just because the site got busy after they ran an advert > on TV last night. > > ACID compliance has serious financial implications and is why people > keep harping on about it. It's really really really important. > > > > On Thu, Sep 12, 2013 at 11:56 AM, Alexey Petrushin > <alexey.p...@gmail.com<javascript:> > > wrote: > >> Customers doesn't care if there's MongoDB, CouchDB, MySQL inside this >> e-commerce stuff. >> >> Also, as soon as the goal is to build widely used open source e-commerce >> - it won't be a huge million user a day site (nobody uses simple open >> source shops at such scale), it will be a small, simple and easy to use >> shop. And on such a small scale - it's totally irrelevant how you implement >> it, it probably will works fine even if you decide to not use any DB at all >> and store all stuff in plain files. >> >> So, this discussion about DB choice is pointless. Would be more >> interesting to see what set of features it's supposed to have and where to >> get a cool design (the thing that unlike DB is really important) for it. >> >> >> On Thursday, September 12, 2013 2:38:19 PM UTC+4, Adam Reynolds wrote: >> >>> Lol "SQL is boring" >>> >>> Think you're doing it wrong :) >>> >> > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
