

Show HN: MongoDB + open source e-commerce = Forward - ericingram
http://getfwd.com

======
whalesalad
This is incredibly cool. The template syntax you have going is awesome.
Reminds me of the natural language of haml/ruby with the handy pipe filter
stuff of django/jinja. I _can't stand_ mustache and handlebars.

The UI is great, it's responsive, and well thought out.

Also, the data modeling issue is a great selling point. Right now, MOST all
applications are the same. Take this data, validate the person sending you the
data is correct, validate the data is correct, and store it. Then apply the
same methodology to fetching it, modifying it, or deleting it. I've been a
django/python guy for years but after recently diving into Rails, I don't
think anyone has done this any better. You can very quickly get things moving
in CRUD/REST without much code.

That being said, it all comes back to the modeling. Modeling is relatively
simple in Rails. The ORM you get with Django _far exceeds_ ActiveRecord in
usability but either way, at some point, a developer needs to sit down and
define the data modeling. I realize you're marking this to developers
(obviously) but I feel like with your cool UI and mongodb backing, you might
even be able to expand this to administrators of the service.

Meaning, I can deliver a pre-configured product to my clients but if they want
to add some fields to a product that are
searchable/sortable/validatable/etc... they won't need to wait for me to do
it. They won't need to wait for me to deploy it. I won't need to run a
migration script.

Modern REST frameworks typically work based on a separation of a model and a
resource. The model handles data storage and representation, and the resource
handles serving it up, controlling access, etc... I think we need to couple
these together. One unified object. I can create something, like a `Product`,
give it some properties, set validations and permissions for those properties,
and boom. Done.

Things like this and Meteor are shining examples of the radical change that we
need in this current era of development. Yes, you guys will find faults in
that statement. The neckbeards will come out and tell me mongodb does not
scale, or node.js async development does not make sense. That is not the
point. The point is that we're really not making it much easier on ourselves
to build the things we want. Right now it makes more sense for me to pay Parse
to handle an iOS back-end. Why? Because for the most part building it is a
pain in the ass.

It doesn't need to be. I'm excited about Forward, very excited.

~~~
randallsquared
_I can't stand mustache and handlebars._

Why do you dislike them?

Separation of design and code seems pretty important, so having a template
system that's really a (more or less limited) programming language of its own
seems like a step backward to me.

~~~
whalesalad
Honestly the django/jinja syntax and library of helpers/filters is virtually
impossible to beat.

    
    
        ### Example User
    
        user: {
          name: "Michael",
          bio: "The quick brown fox jumped over the lazy dog.",
          products: [<Product>, <Product>, ... ]
          joined: "09-07-12"
        }
    
        <table>
        {% for user in users %}
          <tr class="{% cycle 'odd' 'even' %}">
            <td class="user-name">{{ user.name }}</td>
            <td class="user-bio">{{ user.bio|truncatewords:3 }}</td>
            <td class="user-products">{{ user.products.count }} Product{{ user.products.count|pluralize }}</td>
            <td class="user-joined">{{ user.joined|date:"M jS, Y" }}</td>
          </tr>
        {% endfor %}
        </table>
    
        ### Would Display
    
        <tr class="odd">
          <td class="user-name">Michael</td>
          <td class="user-bio">The quick brown ...</td>
          <td class="user-products">2 Products</td>
          <td class="user-joined">September 7th, 2012</td>
        </tr>

~~~
ericingram
Here's what this would look like in Forward:

    
    
        <table>
        {foreach "/accounts"|get as $user}
          <tr class="{cycle values="odd, even"}">
            <td class="user-name">{$user.name}</td>
            <td class="user-bio">{$user.bio|truncate:30}</td>
            <td class="user-products">{pluralize "{$user.products.count} Products"}</td>
            <td class="user-joined">{"M jS, Y"|date:$user.date_created}</td>
          </tr>
        {/foreach}
        </table>

~~~
ericingram
Re: API endpoint, that's exactly it.

