Gimba - A shopping app over a store with no API
A B2B e-commerce app for iOS and Android, with the integration layer built over a system that only exposed database procedures.
Buying company supplies from your phone
Gimba sells supplies to companies. The operation already had an online store and already sold on the web. What was missing was the app, and the initial request looked simple: build the iOS and Android app and integrate with the existing back end.
The challenge that surfaced in week one
The existing back end had no integration to consume. The store was an ASP.NET system over SQL Server, and data access happened through database procedures, not endpoints. Shipping calculation, favourite lists, customer registration: all of it lived as procedures.
In other words, before there could be an app there had to be a layer translating that into something an app could consume. That shifted the centre of gravity of the project, which stopped being only mobile front end.
- Give API shape to a system that exposed procedures. Work across three parties: front end and integration layer on the X-Apps side, the API on another vendor's side, and the legacy system on Gimba's side. Develop entirely through the client VPN, the only route into the environment.
The missing layer
The answer was a dedicated service in Strapi over MongoDB, deployed to a staging environment, acting as aggregator and intermediary: on one side it talked to the SQL Server procedures and to the REST API maintained by the partner vendor, on the other it handed the app a stable contract.
That design solved three things at once. It gave the app a predictable interface even with the legacy shifting behind it. It made it possible to assemble responses the legacy did not assemble, such as the persisted cart used at credit card checkout. And it concentrated the translation between the database world and the app world in a single place.
The operation's admin panel, with banner and featured link control, came out of the same Strapi, with no separate system.
What the app does
The flow is corporate purchasing, and that shows in the choices.
- Sign in as a company or as a person. Login by company or personal tax ID, with corporate registration, plus Facebook and Google. Find the product. Category listing, search and barcode scanning with the camera, which is how a buyer finds the item they already use. Lists and favourites. Corporate buyers reorder, so lists are part of the flow, not an extra. Cart and checkout. Separation of identical items in the cart, discount coupons and shipping calculation. Pay the way companies pay. Bank slip, downloadable inside the app, and credit card. Follow up. My orders, my details and profile editing. Physical stores. Location by geolocation.
The VPN, and what it taught
It is worth recording the point that cost the most time in this project, because it shows up in no architecture diagram: all development depended on the client VPN to reach the environment.
The connection dropped at short intervals, and each drop took down the database connection pool and stalled the integration layer. The symptom arrived as a timeout, but the cause was networking.
X-Apps diagnosed it and proposed the structural alternative, a direct connection between the two networks, rather than continuing to treat the symptom.
The lesson for similar projects is simple: when the client environment is the only route to the data, the stability of that access is a project requirement, not an infrastructure detail. It has to enter planning with the same weight as a feature.
Stack and practices
- React Native with Expo for iOS and Android. Strapi over MongoDB as integration layer and admin panel, on Node.js. Consuming the client's SQL Server procedures and the REST API maintained by the partner vendor. Docker and Kubernetes orchestrated in Rancher, deployed to the cloud. Automated build and deploy pipeline, announcing each stage in the project channel. Navigable Adobe XD prototype, signed off with the client's marketing team before development. Weekly sprints with a scope package per week.
Server specification for the environment was also delivered to the client, with operating system, processing, memory and disk sized for the operation.
Does your legacy system not speak to apps?
Plenty of systems that have run well for years have no way of being consumed by an app, and that does not mean replacing the system. It means building the right layer in between. X-Apps designs and builds that bridge, leaving the legacy where it is.