Need some advice on shopping cart solutions without PHP..

[fuzzybabybunny]

I'm hoping for some advice on how to implement this.

I want to add a shopping cart component to my website - customers can select a service, go through a multi-step form process that allows them to:

1. configure their service with numerous different options
2. become educated on what the individual options are (a photo or demo of each option on each form page)
3. pay for it via their credit card

The order form shouldn't be a problem, but I'm not sure how to hook it up into a shopping cart and order checkout system.

I've looked at a lot of shopping cart software and they all have their own rigid order checkout process that is hard to use for a highly customized service such as mine. Plus all of them use PHP and MySQL. I've only learned Rails, Meteor, MongoDB, and PostGreSQL. I've heard bad things about PHP and MySQL. I really like the way MeteorJS does things but they use MongoDB and there's no support for MySQL.

Because they use PHP and MySQL, wouldn't this be very tough to do if I want to use Rails or Meteor and MongoDB? I'm also fuzzy on what the server configuration would be like with these different languages all running on the same website.

The shopping cart software currently available is critical because of all the additional backend admin features they provide, like keeping track of inventory levels, setting tax rates by state, running sales reports, cost reports, storing credit card numbers, etc. I do *not* want to code all this myself.

But they all use PHP and MySQL.

Any advice is appreciated!

 

[beginner99]

My 2 cents are I wouldn't use MongoDB ever as main storage. Maybe as cache backed by a REAL database.

Else:

https://www.google.ch/#q=ruby+shopping+cart

 

[fuzzybabybunny]

Ok, so after thinking more about this...

1. I need a pretty customized checkout process. This is a huge strike against using one of those free PHP/MySQL carts. And with MeteorJS a multi-page order form is child's play.

2. I really, really like the Pub/Sub and reactive nature of MeteorJS. I think it's the future.

3. I learned that I can do the actual credit card payments through the NodeJS API of https://stripe.com/ And Stripe provides reporting as well. Meteor is built on Node.

4. Building a CMS in MeteorJS is very easy and rapid.

5. The only issue with MeteorJS is load order of CSS and JS files. It's version 0.8, so hopefully they can have this fixed or there will be a package created to manage load order when 1.0 rolls around.

Comments?

 

[fuzzybabybunny]

My 2 cents are I wouldn't use MongoDB ever as main storage. Maybe as cache backed by a REAL database.

Else:

https://www.google.ch/#q=ruby+shopping+cart

I honestly don't know enough about the differences between MongoDB and an SQL database. What are the cons to using MongoDB?

I heard that MySQL is pretty shitty though. Something like PostGreSQL is better.

EDIT:

The man advantage of using a no-SQL DB with an order checkout system is that each order is essentially a document that describes the customer's name, what they ordered, etc. It's like an invoice record. So in this sense a no-SQL DB is a natural fit.

I think the main disadvantage of no-SQL databases is that there's no JOIN. I can see this being an issue when I want to run reports like "How many people ordered Product X for the entire year." But JOINs are expensive in SQL databases anyway, right?

 

[Tweak155]

When I ran a website that took credit card transactions, I paid for a service (I personally used 1ShoppingCart) for a few reasons.

1 - You have to get a certificate for your site. It's pretty cheap if I remember correctly, but another thing to maintain.

2 - You have to have your site certified by a security company. If your cart is hosted off site, it is A LOT simpler to go through the process. All the complicated tech questions you don't have to deal with, your questions become more of a yes / no.

3 - The managing of the credit card data has a lot of rules you'll have to deal with. Although if you're looking for a pre-made solution this probably won't be too terrible.

It's been a few years, but I remember thinking at the time the $35/mo was worth it, and after running that site for a while, it became more apparent. A lot of pay-for services will help you manage people that buy from you, send out automatic e-mails, promos, etc. And, at least with 1ShoppingCart, you can apply HTML to get the cart to look like your website, although it was a pain the neck, it paid off.

 

[cabri]

I would not think that you will have a high volume rate such that you need to worry about overhead cost for a SQL database.

 

