Posts Tagged ‘open source’


Announcing Arch – a functional style application framework for React

by Viktor Charypar

Announcing Arch – a functional style framework for React


A little over a year ago, Red Badger teamed up with the Haller foundation to help them build an app for farmers in Africa. Like we always do at Red Badger, we looked at the new and interesting technology available at that point and decided that we’d try and build it using Facebook’s new UI library called React.

Little did we know that within a year, React would become a major part of pretty much all of our client projects and some internal ones. We fell in love with its simplicity and the power of delivering complex user interfaces quickly and with much less bugs than with any other tool before.

Naturally, we started building entire applications with React at the front end and we quickly realised we need a bit more of a pattern to manage state and data in general in the application. At about that time Flux came out and we tried our own implementation of it successfully, but something didn’t feel quite right.

We loved the functional aspects of React, like the fact React components can be pure functions of their props (which works beautifully with LiveScript). It simplifies testing and even just basic understanding of what’s happening in the application at any given time. Passing around references to stores and figuring out what state all the stores are in still felt complex, compared to the beautiful simplicity of React itself.

We really liked the ideas introduced in Om – the React binding for ClojureScript – but making the transition to an entirely different stack felt like a pretty big step. It is also not the easiest thing to eventually hand over to a client, whereas everyone is familiar with JavaScript. We are still keeping an eye on Clojure and ClojureScript for another time. In the meantime we wanted to get the benefits of the architecture in a familiar stack.

At that point, our React stack got quite complicated – we used LiveScript, browserify, tried a couple of different routing libraries to get the isomorphism that React makes so easy, and gradually, our answer to the question “What should I do to get the most out of React?” was getting more and more complicated. So we decided to distill our experiences and opinions into a framework that gives you all of the features we loved and a pattern to build React applications the best way we know how.

We spent the past couple of months slowly building and refining it and towards the end of April, we finally got it to a state where we felt it’s ready to open source. We call it Arch.


Arch is a front-end functional style application framework using React as a UI layer. Arch applications are isomorphic out of the box, including form processing. This means you write your application as if it was client-side only and Arch will manage the server-side portion.

This also means you don’t get any control over the code running server-side, which is a design decision. The theory behind it is that any server-side code you need to run should sit in a separate server application which you talk to over an API. This is very similar, at a high level, to Facebook’s recently announced Relay framework architecture and we agree that the server-side portion of your application should just be separate. (As with anything in Arch, with a bit of effort you can opt-out of the choices we made and run the Arch server from your own node.js/io.js application.) For development, Firebase is a good tool to give you an API based server-side persistence.

Arch applications are written in [LiveScript] by default. We picked it, because it’s a functional language that’s a perfect fit for React and makes it a joy to build React applications. It doesn’t take long to learn (at the end of the day, it’s still just JavaScript) and gives a huge productivity boost while letting you write very, very readable code. Although you can just as easily build Arch applications with ES6 and JSX, it’s definitely worth taking a look at LiveScript.

Central state

The biggest feature of Arch is the application architecture it proposes, inspired by Om and other ideas from functional (and functional reactive) programming. The architecture stands on an idea of central immutable state, describing your entire UI in a simple data structure. That data structure – a single composite value – serves as a complete model of your user interface at any point in time. Your user interface is a pure functional projection of this data structure.

Obviously, rendering a single UI state is not enough to build an application, you need to update it over time in response to the user’s actions, and you need to do it in a way that doesn’t couple your entire application to the structure of the central state. In other words, you need a way to distribute the central state to your UI components and collect the updates they make in response to user events. Om’s and Arch’s solution for this is a Cursor.

Cursor lets you dig down into a composite data structure and pass a reference to that particular path in it that can later be updated. This doesn’t require any understanding of where in the data structure the cursor is pointing to from the receiver (a UI component for example). So if you pass a cursor with a piece of state to a React component, it can safely use it if it was the entire thing. For example (written in LiveScript):

render: ->
  profile-picture picture: @props.user.get ‘profilePicture’

When rendering a profile-picture component we pass in a picture prop, which is a cursor we obtained by getting a profilePicture key from a user cursor, which was passed to us in the current component’s props. Inside, we can then use the value:

render: ->
  dom.img do
    src: @props.picture.get ‘url’ .deref!

The deref! call dereferences the cursor and gives you a plain piece of JSON data back.

Application state and user interface are not the only things you will ever need. There’s always some business logic to do: computations, data validation, sync with an API, collection of some statistics, etc. For that Arch uses state observers.

Each cursor is observable and you can register a change handler on it that can do work every time the value changes. For example talk to a backend API:

query.on-change (q) ->
  # make API request
  .then (results) ->
    search-results.update -> results

