Use of Node / Express / MongoDB for a e-commerce website?

[Hakan Guzelgoz]

Hi there,

I am planning to use ExpressJS & MongoDB for a e-commerce website for something that would have similar functionalities like groupon. Clients would simply view the various pages and be able to purchase or book some of the offers - and pay online.

I was wondering if any of you had experience with Express & MongoDB for such an "easy" e-commerce website. What kind of problems / solutions would you see or suggest?

Many thanks,

Hakan

[Adam Reynolds]

You use an ACID compliant DB for e-commerce. This excludes Mongo. 

--
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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Hakan Guzelgoz]

Hi Adam,

I can see the need for ACID compliant DB. What would you suggest in that case with Node / Express?

Thanks,

Hakan

[Karl]

Postgresql, mysql (or the Mariadb mysql dropin, haven't tested that myself yet with node)

[Hakan Guzelgoz]

Ok, but is there any live e-commerce website running on Node? I mean I would love to have their feedback / experience - what to consider or to take care of?

Thx,

Hakan

--

[Karl]

there was a discussion on this list under "Re: [nodejs] Re: NodeJs e-commerce solution?" and I recall they run something at urbantouch.com

[Alex Kocharin]

 

Wrong. 

 

I believe here http://www.mongodb.org/display/DOCS/Schema+Design#SchemaDesign-Videos are videos with some talking related to e-commerce. And mongodb does this job quite nicely.

--
// alex

 

 

22.10.2012, 14:04, "Adam Reynolds" <awjre...@gmail.com>:

[Alexey Petrushin]

If You plan to use JSON Rest API and something like Backbone.js - then maybe it's a good fit. If on the other hand You want something like traditional site with lots of forms and server-side templates - node won't be a good fit. 

It looks more like a specialized high performant server, not a high productivity tool for building sites.

For its high performance You'll pay with degraded development productivity.

P.S. Does anyone really estimated how much will be losses in case of some (0.00...X) transactions lost due to lack of transactional support in mongo?

I mean in stores like amazon - it's not a question, losses are huge, but in case of an ordinary e-shop? Are they really so big? One developer cost about 100 / per-year, so, mongo allows to build product faster and thus save cost on development time (although, it's also subject to question). The question is - what's higher - cost of development or lost transactions.

[Adam Reynolds]

You use the right tool for the right job. In the case of e-commerce you really do need transactions. Traditional databases do this very well.

It's not that you can't do this type of stuff in Mongo but you really are hammering a square peg into a round hole. It becomes complicated.

[Eric S]

On Tuesday, October 23, 2012 2:26:40 PM UTC-7, Alexey Petrushin wrote:

P.S. Does anyone really estimated how much will be losses in case of some (0.00...X) transactions lost due to lack of transactional support in mongo?

I mean in stores like amazon - it's not a question, losses are huge, but in case of an ordinary e-shop? Are they really so big? One developer cost about 100 / per-year, so, mongo allows to build product faster and thus save cost on development time (although, it's also subject to question). The question is - what's higher - cost of development or lost transactions.

Hard to say, it really depends on how stable your system is.  We had some problems with a computer that until we fixed it, it was crashing several times a day.  We were stuck with a proprietary, non-ACID database on that, and the data corruption was rather frustrating.  On the other hand, I suspect that mongo wouldn't be as popular as it is if it were as much of a pain as this was to repair after a crash.

I suspect you're thinking strictly in terms of lost sales.  That's the smallest of the three issues I see.  Yes, lost sales are one possible problem.  Getting your database back into working order is another possible problem, as both an expense in man hours and site downtime, with the amount of work dependent on quite a few things.  The last factor, and probably the most important one in my opinion, is lost reputation.  If you bought something online, never received anything, and when you contacted the seller, they said that they had no record of your order other than the CC charge, would you EVER use them again, even if they promptly refunded your money?

[Adam Reynolds]

This. This beyond anything else. You would have a major problem with customer trust. 

On a side note you can google mongodb transactions and see the hassle/failure people have had trying to make transactional processes work within Mongodb. It really is the wrong tool for the job at the (moment).

[Karl]