[Crusty]

When I ran a website that took credit card transactions, I paid for a service (I personally used 1ShoppingCart) for a few reasons.

1 - You have to get a certificate for your site. It's pretty cheap if I remember correctly, but another thing to maintain.

2 - You have to have your site certified by a security company. If your cart is hosted off site, it is A LOT simpler to go through the process. All the complicated tech questions you don't have to deal with, your questions become more of a yes / no.

3 - The managing of the credit card data has a lot of rules you'll have to deal with. Although if you're looking for a pre-made solution this probably won't be too terrible.

It's been a few years, but I remember thinking at the time the $35/mo was worth it, and after running that site for a while, it became more apparent. A lot of pay-for services will help you manage people that buy from you, send out automatic e-mails, promos, etc. And, at least with 1ShoppingCart, you can apply HTML to get the cart to look like your website, although it was a pain the neck, it paid off.

1) Installing SSL certificates is easy
2-3) There is NO PCI compliance requirement if you are using stripe.com, they do it all for you. Your server never ever sees complete credit card details.

 

[Graze]

I honestly don't know enough about the differences between MongoDB and an SQL database. What are the cons to using MongoDB?

I heard that MySQL is pretty shitty though. Something like PostGreSQL is better.

EDIT:

The man advantage of using a no-SQL DB with an order checkout system is that each order is essentially a document that describes the customer's name, what they ordered, etc. It's like an invoice record. So in this sense a no-SQL DB is a natural fit.

I think the main disadvantage of no-SQL databases is that there's no JOIN. I can see this being an issue when I want to run reports like "How many people ordered Product X for the entire year." But JOINs are expensive in SQL databases anyway, right?

You aren't going to be the next Amazon.com. For what you are doing mysql is beyond adequate.
Don't try to solve problems you don't have.

 

[ArsDiaboli]

Meteor runs on Node.js, and there are MySQL drivers for Node.js, if you care to dig into it.

Like mentioned, stripe.com is a good solution to take card payments, I've used it and it's very nice as long as you don't get into very complex subscriptions.

NoSQL solutions like Mongo basically give you amazing performance, but your tradeoff is data integrity that common SQL solutions provide. You will have to manage that yourself, and it can be very time consuming. Unless the application is very small, noSQL is rarely a replacement for SQL, and more often than not I would say that they compliment each other. You can save your transactional data in Mongo, but leave complex information that will need query processing in SQL, and merge them with server side code. It's really up to you, but I wouldn't say that you have to choose one or the other, you can have both.

Question: How would you do a CMS in Meteor? You would need to do it from scratch unless there's a good package that I don't know about, while more mature tools already have CRUD generators for you that can make it a breeze and you'd only need to customize some parts.

If you care about having everything in real-time you can take a look at things like Ratchet for PHP, Socket.io for Node, or any other WebSockets library depending on your framework. I'm just saying, Meteor is still very early in development, and while I do think it's fantastic, I also think that it will cause you more pains than gains until it's a bit more mature.

 

[Tweak155]

1) Installing SSL certificates is easy
2-3) There is NO PCI compliance requirement if you are using stripe.com, they do it all for you. Your server never ever sees complete credit card details.

Even if that's the case, the (marketing) tools you get with paid services can easily pay for themselves if you take advantage of them.

I'm not saying definitely use a paid service, I'm just suggesting to take it into consideration.

For the tens of dollars a month, a good paid service will generate income that surpasses the cost and in general just make your life easier.

 

[beginner99]

I honestly don't know enough about the differences between MongoDB and an SQL database. What are the cons to using MongoDB?

I heard that MySQL is pretty shitty though. Something like PostGreSQL is better.

EDIT:

The man advantage of using a no-SQL DB with an order checkout system is that each order is essentially a document that describes the customer's name, what they ordered, etc. It's like an invoice record. So in this sense a no-SQL DB is a natural fit.

I think the main disadvantage of no-SQL databases is that there's no JOIN. I can see this being an issue when I want to run reports like "How many people ordered Product X for the entire year." But JOINs are expensive in SQL databases anyway, right?