Whenever the query changes, this observer makes an API request and updates the search-results cursor with the results from the response.Extracting the business logic into state observers results in easier to reuse React components and a more modular application. Changing a search provider, for example, can be as easy as swapping the relevant state observer without touching the UI components.

Arch focuses on simplicity (as opposed to complexity) and minimal solutions at every step, which sometimes means things seem harder at first. To help people get started, we provide a CLI that helps you generate a new application by simply typing arch-cli init in your Terminal and a server that handles the isomorphic aspect of your app (arch-cli serve). Arch tries to provide a good choice for all the decisions you make when building an application from scratch, but at the same time, not constrain you. We believe the default set of choices we made is sensible, but each decision we’ve made, you should be able to opt-out of. The aim is also to split up arch into submodules, so you can, for example, use just our cursor implementation. All those goals together should hopefully make a good flexible tool for building React applications.

Can I use it?

Hopefully the previous paragraphs gave you enough of an overview of what Arch is, the philosophy behind it and how you would use it. Although Arch itself or parts and ideas from it are used on multiple projects at Red Badger, it’s still very early in its life and not necessarily ready for production without a bit of effort. We’ll continue working on it and post regular updates.

You can find out more about Arch at (currently redirects you to Github, but we should have a website up soon). We’ll appreciate all feedback and examples of the awesome stuff you build with it and hope you’ll like it as much as we do!

Want to work with cutting edge technology, play with new languages and tools or even build and release your own? Then come join us.


Spree Commerce – The future of E-Commerce?

by Cain Ullah


Red Badger are always looking at new ways of working with regard to our tech stack as well as our process engineering methods. Our focus is on helping our clients to realise benefit as quickly as possible.

We’re always looking at where different business verticals have big problems that need to be solved in a smarter way. One such problem that is obvious is the retail sector. Retailers spend a fortune on implementing their e-commerce stores and are often faced with huge problematic programmes that go-live in a big bang release that goes wrong from day 1.

John Lewis spent £40m on a new e-com platform based on ATG Oracle delivered by Deloitte. This took years to implement with a big bang approach at the end of the project. When like John Lewis, you are selling £1bn revenue online, that is a long time and a lot of expenditure before you can start to realise value.

John Lewis CIO Paul Coby said the new platform is considered to be one of the default choices for his industry. “ATG is one of the two or three standard platforms for e-commerce in retail.”

“It will give us nothing fundamentally different initially, as we want a smooth transition. The aim is to give us another 10 years of upward development. For example, how we then integrate mobile and social media and new search engines into the site is going to be key.”

TEN YEARS!! And £40m that gives you nothing fundamentally different.

Delivering these programmes are also not without big problems. £40m for John Lewis’ website is expensive but at least that was what the programme was budgeted at. Another large (to remain nameless) retailer ended up spending six times their original budget for their e-com re-platform onto IBM Websphere Commerce resulting in a cost to date of several 10’s of £millions.

This is quite typical of retailers. Go with what everyone else is doing, feel the pain and spend the cash (because it is seen as the safe bet). Paul Coby is delivering what will be considered a very successful, large scale project that may also be the perfect solution for their organisation. However, for many scenarios, surely there is a better way to deliver E-com solutions?

New Technology (and Open Source)

In recent years the speed at which technology has improved has been incredible. The development of open source software has been particularly impressive. If you speak to Stu he has some strong thoughts on this. His opinion is that Github has been massively influential in how people develop software and the speed at which it is developing as a result. The biggest companies (Oracle, IBM et al) just cannot adapt at the speed at which the collective open source community can (The speed at which things are moving takes a lot of effort to stay on top of the latest greatest. But, it’s worth it!).

Large companies are starting to embrace open source. Several of our clients have allowed us to develop large enterprise applications for them using a modern open source tech stack (Node.js, Ruby, Elasticsearch, RabbitMQ, LiveScript, Component etc, etc…). Walmart are now building all of their mobile commerce applications based on Node.js. They are making a strategic investment in Node.js transitioning from a core Java solution with a vision of revolutionising retail through technology.

Unfortunately Walmart are certainly an exception to the norm in retail. The attitude of using a “default choice” for e-commerce seems to be the norm and with it comes all of the pain and expense.

An opportunity to do things correctly