Here are several equivalent ways of expressing this:

    
    
        // PHP
        $accounts = get("/accounts");
    
        // Template
        {get $accounts from "/accounts"}
        {$accounts = get("/accounts")}
        {$accounts = "/accounts"|get}
    

Here's a really cool side effect of the way the model result works...

    
    
        {$account = "/accounts/123"|get}
    
        {put [role => "admin"] in $account}
    

When converted to a string, they represent a model URI.

~~~
ricardobeat

        {put [role => "admin"] in $account}
    

Does this mean you have all your view logic inside the templates?

~~~
ericingram
Generally logic that is good in a controller can be put in the template file
instead. This idea came from the "Smart model, Dumb controller" concept. We
made controllers so dumb, it was rather clean and easy to understand when
combined with a template. We see more of this with client side frameworks like
Meteor.

Still, Forward is built on a new micro MVC framework and controllers do still
exist. Those that prefer to write them can do so in a more traditional way.

    
    
        class AccountController extends Controller
        {
            function index ()
            {
                $this->account = get("/accounts/123");
        
                put($this->account, [role => "admin"]);
            }
        }
    

(This is not very useful code but you get the idea)

------
jenius
We desperately need something like this. I just finished a large ecommerce
project built on another open source system and it was so incredibly difficult
to customize anything. It was more or less "do it the way we have in the
template or you're in for a nightmare", and with the client and design specs
asking for custom things, a nightmare was what ensued.

Ecommerce is super complex and it will be a really difficult mission to make
this really work and be flexible without getting bloated. But if it can
happen, this will be a game changing project. My full support is there, and
I'll see if I can contribute as well if I have time : )

~~~
ericingram
Thanks for your support and encouragement, much appreciated!

Also, what you describe is exactly what Forward aims to fix. Custom features
were needed for every single e-commerce site we've built, so we thought it
made sense to focus primarily on this workflow.

~~~
mst
I tried to build this years back and made a complete mess of it.

On the other hand, I still believe it can be done and I think the approach
you're taking is one of the ones with a decent chance of succeeding.

Good luck; I'll be keeping an eye out for clever ideas to steal as you move
forwards :)

~~~
ericingram
I made a mess of it also the first couple tries, but ideas came together much
easier this time. You're free and welcome to build on our experience, excited
to see and help other people that want to.

------
ericingram
MongoDB makes deleting records easier. Forward has a trash can:

    
    
        {get $order from "/orders/123"}
    
        {put $order in "/trash"}
    

Now the order is no longer in the "orders" collection in MongoDB, instead it's
in the "trash" collection. You can still get it by ID though:

    
    
        {get $order from "/orders/123"}
        {$order|dump} -- Still here! But not really here.
    

We can just as easy pull the document out of the trash and put it back where
it was.

