back

by colesantiago·5y ago·view on hn ↗
What does this mean for Shopify merchants? Is it all just faster apps?

I'm still at a loss that Shopify still does not have a subscriptions product. :/

3 comments
Pro: You don't need server infrastructure to customise a Shopify flow.

Con: You need coders knowledgeable in WASM.

However, I could imagine that an ecosystem of "plugins" could emerge, i.e. ready-made WASM apps that merchants could plug into their stores.

There might be more security issues though, if the developer of the WASM and the merchant using it aren't the same party. I think it will be interesting to see how this will play out.

Then again, it might be sufficient to to code something in an LLVM-supported language of choice, then compile it to WASM and just hook it into Shopify, without needing to understand the WASM code that was generated. Good luck troubleshooting or debugging this though...

Why do you need coders knowledgeable in WASM? The majority of coders will use something else (C, C++, Rust, C#, etc.) The majority of them don't need to know the details of the processor their compiler is targeting.
You're right, but I think nonexistent monitoring/debug capabilities are still a problem. For JS, if something goes wrong, you have a vast array of tools available to troubleshoot the problem. The amount of tools for WASM in the browser are smaller, but at least the code runs in an environment you know and can control. With the WASM plugin approach presented here, you're dependant on the tools the host service (in this case Shopify) provides. There is probably not much hope that they will offer step-through debugging or stack traces in the language the code was originally written, so being able to understand the actual WASM might become more important.

There might also be the point of APIs. I'm no expert, but I imagine in-browser WASM must have access to some set of browser-specific APIs to communicate with JS and the DOM. Shopify won't have those APIs available in its runtime environment, but will probably offer different APIs to communicate with the purchase flow etc. I don't know how the WASM tooling landscape looks, but if most tools assume the browser APIs to be available, this could make it harder to develop WASM for other contexts. E.g., you can compile Unity games to WASM, but that WASM will assume that it runs in a browser. You probably couldn't use Unity to write a Shopify plugin.

At the moment, knowing how to compile X to WASM and have it run is a kind of expertise.

I hope that changes, the sooner the better, but right now it's not trivial.

The Blazor tutorials just run (C#). It is trivial

Same with Unity. Click build. Trivial

I suspect others are similarly trivial

I think it is why they have gone with AssemblyScript as the main supported language. Since it is similar to Typescript, Web developers will likely have a easier time learning it.
It’s mainly about the runtime (lack of it) that language brings, ie. garbage collected language brings garbage collector runtime with it that has to be included with every binary. Even rust and c have (relatively thin) runtimes. AssemblyScript has optional/controllable very thin runtime.

What their decision means in practice is that you can execute any language if you want but they won’t expose any specific runtimes to thin your binary. They will also actively support workflows based on AssemblyScript.

The article ends with:

> As we tear down the boundaries between Partners and Merchants, we connect merchants with the entrepreneurs ready to solve their problems.

"Partners" are a key part here, I think. Merchants can run their own code or possibly install 3rd party partner plugins. This is similar to the way 3rd party Wordpress Plugins work except, unlike PHP, they are small, fast, and safe. They can also run in a multi-tenant Shopify environment that scales safely.

As far as I can tell, the use case is similar to database triggers or custom web request filters: enhance the standard request flow with custom actions.

They do allow merchants to sell subscriptions - https://help.shopify.com/en/manual/products/subscriptions
I think this is super new - there are only two apps that offer subscriptions that integrate with Shopify Checkout, and one of them launched in November it seems and is still in beta:

https://apps.shopify.com/collections/checkout-subscription

Yes, I work at Shopify and our first party subscription support just recently launched a few months ago.
Awesome! Very exciting. I recently launched a small business which has a natural subscriptions element (https://narwallmask.com - a mask with replacement filters, which you may want regularly) but without subs integrated into shopify checkout, I decided simply not to offer it. Maybe now I can!

Can you say whether wasm helped make this happen? Seems quite plausible to me...

Perhaps in the future (on the team that added subscriptions at Shopify)