We have recently had an opportunity to deliver a complete re-platform of a heritage retailer’s e-commerce website. This retailer had no desire to use a huge monolithic solution such as ATG or Websphere Commerce. However, they have been looking at the following options as serious contenders.

  • Magento – Magento is (was) an open source platform built on old technology (PHP) and is incredibly slow. It has got so large (8.2million lines of code) that it has ground to  a halt. It has only 8 open source contributors. That’s 1 million lines of code per contributor! Back in 2011 it was also acquired by Ebay effectively incorporating it as a standalone venture. Who knows what is going to happen to it but if it is to make a comeback, Ebay will need to invest heavily in product development to effectively rebuild it from the ground up.
  • Hybris – Is a Java based (Spring Framework) and has now been bought by SAP. With SAP focusing on a B2B model and immediately hiking the license fees for Hybris, the future of Hybris as a platform for retailers is unknown.
  • Demandware – Built using DMS Script, a proprietary code base based on JavaScript. If you use Demandware, you have the problem of vendor lock-in as it takes specialist skills to manage and update. It also has a license model of 2-3 % of your website’s annual turnover. Depending on the scale of your business, that can build up to a hell of a lot of money over a long period of time and isn’t great if you have a CAPEX oriented business model like our potential client does.

Looking at these three options, we quickly discounted any of them as a viable platform for the opportunity that was on our table. We wanted to do this right with modern, flexible, scalable technology that could be delivered quickly and cheaper to provide the client with real value, allowing them to realise benefit as soon as possible. The client was open to suggestions. They wanted their new solution to enforce their brand, and bring it firmly into the 21st century by being innovative with both technology and delivery methodology.

As a result, we did lots of research around e-com platforms to see if we could find something that fitted our criteria. During our research we came across Spree Commerce.

Enter Spree Commerce


Kicking off the Spree Hackathon

Since finding Spree Commerce, we have been delving deeply into research into the platform (we have just finished a 2 day weekend Hackathon building a store from scratch. More about that in future blogs) and like what we see. Spree storefront is a Ruby-on-Rails open source application. Here are some quick at a glance facts about Spree:

  • It has nearly 500 active contributors to the project which puts it in the top 50 open source projects in the world (out of approximately 3 million total)
  • It has approximately 50,000 lines of code to date (about 100 per contributor)
  • There are already over 20,000 stores on the platform globally
  • It’s had over 225,000 downloads
  • Any Ruby developer can modify the software to meet their store’s exact needs — no proprietary programming skills needed
  • The storefront supports responsive web design out of the box for a great user experience. It also has a complete feature set across Product Catalogue, Marketing & Promotions, Payments, Shipping, Site Management & SEO, Checkout, International Features (such as multi-currency) and Analytics & Reporting.

Spree Hub

As well as the Open Source Spree Commerce Storefront, Spree provide a managed software as a service Spree Commerce Hub. This is basically a message broker that integrates seamlessly with the Storefront. It effectively decouples your Storefront from complex back-end integration and automates all of the logistics between the two. There are lots and lots of out of the box back-end integrations and they continue to grow.

The Spree Hub is fully managed as a service by Spree Commerce so comes at a cost, albeit a very competitive cost. It’s also a yearly license fee that is fixed, so the cost doesn’t escalate depending on the scale of your business (like Demandware).

The Storefront combined with Spree Hub is a very, very compelling option for how to deliver e-commerce platforms smarter. After this weekends hackathon, Red Badger will definitely be recommending it as the way forward to our retail clients.

We are excited by how we can approach building enterprise scale e-commerce platforms, delivering them at a fraction of the cost of other platforms and delivering it incredibly quickly using methodologies such as Kanban and Continuous Deployment. We’re looking forward to using Spree to integrate to the likes of Elasticsearch and then contributing our code back into the community. We’ll be using The Spree Hub as a message broker too. Our clients tend to be large and have the usual complex back-end systems such ERP, Logistics and Fullfillment. In general the integration of many systems is made much easier through Spree. The API in the storefront will allow us to easily integrate native apps as well as a responsive web front-end because they will effectively just be consuming the same data.

The proposal is compelling. At Red Badger, we don’t think there is a better E-com solution than Spree Commerce out there at the moment.

Spree Conf

As part of my investigations into Spree Commerce, I went to SpreeConf in New York in late Feb to meet the community, find out more about the platform and see who is using it and how (I’ll write a separate blog summarising the conference itself so will keep this section short).

At the conference I was blown away by the enthusiasm and energy of the community. Everyone is genuinely excited about what they can do on the platform.

Two key speeches that I’ll mention now were from Antonio Silveira – VP Engineering at GoDaddy (who have just announced their partnership with Spree) and Andy Dunn, CEO of Bonobos who are replatforming to Spree but have also just released their female clothing line in just 96 days for first release.

GoDaddy have a platform upon which 60,000 E-com stores are based. This is on an aging tech stack that is getting a complete overhaul. At the core of this will be Spree Commerce. Interestingly, Antonio stated the following as the key factors in GoDaddy choosing Spree Commerce as their platform:

  • Community – Their activity on Github, how many people are committing etc…
  • Quality – Spree’s code base and Ruby-on-Rails being higher quality than the competition
  • Amazing feature set
  • Vision

