REST API request from inside a shopify function

[jessicatrenta]

Hi everyone. 
Is it possible to make a REST API request from inside a shopify function? We have a custom BE and we would like to interrogate it via API call.

Usually in Rust I would do something like this and it would work:

fn main() -> Result<(), Box<dyn std::error::Error>> {  
    let call_my_function = my_function()
    Ok(())
}

#[tokio::main]
async fn my_function() -> Result<(), Box<dyn Error>> {
    let resp = reqwest::get("https://httpbin.org/ip")
        .await?
        .text()
        .await?;
    println!("{:#?}", resp);
    Ok(())
}

But when I try to deploy it in my shopify app I get some errors like:

error[E0583]: file not found for module `sys`

error: Socket2 doesn't support the compile target

and many others.

Thanks for your support. 

[NiceNiceNice]

Hi @jessicatrenta – have you reached out to the product manager for Shopify Functions about an answer? It looks like it’s Nick Wesselman

I’m also very curious about an answer to your question 🙂

[Nick_Wesselman]

Shopify Functions must be WASI compliant and deterministic, so they do not support external API calls. If you need external data for your function, you can place it in either a metafield, a cart attribute, or cart line item property ahead of time, and read the data in your input query.

[garyrgilbert]

Hi @Nick_Wesselman 

So basically what you are saying is that http calls are no supported inside shopifys functions implementation even though there is a crate https://crates.io/crates/reqwest-wasm wasm reqwest crate?

In other words, the ability to affect aspects of the checkout based on external information that is required at that moment or based on real-time information, is no longer possible?  

Cheers,

Gary Gilbert

[Nick_Wesselman]

Correct. This is a result of the intentional design decision of functions to be deterministic.

If you need external data at runtime for your function, you might look at placing it in cart attributes using Checkout UI extensions or the Cart AJAX API.

[garyrgilbert]

Hi @Nick_Wesselman ,

Thanks for answering, I understand that its an intentional design decision, but I'm not sure what that has to do about being deterministic. Maybe I didn't pay attention in my programming class when the subject of determinism came up so correct me if I am wrong, but doesn't deterministic simply mean that given a certain set of inputs the code will always deliver the same result?

If the input is the customers identity + the total value of the checkout and the decision to show the payment method to this customer is based on the credit score of the customer, then this too becomes deterministic.  Because the result of the HTTP call to the credit service and subsequently the decision to show or hide the payment method will always return the same result for the same input (eg. customer information + cart amount).  With the rare exception of a network failure which we would always return a false (e.g. hide the payment method)

We have several Plus Merchants that offer manual payment methods (invoice payment) to their customers who don't want to use a 3rd Party Payment Provider to process these services but simply prevent customers with poor credit ratings from using the payment method. With the current/old checkout.liquid we can remove the payment method quite easily.  With the new functions that flexibility for these Plus merchants goes away, and subsequently the flexiblity to still use the manual payment methods.

Cheers,

Gary

[Nick_Wesselman]

Determinism and computer science aside, Functions are not our intended mechanism at the moment for doing this data integration. What about an offline job which populates a metafield on a customer, combined with a payment customization function? Or a checkout UI extension which populates an attribute on the cart at the start of checkout, based on the external call?

[garyrgilbert]

@Nick_Wesselman , thanks a bunch for taking the time to once again reply, I appreciate it.

I have considered this and that would generally work for returning customers but falls apart for new customers since personalized information (required for a credit check) only gets added within the checkout process.

A customers billing or shipping address exists only after the information step in the checkout for new customers or customers that have not yet logged in, and it is at the payment step where we need to determine whether to allow the customer to use the specified payment method. Ideally, we would only perform the "credit" check once the customer chose the payment method.. which brings me to the ideal "solution"

If we could create a workflow for the custom payment methods similar to what the payment gateways can do (payment authorization with redirect back to Shopify) then all of this could be done "outside" of the checkout. We could "simply" plug into the existing workflows but use it for a custom payment method. This would open up a whole other pandoras box but at least you could still have your walled garden around the checkout in tact. 

But this isn't Disneyland where all my wishes come true 🙂

It's unfortunate for these plus merchants that will be affected by this decision but I guess they will either get over it or migrate to a different solution/system if it's important enough to them.

Cheers and thanks again,

Gary

[Nick_Wesselman]

Hey Gary,

Thanks so much for the detailed reply and info on this merchant use case -- it's invaluable.

I'm not an expert in Checkout UI Extensions, but this use case may be facilitated by existing or future extension points which provide access to the customer information. Both Functions and UI extensions continue to add APIs enable more merchant use cases.

Nick

[Alban2]

Any change in this?
Is it now possible to make requests from inside a Shopify function?
Or is there some other way to implement a server-to-server external API call?

[SMDHH]

It has been made available for a limited functions and only for Enterprise or Plus merchants.

https://shopify.dev/docs/apps/functions/input-output/network-access#availability-of-network-access-f...

Still no news for the general public audience.

[garyrgilbert]

It says shopify for enterprise.. I didnt even know there was such a thing a shopify for enterprise only plus.. I guess enterprise is a better marketing term than simply "plus".

thanks for the heads up.  At least its a move in the right direction.  Will wait till they provide access in the payments function.

Cheers,

Gary

[oceanswave]

I'm also in need of this functionality but this seems too complicated.

My use case is that we have a CRM that contains user information. Based on some profile data, we want to auto-apply discounts.

The implementation could be just a simple webhook response that returns a discount amount based on a customer id on cart mutation.

Instead, one needs to go yak shaving.

[garyrgilbert]

Apparently some functions now allow network acess but currently quite limited.

https://shopify.dev/docs/apps/build/functions/input-output/network-access