Trust is a big asset, I saw a recent study somewhere that webshoppers seem to be considerably more loyal than one assumes. More reason not to take chances. Risk taking was what got us into the current complex situation (I'm in Spain)

[Hakan Guzelgoz]

What about a combined solution between MongoDB and Mysql where you would use Mysql only for the transaction side of things and Mongo for all the rest? Would this be worth investigating?

--

[mlegenhausen]

We build a e-commerce system on top of node, express and mongo and for my next ecommerce system I would use node, express again but not mongo. Cause when you have no ACID you need to do it your own and that can be very error proune, complicated and takes very much time!

When you use both keep in mind that transfering data between both databases needs to be ACID too. My advice would be to start with MySQL or Postgres and then when you really need it use something like mongodb. Maybe you should keep a look on Postgres and the Foreign Data Wrappers (fdw). Where you can integrate mongodb (or other databases) in your SQL Database.

[Alexey Petrushin]

> I suspect you're thinking strictly in terms of lost sales.  That's 

> the smallest of the three issues I see.  Yes, lost sales are one 

> possible problem.  Getting your database back into working 

> order is another possible problem, as both an expense in man 

> hours and site downtime, with the amount of work dependent 

> on quite a few things.

You are saying that biggest problem is that MongoDB allows DB to end up in inconsistent state that causes errors in the Application and makes the Application unusable untill the DB is fixed by hands.

I agree with You - it's the biggest problem with no-ACID database, but it's not in any way related to E-Commerce.

[Murvin Lai]

though Mongo is not ACID .  however, when i raised that question to 10gen during a training, one of the solutions they suggest is to do it in code with two handshakes for committing data.  not pretty but dorable. 

My suggestion is like that:

For DB, split it into two parts.   Anything non-transaction related, (e.g. user data, page content data), use Mongo.   Anything to do with transaction & payment, use MySQL.  That you will get the best of two.

For Front end, depending on how you wanna do it.  But for small project, I will just stick with Node.js (express) and do it all. It's just like normal webpage may be with some CMS functionalities.  

--

[Ted Young]

Just some warnings against mongo being a magic bullet:

P.S. Does anyone really estimated how much will be losses in case of some (0.00...X) transactions lost due to lack of transactional support in mongo?

I mean in stores like amazon - it's not a question, losses are huge, but in case of an ordinary e-shop? Are they really so big? One developer cost about 100 / per-year, so, mongo allows to build product faster and thus save cost on development time (although, it's also subject to question). The question is - what's higher - cost of development or lost transactions.

I think there are reasons why mongo is useful, but saving on developer costs is not one of them.  When I hear people argue this position, they usually don't know much about mongo (and a lot of times aren't big on databases in general) and their hope is that they can build a web application without having to learn how their db works or how to administer it (or rather, learning mongo is much easier than learning mysql).  I'm not saying people are dumb for hoping this will work, but I do believe it's incorrect and is based more on PR than reality.  Having used both, my opinion is that all db's are complicated and it takes a fair amount of knowledge and effort to not screw it up when the stakes are high.  If you want to speed up development (regardless of db), you can outsource the db work for a while and get consultants to train you and help you set it up and use it properly.  

though Mongo is not ACID .  however, when i raised that question to 10gen during a training, one of the solutions they suggest is to do it in code with two handshakes for committing data.  not pretty but dorable. 

This is total marketing FUD, Murvin I am glad you didn't buy it.  Any form of saying "just implement transactions yourself in your application" is pretty damning - that's a *huge* burden the db vendor has just foisted onto your dev team.  You are not going to be saving any developer cycles if you have to do that.

I'm not saying "don't use mongo ever."  Just don't use mongo because you think it will be easier than mysql, especially if you need transactions (which you will if you are doing commerce).  And if you're building e-commerce and handling transactions and money, you should have staff dedicated to db operations and security very early on in your startup.  You can't measure how badly things will go if going got messed up, it's impossible to make a judgement like that ahead of time.  It's an important enough part of the system that things will move faster if you have someone handling it full time.

Again, not anti-mongo, but I see a lot of dev's pinning their hopes on it being a magic pony (and a lot of marketing encouraging this), and it make me want to slap a big warning label on it.

Maybe postgres + elastic search is what you are looking for?  It's a pretty winning combo if you're building a store.

Ted

[Alexey Petrushin]

