Context
Late 2024, I decided to build out an AI embedded application for use on the Shopify app store. Because we have not release just yet, I cannot speak on the nature of this but I would like to write on my experiences so far.
Scaffolding:
Building out the foundation for this application was a bit difficult for a number of reasons. Firstly, Remix, the Shopify recommended JS framework, is fundamentally different from other traditional JS build outs. It uses loaders and action functions that act as the backend endpoints and data fetching routes. This is compared to a more traditional separate backend build using something like ExpressJS. It tries to simplify and abstract this relation and incorporate route definitions and fetching into the same file system. Its certainly not my favorite flavour of a JS framework but it has worked thus far.
High level view
Above is a high level view of how a Remix application works within Shopify and the embedded environment. Client side rendering happens with React, and then loaders abstract away backend calls to resources. For resource only routes, you can use a utils/ approach or create routes with only loaders and actions.
Lower level architecture
Front end design
Aside from recycling components for the frontend written in React, using Polaris was relatively straightforward. It is a simpler css library with a lot of Shopify tailored themes and design to match their recommended themes.
Middleware and Backend design
Middleware is abstracted away for Shopify apps and is actually handled in certain configuration settings. Shopify embedded apps are fairly different from a regular webapp because things are rendered within an Iframe so shopify controls everything up to this rendering. CORS and other policies are handled within the shopify.app.toml file.
The most important backend elements that I have incorporated into this project thus far is my use of a domain, service and utility layer. Incorporating these layers has allowed me to easily separate concerns and
make adding new features and routes easy. Simple routes usually stay located within the route definition itself in remix, but when you start to add in api calls to different providers and other DB lookups having layers that have a predefined structure to implement makes life easy.
Since I wanted to make this project highly scalable because I anticipate other engineers working on this in the future
Deployment
Deployment, as a result of the use of a single docker container, it is quite easy if using a platform as a service such as a Heroku. Given I didnt want the overhead of IAC at the moment, I used the existing Shopify and Heroku integration to deploy my application. Using Heroku CLI is simple enough and there are a variety of add-ons, within the Heroku platform that make adding logging and a DB easy.
Notable quirks
A particular quirk that I had some issues with initially was route naming conventions and file structure. In an attempt to make things simpler from a file organization point of view, with flat routes introduced as a part of v3 (I think) routes are organized by . . indicated in the file. So naming a route, app.page.tsx will generate a /app/page route and app.$slug.tsx will generate a target with /app/123.