Andy Dunn shared the vision sentiment. Basing most of his talk on why E-com is bad business he finished by saying “Spree is here to save the day in transforming e-com”.

Both of these are very compelling views from the guys that are already doing it with regard to Spree Commerce.


As a company Red Badger are very excited about Spree. We feel we can bring something new to the table for our retail clients, both present and future, to help remove the pain and cost that is typically felt by using a “default choice”.

The Spree community is incredible. Spree clients are customising Spree to fix problems they experience (be it an integration to Elasticsearch or a CMS) and with the help of Spree Commerce these are finding their way back into the product. Companies that could be seen as being competitors are sharing their code and their learnings (We had a developer from Rails Dog join us for the Spree Hackathon at our offices this weekend) in true open source fashion. All of this results in a great product, that is improving rapidly and everyone benefits.

Watch this space on updates on our Hackathon and more blogs about our learnings with Spree Commerce.

We have also started a London Spree User Group at our offices to see if we can generate more interest in the open source community here in London and to share war stories.

Hopefully we’ll be delivering our first projects on the platform soon so we’ll keep you updated on that too. We’re looking forward to getting involved with the community, contributing back and making e-commerce a much nicer space to be playing in.

Ref: Spree Commerce Sites

See below for some examples of some nice Spree Commerce sites that are live. I think you’ll agree the user experience and design of these sites are delightful and all are responsive.


XPF goes open source!

by Cain Ullah

To avoid repeating what has been said in previous posts, I’m going to keep this blog as short as possible.

As announced by David in his July post, we have been planning to open source XPF – our layout framework for XNA, for a little while. Jaco Geldenhuys and Jonathan Dickinson have been working around their busy schedules to get the code ready for a public release. We are delighted to announce that this has now been completed and our Github Repository is public.


What next?

XPF is now open to everyone so please go ahead and start to play. If you want to contribute, all the details on how are up on the Github wiki as well as the repository rules and license details. Jaco and Jon will also be doing some work in the developer community to try and attract some potential contributors.

To help you to get started. the Getting Started With XPF blog post has been uploaded to the Github wiki but there are also some historical XPF posts on our blog that are not yet uploaded so you may find some of those useful.

Any new documentation and/or announcements will now be made on the Github wiki rather than our blog. This will avoid the need to retrospectively update old blog posts that are no longer relevant.

So that’s about it! We look forward to seeing how the community can take XPF forward in developing it further. Happy coding!


XPF to be open sourced

by David Wynne

Way back in 2010 we announced the public beta of a new framework called XPF, a layout framework for XNA.  It enabled WPF/Silverlight style layouts to be created in XNA solving the pain point of doing 2D layouts in XNA.  It was built from the ground up in pure XNA, supported data binding, attached properties etc and came with a bunch of out of the box controls like Button, Border and the always popular Grid.


What happened?

We were working on a project that had a huge amount of 3D and 2D content and as such was the test bed and, if you like, the thing driving the backlog of XPF.  We were also planning to productise XPF and sell licences so that others could use it in their products and we could make a few quid.

Two things happened.  The project we were working on fell by the wayside and Microsoft announced that they would allow you to combine Silverlight & XNA on the next version of Windows Phone 7 OS.  The impetus for XPF was lost and, as is often the case with start-ups, our attentions were focused elsewhere.

Where is XPF now?

The code for XPF is still sat in a private repo on  We really did do a ton of work on it, as you can see from the numerous blogs we wrote as we went.  There are literally hundreds of BDD specs covering every aspect and thousands of lines of code goodness.

We still get a lot of interest in XPF and pretty much decided months ago that there wasn’t the market to really productise it, so would instead turn it over to the open source community.  We didn’t really want to just flip the switch, make it public and slap an open source label on it however – we wanted some form of curation.  After all we’ve put a lot of our time and effort into the codebase.

What’s going to happen?

In February I started chatting to a Jaco & Jonathan in South Africa about what was happening with XPF and to cut a long story short, we’ve got to the point where they have agreed to shepard XPF into the open source arena – with some help from us of course.

Jaco, Jonathan & I have just had our first Skype call together to get the ball rolling and over the next couple of weeks they’re going to get the code base updated and ready to go public.

It would be great to see XPF brought back to life and to provide real benefit to those who’ve shown interest in it over the last couple of years.  We’re not totally sure how the project will pan out and obviously it’s early in our working relationship – but hopefully we’re moving in the right direction and together we can open up XPF to everyone!