Introducing A Scalable iOS Application Into A Growing Tech Stack
The SSENSE website is amazing! It stands out for its simplicity and elegance. It is not a coincidence that the website has been the primary medium of interaction for SSENSE and its users since its foundation. Now, imagine the excitement when my team and I were tasked with creating a new channel from scratch that matches the website in quality and stands out in innovation: welcome to iOS mobile development at SSENSE.
In this article, I will take you through our technical and architectural journey in developing the first customer-facing SSENSE mobile application.
Single-Client vs Multi-Client: A Mindset Change
Calling our architecture single-client would be misleading, our stack is also composed of a custom mobile point of sale which powers the SSENSE MONTRÉAL flagship and many other smaller applications with individual purposes. For this article’s purpose, let’s take into consideration that these client applications are not customer-facing, and have much smaller traffic and update rates when compared to the website.
Our first challenge was to position iOS development in the everyday planning of all features. We started with the question “How will this affect mobile?”, so other teams would consider and acknowledge that we are in a multi-client stack. This question soon shifted into “Where should this feature be available first?” and “How can we use each platform’s characteristics to better deliver this feature?”. It was soon evident that both clients would have a different feature set, but the user experience should be kept the same between them.
Adding an iOS application to our stack shifted the gravitation center out from the website and put engineers in a more challenging space. We now think about features as a set of APIs, and use them to harness the best experience on each channel.
A Fast-Paced Environment
SSENSE delivers hundreds if not thousands of updates in our stack transparently each day. This is possible on the website and all web-based back-office systems but is different for iOS. The release flow for iOS involves Apple’s approval and finally a download to the customer’s device. Releasing new app versions with the same frequency would either be impossible, or prompt our customers to uninstall the app.
To solve this problem, we imagined a layer that would remotely control and change the app behavior at any time. Coupled with this layer came the vision that the app would need to be a highly configurable shell, responsible only for state management, which would naively present data to its users.
After due research, the Back-End for Front-End (BFF) design pattern liberated us from the problems stated above. The only thing left was to properly divide the responsibilities of each service:
The Perfect User Experience
Being the luxury fashion platform that we are, we aim to deliver the perfect user experience. One of our main concerns was regarding server-to-client data delivery. We can’t control how good or bad our clients’ network is, but we can control how we use it. The perfect technology for communicating between the BFF and the app would ideally allow us to minimize the number of requests from one to the other, and also optimize what data is transmitted when the requests are complete.
We found this to be a fitting problem for GraphQL. Instead of making individual requests to retrieve items like a list of designers or a list of categories, we could create ‘resolvers’ which would allow the app to retrieve both in a single request, or further define which fields of which entity it needs right away. The flexibility it provides to the client application is groundbreaking, and is one of the key reasons why the SSENSE app has a snappy response time and minimal network dependencies.
To SWIFT or Not to SWIFT?
Definitely SWIFT.
At this point, we already knew the responsibilities of the app within the architecture we were building, and we knew it should not do anything too complex. The app’s internal architecture was built with the intention of being lean and simple, so we opted for the classical Model-View-Controller (MVC) pattern. Powered by dependency injection and our component library, each screen acts as a collection of reusable components, enabling us to iterate quickly on many variations of the design.
Node.JS + AWS Lambda
The app itself is not provisioned, so why should its BFF be different? Provisioning the BFF as a service would create an imbalance between what we scale and what we don’t. After several successful projects delivered via AWS Lambda, we were confident that it fit our needs both for its utility and design philosophy. You can read more about how we manage and deploy AWS Lambda functions here.
Following this choice, came the question of programming language for the BFF. The majority of SSENSE front-end products are Node.js based, so choosing Node.js for our BFF helped democratize the mobile development initiative. It meant that any other developer, even without an iOS background, could contribute.
In a Nutshell: The Architecture
Introducing a scalable iOS application into a growing tech stack goes beyond XCODE. For SSENSE, it was important to understand our current challenges and put the right tools and layers in place to address them. Hopefully this article has provided insight on some of the key decisions behind building the SSENSE app, which we’re happy to say is available for iOS download here.
Diagrams by Max Kaplun.
Editorial reviews by Deanna Chow, Liela Touré & Prateek Sanyal.
Want to work with us? Click here to see all open positions at SSENSE!
