Shopify Vs. Squarespace for eCommerce

I had the recent opportunity give both Shopify and Squarespace a thorough test drive and learned a great deal about the two. I wanted to give them an equal chance to wow me so I built the same exact site and product catalog using both platforms. Throughout development I kept thorough whiteboard notes on features that I liked and disliked about each. In this post I will share my story of what it was like to build the same site using two different platforms.

The site is an online retail store for a clothing brand called LOM Clothing which was started by world renown battle rapper and hip-hop star, Hollow Da Don. LOM Clothing has a growing catalog that changes frequently so product/inventory management was definitely a priority. Other priorities included quality of design, ease of checkout process, security features, ability to customize at every layer, and native integration with Stripe, the popular credit card handler. After some quick googling it quickly became clear that both Shopify and Squarespace met all this criteria so here comes the good, the bad, and the ugly of both platforms.

Shopify Highlights

  • Product Entry / Management
    • This is one area where Shopify really shines. Creating new products, categories, collections, features, etc really couldn't be easier and managing inventory is a breeze. As a side note, their "bulk editor" function is absolutely and completely epic.
    • Going deeper into the collections topic, the ability to create "regex style" rules to define product collections is extremely cool and allows you to keep things quite dynamic.
  • Editable Liquid Templates 
    • Liquid is a templating engine, similar to Smarty, Jade, and others but the ability that Shopify gives you to customize and add to these templates is really outstanding. I didn't feel like I was trying to code my way out of a box, I could add and change functionality to my heart's content without feeling frustrated.
    • The build-in CSS/HTML editor is actually quite functional. I was expecting to have to copy/paste things out to Sublime and back in but I didn't do that, even once.
  • General Administration
    • Navigating Shopify's admin section is really a pleasure. It doesn't matter if you are managing products, orders, website settings, or accounts, the entire experience is very well done.
  • App Store
    • Shopify has its own app store which includes a variety of different data manipulation tools, additional analytics, sales channels, and more. It's a great feeling to have an active community of other developers publishing useful apps for a platform you are developing on.

Shopify Negatives

  • The only negative I can call out is that there isn't a "Create New" button from a product detail page unless you have just created that product. When you save a product for the first time it has a link at the top to create a new one. If you update an existing product you have to go back to the overview page to find a way to create a new product. While that's a little nit-picky, I found it to be annoying on a few occasions.
  • I know this sounds a bit crazy being the only "negative" but after a fairly frustrating experience with Squarespace (which I used first) I found Shopify to be a great experience.

Squarespace Highlights

  • Extremely WYSIWYG
    • There are a lot of ways this can be a negative but Squarespace does an outstanding job of proving "blocks" which you just plop into containers, define some properties for, and boom, you have content. While these aren't extremely easy to customize, they provide an outstanding way to get rich and dynamic content on your pages. 
  • High Quality Themes
    • The "quality" of templates in the Squarespace ecosystem surpasses what is currently available with Shopify.  By "quality" I mean the attention to detail, the responsiveness, and the UX of a given theme or template. Squarespace seems to take a lot of care with what they publish to the marketplace.
  • Import Tools
    • Squarespace makes it incredibly easy to import products and content from existing platforms such as Big Cartel, Etsy, and ironically, Shopify.  Using the Squarespace admin UI you simply select your platform, enter your credentials, and boom, it takes care of the rest. In my limited testing I found their import tools to be very impressive and robust.

Squarespace Negatives

  • Product Management
    • With any eCommerce site, product management is crucial for scalability, maintainability, and sanity. Managing products in Squarespace feels very clunky and at times was incredibly flaky. It took far too many clicks to create/update products which ultimately leads to frustration and wasted time.
  • Product Relationships
    • Squarespace does something very strange with products in that it creates a relationship between a product and a page. This means that when I was doing testing and creating/blowing pages away I would suddenly lose products. I finally realized that there is a strange and seemingly arbitrary relationship between a product and a page which leads to a lot of extra work. Something as simple as getting the same product to show up on multiple pages is a common ask in the Squarespace support forums. Clearly that is a problem.
  • Customization
    • As I mentioned in the "Shopify Highlights" section, the ability to customize templates and their associated assets is incredibly useful. Squarespace doesn't offer any options to make direct edits to template files without using their "developer platform" which I heard very negative things about from Squarespace users and developers. The fact that there is no support for anything other than injecting code into the header is quite limiting and something that definitely got in the way of things I needed to accomplish.

Summary

I am sure it's fairly clear which direction I would go but for the sake of clarity, Shopify won this contest hands down. Whether you are handling product/inventory management, web site development, or both, Shopify provides a much better all around experience. I would highly recommend it for developers and non-developers alike because even though it gives you all the tools to customize it doesn't require that you do in order to get up and running. 

