In this installment of our case study about working with long term projects I will explain the architectural decisions made by our client, ZEIT ONLINE, regarding the relaunch of their digital subscription platform. Please refer to part 1 of this series for basic information about the project and a discussion of how to deal with the evolution of programming languages and operating systems.
Early on our client had decided to split up the platform into separate services that communicate via HTTP. This would allow them to develop those components using the most suitable technology for each, as well as allowing the services to progress more independently. The existing platform already used a separate service for authentication and storing user profile information. We took it from there and worked with the client to take it a step further.
First we identified the major logical components of the platform:
- User accounts
- Product presentation
- Checkout
- Order management (including data exchange with fulfillment provider)
- Content delivery (via HTTP and E-Mail)
When considering how to divide the whole into services, we found it helpful to elaborate on the interfaces between them. The overall idea here is similar to what is accomplished by writing tests first: by grasping how you will consume an interface, it helps define the implementation more succinctly. In order to keep it simple we imposed a constraint on communications between services: When responding to any request, a service must not depend upon another HTTP request to a third party. That way developers would not have to deal with complex dependencies in their development environment and errors would be easy to locate.
Another important consideration was not to do too many things at the same time. Drupal 6 was fulfilling the roles of delivering content and product presentation to the client's satisfaction and the functionality was provided by a small amount of modules. As an upgrade of those parts to Drupal 7 would be straight forward, that was the direction taken for those items. A new client side order form had been developed already and was in experimental use as an alternative to the Ubercart checkout process.
That left the order management as a candidate for a new service. It needs to take orders from the client side order forms, store them, and send them to the fulfillment provider. It would also need to receive updates about the states of an order from the fulfillment provider. Agaric was asked to develop that component and picked Flask as a framework. That was a subjective choice, any other technology for building web applications could have been employed as well.
In upcoming posts I will cover the individual components and how they fulfill the goals of the overall architecture. ZEIT ONLINE is happy with the architecture and is currently moving further along those lines.
Comments
Add new comment