I like mongo (although I'd choose to drop its performance and go with ACID instead), but, working with two databases, or do transactions manually (two handshakes, CQRS / event stream, ...) - those are things that You should try to avoid.

Use mongo if You like it and it meets the requirements, or use RDBMS if not, but don't invent Your own database (unless You really has to).

[Alexey Petrushin]

> I think there are reasons why mongo is useful, but saving on developer costs is not one of them.  When I hear people > argue this position, they usually don't know much about mongo (and a lot of times aren't big on databases in general)

Hmmm, I spent a couple of Years working with JEE and Oracle big part of it - fixing and optimizing SQL queries - this work made me totally hate all this stuff, so, I'm biased a little against RDBMS. 

As for developer productivity - I mentioned there that this is an open question (lack of ACID is a big pain in the ass) - I personally feel (just feel, didnt measured it exactly) that code for document oriented database ends up more simple and flexible, and just looks more nice.

> If you want to speed up development (regardless of db), you can outsource

I'm not so sure about it, if You want to speed up via people - You should go for - get clever people, not get more people.

[mlegenhausen]

@tedsuo good that you say it that directly. If someone had say it to me I hadn't build a ecommerce system on mongo. It is a myth that mongo increases productivity. Of cause the first steps will go faster, cause mongo simply has less features. You don't need to define schemas, don't have to thing about transactions and so on. But does anyone program in this way? It is the same as I would say I don't have to thing about data structures, software architecture or consistency... in generell (and what would everybody say) start with MySQL or Postgres or any other ACID Datastore. Don't run multiple datastores at once (except redis ;)) you really don't need it. Thing about your data model. Use one of the available ORM for node. That don't sound that good as NoSQL and the other stuff. But it will make your life much easier!

[Stephen Handley]

re: the idea of using sql for some transactions and mongo for an object store 

http://www.citusdata.com/blog/51-run-sql-on-mongodb

http://www.craigkerstiens.com/2012/10/18/connecting_to_redis_from_postgres/

http://wiki.postgresql.org/wiki/Foreign_data_wrappers

[Dan Milon]

Still, postgres foreign tables do not support SQL transactions, which
you'd need for an e-commerce product.

But its definitely interesting.

[jmartins]

Use Postgresql 9.2 now it's have HSTOR a key/value json support, can scale linearly to 64 cores, read queries can be up by 4x faster

See more: https://postgres.heroku.com/blog/past/2012/3/14/introducing_keyvalue_data_storage_in_heroku_postgres/

Other option is use NEO4J it's ACID.

regards

Joao Martins

[Sam Stainsby]

On Wed, 24 Oct 2012 12:44:32 -0700, Alexey Petrushin wrote:

> Hmmm, I spent a couple of Years working with JEE and Oracle big part of
> it - fixing and optimizing SQL queries - this work made me totally hate
> all this stuff, so, I'm biased a little against RDBMS.
> As for developer productivity - I mentioned there that this is an open
> question (lack of ACID is a big pain in the ass) - I personally feel
> (just feel, didnt measured it exactly) that code for document oriented
> database ends up more simple and flexible, and just looks more nice.

Newbie question: is it feasible to use mongo for most things, and where
transactions are really necessary, augment it with something like
Zookeeper/Cages. Might be a lot slower for those operations .. but maybe
worth it if they are infrequent? Does anyone have experience with this?

Cheers,
Sam.

[John Puddifoot]

We've been using nodejs, express and mongo in ecommerce apps for around a year.... 

Now we're getting into a whole new thing using this structure for a backend to a new open source ecommerce system - http://traider.io/ - it's only in it's infancy, and it's looking for contributors (and constructive feedback). 

Would be very, very pleased to hear more on other dev's experiences with this stack!

find us on the web: https://www.eastpoint.co.uk/
follow us on twitter: https://twitter.com/EastpointS
like us on facebook: https://www.facebook.com/eastpointsoftware

This e-mail and its attachments contain information which is private and confidential and is intended for the addressee only.

If you are not an addressee, you are not authorised to read, copy or use the e-mail or any attachment.  If you have received this e-mail in error, please notify the sender by return e-mail and then destroy it. The views expressed in this e-mail and any attachments are personal and unless stated, do not represent the views of Eastpoint Software Limited. Furthermore, Eastpoint Software Limited will not be bound by this e-mail.

[yota]

在 2012年10月22日星期一 UTC+8下午5:50:31，guzelgoz写道：

hi  Hakan , 

   have you finish you project build a e-commerce website use nodejs & express & mongodb?