Side Note

Ironically and a result of all this, I did end up migrating 5 years worth of blog posts from WordPress over to Squarespace. This blog (as of the time of this post being published) is running on their personal platform and I am extremely happy. It's a breeze to maintain, the "block" approach to laying out content is fantastic for blogging, and now I don't have to think about keeping my WordPress server/plugins up to date any more. I will be doing a separate post on the import process and how Squarespace really shines as a blogging platform sometime in the near future.

Building a Scalable API in the AWS Cloud

We've been running our Node.js based API in the AWS cloud for a couple of years but have been wanting to scale way up. Rather than trying to beef up our existing VPC (vertically scale) I made the decision to architect a new solution and rebuild it from the ground up. In this post I will talk about some of the technologies we leveraged, challenges we ran into, and benefits we have seen already.

As you probably guessed from the image above I saw this as a great opportunity to try Elastic Beanstalk. Elastic Beanstalk is what is known as a PaaS (platform as a service) and it acts a container for your applications and their respective environments. After creating an "application" you define a set of parameters corresponding to AWS services like EC2, RDS, ELB, etc and boom EB takes care of creating compute instances, database servers, load balancers, and more! And yes, I know what you are thinking and it is just as magical as it sounds. As a part of this configuration you can setup autoscaling triggers which will scale your fleet of applications up/down based on the metrics you set. It was an absolute joy doing load testing and watching the fleet respond like an accordion based on the amount of CPU being used.

The reason I went with this approach is because I know that we have a very steady load that will only grow based on the number of machines we have connected but on top of that we have a number of highly variable customers which could cause huge spikes for short to medium durations. In the "olden days" we were forced to pay for servers which could not only handle the peak load but also the forecasted load based on our growth. Today with solutions like Elastic Beanstalk and autoscaling you are only paying for the fleet needed to support the current load and not the worst case scenario load. Clearly this is huge for the bottom line.

For this particular application we are leveraging the following AWS services:

  • Elastic Beanstalk
  • CloudFront
  • CloudWatch
  • EC2
  • ElastiCache
  • ELB
  • RDS
  • Route 53
  • S3
  • Trusted Advisor
  • VPC

A really neat aspect of using Elastic Beanstalk is the not only the ability to monitor any component of your environment (via CloudWatch) but to also see a summary of things like CPU utilization and network I/O across your entire fleet.

The only major issue I had with this architecture was with WebSockets. Our mobile application uses Socket.IO for all communication between the client/server and we kept seeing 400 errors on the socket connection. After a lot reading and chatting with AWS engineers we came to find that the proxying being handled by the ELB + Nginx was causing the handshaking to fail on the socket connection. The fix (take note, it could save you a major headache) was to change the ELB configuration (from the EB settings) from HTTP/HTTPS listeners to TCP on port 80 and SSL on 443. The combination of that along with removing Nginx from the stack solved all of the socket issues and even with hundreds of devices connected to dozens of servers in the fleet everything stays in sync.

In closing, we couldn't have landed on a better method for keeping our API scalable, even if we spent a lot more dough. The peace of mind that comes from knowing that the environment will scale up when it needs to without any human intervention is near priceless.

Securing WordPress Admin

In today's online world security is a top concern. For WordPress maintainers keeping your installation, themes, and plugins updated is an essential first step but there are many other things that should be taken into concern. Today I am curious to get your feedback specifically on locking down the admin section of your WordPress site and after collecting those results I will throw together a post with some links to some really great material on locking things down in a more generalized fashion.

Now as far as the admin section goes, I use a server-side technique that requires both a password an me being at a specific IP address to access the wp-admin section. That may be too strict for most, particularly those on mobile so here is a little snippet that will force Apache to require a user name and password (all of which are stored server-side) before even displaying the page.

*** Update: A great discussion resulted on Facebook as a result of sharing this post and I learned something extremely useful. There is a Google Authenticator WordPress Plugin which enables two-factor authentication via the Google Authenticator app/service. I already use this technology for a variety of other sites/services so naturally it was a no brainer to use it for WordPress.

Here is some important information to keep in mind when using this plugin from Justin Dessonville:

"The key is to make sure you have your wordpress general settings timezone set to whatever time zone your phone is in. I'm not sure how this would work if you travel across time zones a lot, but it could potentially lock you out if it's not setup right. Regardless, when both your phone & wordpress instance are set to the same time zone it's been solid for me."

To re-cap: after the update, I am still using Apache/htpasswd to protect the /wp-admin part of the site, but I have removed the IP checking in favor of the 2-factor authentication. I feel just as secure (if not more) and I don't have to worry about tunneling in via VPN to satisfy the IP check.