Node Red Shopping Cart 1.1

Share Your Projects
1

After trying Woocommerce, Prestashop and some other carts nothing really quite fit. I needed something that regular no so highly paid hourly employees could handle and something that was flexible enough to support many customizations. I was also quite annoyed by shopping cart vendors who endlessly update stuff and break things at the worst time. Update the cart, get a call the next day about what's not working now.

I happened to stumble across a static site generator, HUGO and thought, this is cool. Kind of like what we did back in the 90's when we generated thousands of html pages because perl/cgi was such a resource hog. Problem was I'm lazy and Hugo wanted thousands of config files and fiddly stuff and it was far from being interactive since it was a static site generator.

Then it dawned on me. Use node-red to generate thousands of Hugo content files and build the site that way. For the actual cart math thingy, use node-red to add up the items and process the transaction.

Seems simple enough. First attempt worked, processed sales and integrated with stripe. Items were pulled out of files dumped from the point of sale system. Things were parsed, substituted into markdown files and html was generated. I ran the cart for about a year. It was fast, robust and easy to deal with. Unfortunately I didn't know quite what I was doing the first time, we usually don't. There were things I didn't take into account and capabilities I wanted to add.

So I gutted the system and started a rewrite. Code was cleaned up, features added, things rewritten to make them cleaner. The total code base was cut in half and organized far better.

Overall, I'm very happy. I constantly get thrown curve balls and changes and the node-red system is very flexible. I wake up one morning to find that they put youtube links in a bunch of my data. No problem. 15 minutes later those links are being turned into embedded videos on the items page. I'm told there needs to be a cap on transaction amounts, no problem. 15 minutes done. The ability to customize the system compared to other carts I have worked with is just amazing.

The typical problem with other open source carts is you fiddle with the guts and the next time they put out updates your customizations go to hell. This is no problem. No one else is mucking around with my stuff all the time "improving" it.

Security is a major issue with a lot of the shopping carts. Huge code base, huge attack surface. Nodered sits behind a proxy. Few and specific entry points are allowed in and carefully controlled. The vast majority of the site is static html.

Processing power needed is absurdly low. Wordpress on an instance twice the size melts down while this has no detectable load.

Nodered plays quite well with Hugo. I would assume it's the same for other static site generators and probably also Ghost. I'm considering using Hugo and NodeRed as a content management system where Nodered is used to edit content files that Hugo then builds into a site.

Prestashop had a massive back end and the people responsible for filling the orders were intimidated by it. Not to mention inventory updates were a mess. The back end of this cart has about 10 buttons. It does nothing but what needs to be done. Updating inventory takes about a minute and it is bone head simple.

One of the new tasks was to include all the items from a vendor which are essentially being locally drop shipped. The vendor provides a spreadsheet of prices and they have a website displaying all the items. The cart spiders the vendors website, extracts information, pulls pictures and creates a json structure for all the items for inclusion in the site. There is no database. The whole site is essentially generated from a couple excel files and a big pile of pictures. The process takes about a minute. There are now about 2000 items.

There are a lot of features the cart doesn't have. For example shipping. Because in this case items are not shipped. I have no doubt I could add in shipping capabilities if needed. At this point adding new features is actually a joy.

The amazing thing however is that I'm not much of a programmer and I have done this in my spare time. I taught myself basic javascript via function nodes. I understand pretty much how everything works and I can find anything I need. Prestashop on the other hand was a mass of tangled mess and just finding the right file to edit for customizations was a chore.

5 Likes
2

Are you going to show an example flow of what you have done? I think how it could be use=ed for documenting things, for example converting recipes in a text file to Hugo.

GREAT IDEA YOU CAME UP WITH! :sparkler:

3

I wrote a proof of concept simple CMS using Node-RED, uibuilder and markdown - worked fairly well. Not retried with the newer versions of uibuilder, should be even easier. On my backlog of things to try :grin:

Agree with Paul, very inventive. Nice.

4

I have a number of projects I would like to make available to the public.

The problem is that often they require things besides just node-red to run. In the case of the cart, I also used Apache as a reverse proxy, there is of course Hugo which needs to be installed and some customized templates, a bunch of pictures, additional modules, a php script for uploads, some shell scripts etc.

Anyone run into this issue distributing a Nodered application? I would like people to be able to play with this stuff without a lot of effort and configuration. I'm thinking Docker might accomplish this.

Providing just the flows results in something cryptic that doesn't do anything. Personally I learn by taking fully functional things and constantly breaking them. That didn't seem to be appreciated when I was a child for some reason.

1 Like
5

Yep - Docker for each of your components and some concise directions for setup would be the easiest.

Also clear delineation between modules - so if someone already has NR do not force them to deploy another instance with a Docker container - but tell them what to add change in their instance

But start with it all in docker and see how you go

(I am very interested in this for a couple of people i know who run online shops and are very unhappy with their developers and costs for doing things)

Craig

6

If I didn't have a day job. But I do so more likely I shove everything into one container and be happy if it works for demo and examination.

7

Why tell about it if you do not share? The subject for this part of the forum is "Share Your Projects"

EDIT: Edit, softening my posting a bit; I just would like to encourage you to share, is just me, I normally have something ready to share before I write about it

8

Lets not be too hard on the author here :slight_smile: I get the issues and I'm glad to hear about someone using Node-RED in this way.

1 Like
9

Thank you for this idea. I will have a small project coming up and I have been going back and forth how to tackle the frontend without exposing anything from the backend useful to an attacker. Using static periodically regenerated html crossed my mind, but creating static html put me off so far. If generating "construction files" with node-red that "produce" the html is a viable way, things could become easier a lot. :+1:

10

That main potential problem using something like Hugo would bring would be having to regenerate the site after making changes to the underlying Markdown files. An alternative would be to use something like Docsify which is certainly slower because it converts everything in the browser but does not require any rebuilds. I use Docsify for the uibuilder documentation for example and also use it at work to publish our IT standards via GitHub.

Otherwise, potentially, uibuilder could help here in various ways.

You could use it to generate HTML that changes relatively rarely. Either then capturing the HTML and writing to a static file or using a reverse proxy with caching. Both can add additional security.

Or you could use it fully dynamically with a reverse proxy, again adding an extra layer of security.

You could potentially do a mix of the two as well.

Worth noting that uibuilder's client library has a feature that allows dynamic conversion of Markdown simply by adding the Markdown-IT library to your front-end page. It also has the ability to sanitise HTML output simply by adding another library.

11

I generate about two thousand pages in less than a minute. Unfortunately Hugo can't regenerate single pages.

Ghost seems like it also might be a good match. I did some checking, the only issue I ran into was that Ghost was running up the CPU load on an instance with no visitors. It may have been my lack of knowledge of Ghost and optimization which caused this.

Using apache as a reverse proxy to access specific http endpoints in nodered works well.

12

That seems very fast. And if it is that fast to rebuild the whole site, why bother with incremental updates (and possible pitfalls thereof).

1 Like
13

It is indeed very fast and I use it for my blog. But you do still have to go through a rebuild even if you only want to correct a typo on a page.

Depending on the type of site and its information/data and what you are wanting to do, having to run Hugo to do an update - probably followed by a Git push - might not always be the best approach. For something like a WIKI-style site being updated by many people for example, Hugo would likely be a very poor choice whereas something more dynamic might well suit.