Moving to Headless Shopify: Moving API calls servside

hat I’ve been thinking about:

We’ve looked at some initial choices of headless apps and we’ve also delved into some tips and common gotchas of the Shopify Hydrogen setup when using the documentation.

Now I thought it would be useful to look into how we’d move a client side api call into the server side.

Let’s also pretend that we are exposing an API secret too on the client before and how we can do it server side more safely (scary).

API Calls Hydrogen

In Hydrogen you can use the “routes'' folder to store your api calls. The approach follows the same routing mentioned in the Remix docs for the file or folder naming convention that is converted into a url.

Our example will be creating a folder (you can also just have a file too) that is called:

api.hello-work - this would translate into mystore.com/api/hello-world

Now inside this folder we create our TS file, called route.ts and inside here we can put a special function called action.

It takes three parameters that we can use to get information about the request, params that are attached to the url and the context of our Remix application.

From here we can then inside our action function look to make sure it is a post request and if not we can throw an error back to the client. You can change this to check for any request as needed.

Once we have our data, we can get our hello world api to do something with it and return a new response back to the user. Here’s a sample of a more complete action and I’ll break it down below.

First, as before we get our params from the action function using object deconstructing and do the same again on the context to get the session, storefront api and env.

Next we check if the request is a POST - then we exit out if it is not. Great to make sure we don’t let through requests we don’t want.

If we are a POST request, we continue by grabbing our ENV variable. This could be an API Secret or anything you like.

We then get the json from the request but if it was a formdata POST request, we could do the same but with a different method which I’ve left in the example.

Finally we grab our param from the JSON called bar and this is set up in TypeScript on the data object so we know what to expect.

Once we have what we need, we return the response back to the client with a new data object using the json method which is a nice wrapper function. We pass two params, one called success so we know that we’ve done what we need to and the other called data which in our example just has a string and appends our bar variable.

This is just a basic example, but using this as a base you can do a whole number of things and all server side which is a lot more secure for your application. Of course client side api calls are still perfectly fine to use depending on the scenario.

4 links you can’t miss:

Remix Action Explained - the docs from the remix site about the action route

Remix API Routes - an overview of how the api routes in remix work in a more general view.

Remix Routing - how you can set up routes based on file structure in your application.

What I had wished I had known about SPAs - a good blog on stackoverflow about SPA applications.

1 app I like:

JudgeMe - We’ve probably all heard of these as they are a big app on the Shopify marketplace and I do like to advise these for anyone looking for a reviews app.

That’s not all though, as an app developer I make integrations for a lot of applications and I’ve found JudgeMe to be amazing in the developer/QA process of making integrations for the system. They provide great support, have decent documentation and their QA process is solid. So if you are in the process of adding integrations or want to but not sure where to start, these people are great to work with.