After many months we have reached our frustration point with our Magento 2 migration path - it's a long sad story for a separate thread - so we are seriously considering instead a lightweight custom frontend using our existing Magento 1.7.x database / admin backend.

The benefits we see:

  • Reduced risk: Existing backend/admin continue to work as usual. No data migration necessary. No staff retraining. Consideration for a future date migration to 1.9.x is a much smaller risk than Magento 2.
  • Improved developer experience: We understand our use case and don't need the kitchen sink of flexibility that Magento framework offers and the burden that goes with such. We want an F5 - or livereload - experience that computes under a second, a directory structure with a max depth of 2 or 3, and just simple code.
  • Easier to recruit non Magento developers: As we are considering either PHP + a MVC framework, or Node.js - with session sharing code, and nginx/haproxy handling the backend split - The talent pool of either seems larger than those with Magento specific experience. We also hope this converts to saner estimates time wise when we need to outsource, we've been getting ridiculous quotes for even the most basic of tasks recently.

So at high-level our implementation plan is to handle in our custom frontend - the homepage and other CMS pages, collectively the category, search result and listing page, and the product detail page. These parts are essentially read-only at the request level - excluding recently viewed, logging and session concerns. We will maintain a flat fast read no-EAV database of information required for these parts, for now we have built a one time sync for testing but will probably rely on triggers, or some form of mysql notify or even code an observer with the m1.7 backend to populate this fast read db as information changes.

We intend to utilize the existing cart, checkout, and account management, and postpone the rewrite, if ever, for these parts to stage 2. Accessing the M1.7 session state was an easy spike outside of Mage::app.

We prototyped the most difficult part early this week - the listing page that touches products (stock, images, parent relationships), category, attributes sets, attributes, and even a third party Amasty plugin for 'better navigation', and it was quite a smooth experience, performant, and almost identical in functionality - we didn't replicate Amasty bugs though.

So it's been a interest week, we go carefully..

Of course we must consider the risk, some things that have come up in discussion:

  • How can we keep our lightweight frontend simple enough that a new developer can pick it up in a morning, do we risk creating a system like Magento without any community, documentation, third party support
  • If we add a new Magento functionality via a module, how much burden are we shouldering by having to implement the frontend part ourselves. Stakeholders have already mentioned a new coupon plugin.
  • Can we always figure out the intent from the backend and database tables? Many plugins are obfuscated.
  • The time saved is it then spent on documentation and other unconsidered pitfalls.

Have anyone attempted or even considered a custom frontend for Magento before? What were the pitfalls you encountered? What other considerations would you factor into a decision like this?

1 Answer 1


Here's a thread about this topic, it's mainly about magento 2:

Magento 2 as a headless solution

Zefiryn gives some practical insight in his second answer, as he has developed 2 headless magento projects.

I myself also did a 1 week prototype for a headless magento 2 solution with a Polymer Frontend, but my company decided to go the saver route of implementing a full magento stack.

The anwser if you should do such a project or not, of course, heavily depens on your requirements. If you don't rely heavily on third-party extensions, then I can see a headless approach being more effective. I've personally enjoyed working on the prototype much more than working with the horrendous magento frontend.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.