Example:

http://stackoverflow.com/questions/7149890/what-does-mongodb-not-being-acid-compliant-really-mean

But google yourself. No-sql stuff has very big issues in terms of data consistency. And in terms of financial transactions that seems very important. Besides that speed is a non-issue because if it where such a big site you wouldn't be asking for advice here. Also benchmarks are usually done in the must "insecure" configuration for MongoDB. Once you change this it also isn't that much faster anymore anyway.

Yes, choose PostgreSQL over MySQL any day. Note that PostgreSQL 9.4 will support no-sql features but with full ACID support. Eg. you can store JSON documents and index them. Basically makes document based no-sql stores obsolete.

Also be more critical about all the new cool stuff. Also nodeJS is a hipster thingy just like MongoDB. They aren't solutions that have proven to be reliable and useful over the last 3 decades like real relational databases or apache/nginx.

Else I think Tweaks advice makes sense.

 

[Leros]

You aren't going to be the next Amazon.com. For what you are doing mysql is beyond adequate.
Don't try to solve problems you don't have.

Yeah. MySQL will be perfectly fine.

I work on a handful of products that use MySQL. I deal with things on the order of hundreds of thousands and tens of millions. As long as your indexes are set up appropriately, MySQL works quite fine at that scale even with complex joins.

As you get really big, you get into things like tuning disk performance and memory usage. In my experience, Mongo is even worse in that regard.

 

[fuzzybabybunny]

Gotcha. In this case, is there a framework out there that is Reactive like Meteor and uses the Pub/Sub model like Meteor but also uses MySQL or PostGreSQL?

 

[fuzzybabybunny]

Even if that's the case, the (marketing) tools you get with paid services can easily pay for themselves if you take advantage of them.

I'm not saying definitely use a paid service, I'm just suggesting to take it into consideration.

For the tens of dollars a month, a good paid service will generate income that surpasses the cost and in general just make your life easier.

What marketing services are you referring to?

 

[beginner99]

Yeah. MySQL will be perfectly fine.

I work on a handful of products that use MySQL. I deal with things on the order of hundreds of thousands and tens of millions. As long as your indexes are set up appropriately, MySQL works quite fine at that scale even with complex joins.

As you get really big, you get into things like tuning disk performance and memory usage. In my experience, Mongo is even worse in that regard.

The problem with MySQL isn't the performance.

http://www.youtube.com/watch?v=emgJtr9tIME

 

[Graze]

The problem with MySQL isn't the performance.

http://www.youtube.com/watch?v=emgJtr9tIME

Op alluded to the performance of mysql(postgre) vs a no-SQL db

 

[Tweak155]

What marketing services are you referring to?

Each service varies, but in general the cart services store the emails of everyone who buys anything from you and will generate nice template advertisements for you to send back out to those buyers. You can control how often they go out, what the content is, etc.

They also make it easy to advertise a sale or discount bundles or shipping (probably doesn't apply to you) based on a good variety of factors... total purchased, number of items purchased, etc. I imagine even free carts have this, but I found the complexity of what I could do even with a cheaper service was quite nice. Configure coupon codes with number of uses, applies to only certain categories, based on total etc.

Also one more thing I found nice at least about the service I used was the reporting tools to look at my last month, 3 months, year etc of sales data. I could view it by what credit card type was used, how many of a certain product was purchased, average high transaction amounts, etc. It helped me see what people liked to buy and I could hone in on doing deals with those products.

 

[ArsDiaboli]

Gotcha. In this case, is there a framework out there that is Reactive like Meteor and uses the Pub/Sub model like Meteor but also uses MySQL or PostGreSQL?

https://www.google.com/search?q=websockets
+
https://www.google.com/search?q=<language & framework of your choice>
+
https://angularjs.org/

 

[Leros]

Op alluded to the performance of mysql(postgre) vs a no-SQL db

Yup. My point stands for MySQL, PostGres, etc.

A relational database seems like a nobrainer for something like a store.