It's the reason you see we can delete documents without even a warning in the
demo (<http://demo.getfwd.com>).

------
julien_c
Really interesting. As someone who's done some consulting in e-commerce I've
always dreamt of an open source engine based on MongoDB.

Magento and Prestashop are perfect examples of "relational databases gone
wrong"... 2,000 tables? Right!

~~~
ericingram
I started building my own first e-commerce business around the time Magento
hit beta, and the EAV (Entity Attribute Value) model is the part that killed
it for me. I had ideas for my site that didn't work out of the box, so I knew
I had to understand the code to customize it.

Instead we built a platform from scratch to fit the unique features of that
site, and it worked. The business did $400k in revenue the first year.

Now a few years later, I can accomplish the same thing with the same basic
skills (HTML, CSS, easy to understand data storage), but I don't have to start
from scratch. I wanted this to exist so that I would have fun building
e-commerce sites again.

------
mrinterweb
I thought that e-commerce was one of the things MongoDB said it would not be
good for [http://www.mongodb.org/display/DOCS/Use+Cases#UseCases-
Whens...](http://www.mongodb.org/display/DOCS/Use+Cases#UseCases-
WhenshouldyouconsiderusingMongoDB%3F) I love MongoDB and I use it on many of
the projects I work on, but I'd want something transactional and ACID
compliant when dealing with money and purchase tracking. How are you
mitigating the risks of data integrity compromise when using Mongo?

~~~
ericingram
There are ways to perform document-level transactions using optimistic or
pessimistic locking, in our experience so far this has been sufficient for
purchase tracking. I imagine our perspective will mature as we get the system
into higher load scenarios.

One of the reasons we decided to delay code release is that we need more
time/resources to get it ready for the different ways developers will try to
use it early on.

------
ericingram
Another concept in Forward that is new, REST-like models. The base Model
defines 4 public methods:

    
    
        get(uri, data)
        put(uri, data)
        post(uri, data)
        delete(uri, data)
    

It's easy to code a model around this pattern, and the result is a system that
functions entirely without procedures from the template's perspective.

For those used to WordPress style functions in templates, this model
accomplishes something similar, but again without functions.

------
jontas
I have recently been evaluating e-commerce platforms for an upcoming project.
This looks very nice, but it seems to be missing one key piece of
functionality: variable products. For example, shirts that come in three sizes
and three colors (so 9 combinations, each with their own SKU and inventory
level).

I guess since it is open source, if I want this added, I should put my money
where my mouth is and add it myself. Maybe one day, if I ever have the time..

~~~
ericingram
It does have this functionality, but so far we've used it in different ways.
What you see in the Demo admin is not all there is, but since it's meant to
customize, certain features aren't visible in this version.

My last e-commerce business was a fashion site (<http://redtagcrazy.com/blog>)
built on a custom platform, and we dealt with variations of course, but so far
only one of the early sites we built on the platform needed this feature (and
they have it).

Edit: I would add that Forward aims to be full-featured, and anything you
might reasonably expect out of the box in something like Magento, will be
available in one form or another.

~~~
jontas
That is good to know, thanks!

I have also built totally custom ecommerce platforms in the past
(getbuckyballs.com) and I understand many of the difficulties involved. I
think you guys have done a great job with this, I hope I have a project that
can use it.

------
ericingram
Developer/founder of Forward here, happy to answer questions about what it is,
why, how, and take critical feedback.

Devs complain endlessly about the rigid, complex mess of e-commerce software.
I'm trying to change that with a platform that is easy to understand and
customize by developers. We've had a lot of success so far with early projects
like <http://jellyfishart.com>.

MongoDB has been a huge help.

~~~
burningion
The layout is great, very clean, great job.

That said, how do you deal with transactions? It was my impression that
MongoDB doesn't really support ACID transactions. Did you find a workaround?

I know from prior experience working on a major eCommerce store that there can
be really taxing loads on the database server, right around Black Friday, and
having inconsistent writes could really be disastrous. Have you tested your
transactions for consistency under load?

~~~
ericingram
To start, I will say we haven't run into any issues relating to consistency
under load. We do have a plan for dealing with it, using an optimistic locking
mechanism (where each document has a revision number and an update requires
it), but as an early project we haven't had the chance to put it up against
high load for a long period of time.

Also, I'm pretty confident MongoDB is going to introduce an easier mechanism
for document locking in the near future.

~~~
jeremyking
It's difficult to find the right back-end solution that can easily scale with
a business and demand. I saw this post a month ago and think it looks pretty
promising and might be something you could take advantage of here.
<http://news.ycombinator.com/item?id=4294719>

Currently it's in alpha testing and promises multi-key ACID transactions. And
also introduces a really interesting layers concept.
<http://www.foundationdb.com/#layers>

Keep up the great work!

------
obayesshelton
Why should a developer or a contributor pay to help develop something for the
community ? seems a little too money making and less community driven.

~~~
whalesalad
What the fuck? Are you joking? We now live in a world where developers bust
their asses to deliver _99 cent applications_. It's fucked. Slowly, here and
there, we're beginning to see a shift. People will pay for a great product,
especially if it makes your job as a hacker/developer easier.

Play with the demo for 60 seconds. How long would it take you to build that?
How much do you charge per hour? I built a lightweight ORM for pymongo/mongodb
last weekend from an empty .py file. It was fun, but it was challenging and
took pretty much the entire weekend. And it's basic. You can find, find_by_id,
find_one, and a few other things. What these guys have done is tremendously
impressive and difficult to do. They deserve every right to ask for money and
that will only fuel further development.

Everyone has to keep the lights on at some point.

~~~
ericingram
You get at the core of the issue here, which is that we can save developers a
huge amount of time with the right mix of pre-built components and dedicated
developer support.

All of our paid options surround the idea that developers can go faster and
better leverage their time with time-sensitive help. We've all become used to
Stackoverflow saving the day, but if the answer doesn't magically pop up in
Google, we can waste many hours chasing it needlessly.

I hope the future is full of paid open source options.

~~~
mst
Same here. The mixture of support contracts, straight up donations and the
Varnish Moral License that varnish offers is, I think, a taste of things to
come. Mixing support and patronage is, I think, the answer - patronage is a
means to ensure the software is better, support contracts a hedge against it
sucking - but if you combine the two so money spent is never perceived by the
customer as wasted, the result is really quite interesting.

------
ewsplat
Great effort, I'd love to see the finished product. I have been contemplating
of migrating my own e-commerce platform (<http://demo.embwebstores.com>) to
MongoDB and one of the new frameworks - Laravel.

I wonder if you found the lack of relational data an obstacle? Maybe not now
but do you see it being a problem down the road?

~~~
ericingram
We didn't find the lack of relational queries an obstacle at all. The model in
Forward handles relationships in a way that makes it feel easy. Model fields
can be defined as a callback:

    
    
        // class Accounts ...
        'orders' => function ($account) {
            return get("/orders", [account_id => $account['id']]);
        }
    

Get an account, access the relationship:

    
    
        {get $account from "/accounts/123"}
    
        You have {pluralize "{$account.orders.count} orders"}
    
        {foreach $account.orders as $order}
            ...
        {/foreach}
    

This also works as expected:

    
    
        {get $orders from "/accounts/123/orders"}
        

It would be cool if you built your platform on Forward. Just sayin' :)

------
knodi
Looks very cool.

Where is the source code repo for Forward? I take it its public as it says
"open-source platform"

edit: nm i found the burb.

"Scheduled for public release in June 2013. The code will be 100% free
forever, supported by our team plus a community of open source developers."

~~~
ericingram
Open source is important because it gives you freedom, but we want to have the
resources to support developers before releasing code. Without support and
great docs (which are coming), it would be a frustrating experience.

------
madarco
You should have said that with "Free style templates" what you really mean is
a BPEL.

The first time I've seen the project I've thought "oh no, another MVC
framework!"

Now that I've seen the {put [status => "shipped"] in "/orders/12345"} I think
it's cool.

~~~
ericingram
You have a good point here, and we will share a lot more details around the
template code on our blog soon. I hadn't heard specifically of BPEL but will
check that out.

We went with the MVC pattern to leverage ours and others' experience in that
architecture, but there is almost no typical MVC boilerplate to deal with in
Forward.

You just create a new template file, like "mypage.html", and go, just like you
would with raw HTML mockups. If you prefer to write controllers you can. If
you want to write custom data models (for something like this {put [something]
in "/my-custom-model"}), you can, but you don't have to.

This is meant to make it easy for less technical designers to move fast
without having to learn MVC patterns.

------
brittohalloran
Looks amazing. You should have more technical details on the site though. This
is _for_ developers so they can handle it up front. I had to dig a bit to find
out it's a templating engine built on top of PHP. More about the architecture
would be good.

~~~
ericingram
You have a good point. We'll write a lot more technical detail over the coming
weeks on our blog. I'm also writing a guest post (technical) for the MongoDB
blog, so expect a lot more to come out soon.

The architecture: A very small PHP MVC framework (5% or so the size of Zend
Framework last I checked). I started developing the earliest version of it ~6
years ago, around the time Rails picked up steam. I loved Rails and Ruby, but
with so much invested in PHP (10 years back then) I decided to implement
Rails-like patterns instead. Those patterns have matured a lot, but I stick to
idea that the framework should be very light itself. Happy to answer more
specific questions.

Also, I'm really excited about the idea of porting the framework/platform to
languages like Python and Ruby. I think it's possible because it's so light
weight, but time will tell. People might call me crazy for that one, but I've
been dreaming about a multi-language platform for years.

~~~
julien_c
What about frontend? Are you using an MVC framework?

~~~
ericingram
It is an MVC framework per se, but it's new and unique to this platform. It's
very light, therr are about ~10 core classes. It also uses Smarty 3 (which is
a big improvement over Smart 2), but the template system can be swapped out
for pure PHP or another package for those prefer.

~~~
julien_c
Sorry I wasn't clear enough: do you use any JS MVC framework, like Backbone
etc. ?

~~~
ericingram
Ahh I see, there is no UI framework, just a simple list/view pattern. Views
are loaded in HTML parts from the server (old school). I would like to see
what people come up with using a framework like Backbone.

One of the driving ideas is that people will develop different versions of an
Admin interface. What you see in the demo is just a template, like any front-
end template, so creating one with Backbone would be an interesting project.

------
ericcholis
Damn you! I'm about a month away from re-launching an ecommerce site in
MongoDB. I probably could have used this six months ago :-)

Oh well, very nice product, glad to hear of yet another use-case for MongoDB
and ecommerce.

~~~
ericingram
I knew there had to be others building e-commerce with MongoDB, but have seen
very little of it so far. We've be happy to help you in the future if your
site can benefit from it.

------
rburhum
I had my e-commerce website ( <http://www.modewalk.com> ) opened in a tab when
I opened yours. Funny enough, our favicons are very similar :)

~~~
ericingram
Hey that's cool! Great looking site too, I'd be interested to know how you
built it.

~~~
rburhum
Python/Django/Fabric/Celery/Redis/PostgreSQL/SphinxSearch/jQuery/Sass/AWS/Jenkins/Selenium/etc
and a lot of stress/tears/joy hahaha

~~~
ericingram
Fantastic, I think it's a rare breed that can take on the full-stack challenge
like this. I would kill to hire people like you.

~~~
rburhum
Thank you! Should I tell you that I am currently porting a native iOS app I
wrote sometime back (in C++ / Objective C) to Android. Sometimes I feel that I
have a tech version of Attention Deficit Disorder.

------
zoneinfinite
Will this e-commerce platform support digital file download/delivery?

~~~
ericingram
Definitely, the goal is to support all of the most common e-commerce models
(standard, drop ship, subscription, private sale, etc) out of the box and
free. There may be different default admin versions to start with also, but
the admin is easy to modify for anyone with HTML knowledge, so it's expected
that certain features will work differently for different models.

MongoDB makes this much easier because the database only needs to know about
the way you are using it, and not the various other ways that unrelated
businesses might use it.

Digital file delivery is on the roadmap now (will publish this in the near
future).

~~~
zoneinfinite
Thanks! I am really looking forward to using Forward (no pun intended). It
looks so damn good. I think your solution is what LemonStand cart is TRYING to
be but is not quite there in my opinion (and probably will never be).

------
tegansnyder
This looks promising. Having worked with Magento for a few years now I
appreciate the thought you put into the UI and the choice of MongoDB is
excellent.

~~~
ericingram
Thank you, I'd be really interested to get you working with the current
version. I'm looking for Magento developers that can help connect the dots
with that community. E-mail eric at getfwd if you're interested.

------
camurban
Congrats! This is truly awesome.

~~~
ericingram
Thanks Cam :)

------
yakshay
Looks incredibly cool. What JS library/framework is this using?

~~~
ericingram
Only jQuery at the moment. The UI seems fast because MongoDB is very good with
caching and speed in general, so it kind of feels like a client-side UI, but
it's actually all server side rendering.

