12 ms·

How Shopify Uses WebAssembly Outside of the Browser

243 points by oedmarap 6y ago

colesantiago 6y ago
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. :/
- SingAlong 6y ago
  They do allow merchants to sell subscriptions - https://help.shopify.com/en/manual/products/subscriptions https://help.shopify.com/en/manual/products/subscriptions
  - rattray 6y ago
    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 https://apps.shopify.com/collections/checkout-subscription
    - TheGeminon 6y ago
      Yes, I work at Shopify and our first party subscription support just recently launched a few months ago.
      - rattray 6y ago
        Awesome! Very exciting. I recently launched a small business which has a natural subscriptions element (https://narwallmask.com 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...
        ewalk153 6y ago
        Perhaps in the future (on the team that added subscriptions at Shopify)
- xg15 6y ago
  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...
  - deleted 6y ago
    [deleted]
  - gfxgirl 6y ago
    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.
    - marcosdumay 6y ago
      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.
      - gfxgirl 6y ago
        The Blazor tutorials just run (C#). It is trivial Same with Unity. Click build. Trivial I suspect others are similarly trivial
    - xg15 6y ago
      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.
- sradman 6y ago
  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.
CyberRabbi 6y ago
Technically you can accomplish the same thing using seccomp, I.e. the way most services run third party native code to process untrusted data, e.g. imagemagick. That’s what I would probably do since it’s more efficient and simpler. No need for a compilation step or an interpreter. No need to trust the (likely complex) webassembly runtime to be bug free. Edit: most responses are being made under the assumption that seccomp is the same as seccomp-bpf. The two are different and designed for different use cases. For example it is not possible to run a wasm JIT entirely under seccomp but is possible under seccomp-bpf. Seccomp was specifically designed for the use case described in this article by Shopify. You can read more about the differences here https://en.wikipedia.org/wiki/Seccomp https://en.wikipedia.org/wiki/Seccomp
- xg15 6y ago
  I think WASM has the added benefit of being platform-independent - which is generally a good thing but can even be a security feature: With native code, even if run without privileges, you need to expose a lot of details about your hardware that malicious users could use to find vulnerabilities. With WASM, the host can keep the actual hardware architecture and even the actual machine code that is generated a secret.
  - CyberRabbi 6y ago
    Yeah but there’s a nearly 100% chance your server platform is x86 and in the case that it changes, it will be a gradual change in the long term. While it’s nice to have the platform independence, it has nearly zero practical utility here. If you’re making a security argument, using seccomp over a complex webassembly runtime reduces your attack surface.
  - croes 6y ago
    Security by obscurity?
- feanaro 6y ago
  Shopify is already a known seccomp user (for running Ruby in the mruby VM), so I think there's no reason to assume the WebAssembly runtime is not in a seccomp jail too.
martin_drapeau 6y ago
Could someone eligthen me. Why not just use JavaScript? It is being used by Cloudflare on the edge, and AWS lambda. Why need to go to WASM?
- enriquto 6y ago
  The issue is quite symmetrical, isn't it? Somebody could ask: why not use just WASM? Why need to go to JavaScript? This is a better question, actually, if you already have a codebase in another language that can you can easily compile to wasm, but not to javascript.
  - rattray 6y ago
    Because as the article states, JavaScript is widely used by their plugin developers, while AssemblyScript is still nascent (little-used, missing features, has bugs).
  - runawaybottle 6y ago
    Like what? This is like me saying I have a mostly html/css/js website, and I just need it converted to a native Android app. Well no right? I have website. I don’t have mobile app that just needs to switch platforms. Do you have a website built in another language already? Then sure, all you need to do compile it via WASM. What I bet most of you have is a program for a totally different platform. In that case, you have to redo it, so why not just do it right.
- alquemist 6y ago
  * Predictable performance. * A wide ecosystem of mature language toolchains. * Simplicity: JS implementation contain sophisticated JITs, which are harder to prove correct compared to a simple ASM translator. * Portability: not tied to a specific HW architecture.
  - rattray 6y ago
    For clarity, do you work at Shopify? These all sound like valid reasons, I'm just curious if they're the ones that motivated the Scripts team at Shopify.
peteretep 6y ago
> you cannot express anything malicious in Wasm This feels like a comment that will as age as badly as “you can’t get a virus just from looking at an email”
- bagels 6y ago
  Sounds like the promises made about the jvm.
  - nih0 6y ago
    can u elaborate on these jvm promises?
    - officialchicken 6y ago
      The "sandbox" promise was/is still offered as the primary line of defense for Java. "The first version of Java was released by Sun Microsystems in 1995 [2]. One year later, researchers at Princeton University identified multiple flaws enabling an analyst to bypass the sandbox [3]. The authors identified weaknesses in the language, bytecode and object initialization, to name a few, some of them still present in Java at the time of writing."[0] [0] https://www.exploit-db.com/papers/45517 https://www.exploit-db.com/papers/45517 [2] http://www.oracle.com/technetwork/java/javase/overview http://www.oracle.com/technetwork/java/javase/overview [3] Drew Dean, Edward W. Felten, Dan S. Wallach. "Java security: From HotJava to Netscape and beyond." In Security & Privacy, IEEE, 1996
      - marcosdumay 6y ago
        The Java sandbox trusted any code signed with a SSL certificate by design, what didn't stop Sun from announcing it was secure and everything.
- jedisct1 6y ago
  You can’t express anything malicious in JavaScript either, yet vulnerabilities are constantly found in web browsers, including WebAssembly JITs. You can express malicious things in Go, yet the number of RCEs in Go apps is pretty much zero.
xtiansimon 6y ago
This is PR about Shopify’s use/promise of WebAssembly—cool. I get WebAssembly tech is cool. I’m interested why Shopify is practically the only sales platform that gets ‘airtime’ at HN. Is this because partner apps are using Ruby? Does it have something to do with the governance of Shopify? Community of Canadians on HN? I have some experience with Square, and a few others. I’m an interested party.
- louis-paul 6y ago
  Do Shopify's competitors produce similarly high-quality engineering content? (if you know some, please link!)
  - bdcravens 6y ago
    Bigcommerce does have a developer blog, but it seems a bit more limited in scope: https://medium.com/bigcommerce-developer-blog https://medium.com/bigcommerce-developer-blog
- christophilus 6y ago
  Amazon gets lots of airtime and is a Shopify competitor. Stripe gets lots of airtime and is a Shopify competitor. Anyway, Shopify’s engineering blogs can be worthwhile, so they make it to the front page. They do interesting work at pretty big scale, provide in depth writeups from time to time, and folks like me enjoy reading them. I see nothing suspicious about it.
  - hobofan 6y ago
    > Stripe gets lots of airtime and is a Shopify competitor. Barely. AFAIK Shopify Payments is built on top of Stripe. They only compete on their Capital products, though given that most of Shopify's financial products seem to be built on Stripe, I'm not even sure if that's true.
  - xtiansimon 6y ago
    > "I see nothing suspicious about it." I didn't intend to imply anything of the sort. I gather from your response including Amazon you might have a different perspective. I'm interested in sales platforms for small business retail. Platforms which let business owners put a store on the web and maintain their own website design. Shopify's turn-key solution lets you have a stores without all of the Platform cruff. You can seel goods on Amazon, but you're just a another 'seller' under the branding of Amazon.com (unless there is another competing service I'm unaware of). Personally, I get to see a lot of small businesses from the Admin side. And Shopify's partner platform is one of the most robust. Pricing is competitive (for the businesss) and they're very developer friendly. No. I really like Shopify, and I was curious why others _like_ it so much. haha. I understand where you might default to thinking I'm suspicious. We're all suspicious. And I see a lot of businesses who go full-in on a platform (POS, online retail) and when it comes to getting financial reports or API access you might want, they are unhelpful and very costly. (Don't get me started on Third-Party Online Ordering Services like DoorDash or Ubereats).
azangru 6y ago
The article starts with "what is webassembly", but doesn't breathe the keyword WASI [0], although they are using a service that's implementing it? [0] https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/ https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...
- lsaferite 6y ago
  The linked page on Lucet does call out WASI if that make it any better.
gravitas 6y ago
Since we're here talking about Shopify - nearly every small shop (1-10 person makers) I buy from who uses the platform could not (in the past 30 days): (a) change the email address associated with an existing account with history, and (b) could not delete or change or transfer the orders from the old account to the new I'm working through an email change and have discovered the above via hundreds of my logins - Shopify by far is the largest defunct platform which locks your account in using an email address, neither the user nor admins can "fix" it. All shop owners indicate to me they've emailed Support and gotten no help, every solution has been "just make a new account".
- tuwtuwtuwtuw 6y ago
  What's the problem with making a new account? Should take a few minutes at most?
  - gravitas 6y ago
    Losing years worth of order history with that vendor? Having ghost accounts in a vendor database you can't delete, which has your previous order's PII (home address, etc.) tied to? The problem is not making a new account, it's appropriately dealing with the one containing personal information you're leaving behind.
    - jeromegv 6y ago
      You can’t change the email on existing accounts however you can definitely delete it. See the docs https://help.shopify.com/en/manual/your-account/privacy/GDPR/processing-gdpr-data-requests https://help.shopify.com/en/manual/your-account/privacy/GDPR... Their account management is definitely poor. But you seem to make it a bigger deal than it is. You don’t have to lose the order history, even if you don’t have access to the email anymore nothing would prevent you from logging again with the user/pass. And the order history is really the only valuable info... you can also save the email with your receipt. It’s not ideal but again, how much it actually impacts your life is about close to nothing. Request the account to be deleted under GDPR and then save the emails with your order history.
twic 6y ago
So how about garbage collection? WASM doesn't have GC in the machine model, right? So either customers have to use a language with manual memory management, which is hard work, or use one with GC and then compile the collector into their binaries, which means bloat, and possibly a sub-par GC. I guess what I'm saying is that it seems like it would have been better to have used a JVM.
- __s 6y ago
  https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...
  - twic 6y ago
    Something like this seems really important to (some branches of) the future of WASM, but this is still just a proposal, right?
    - azakai 6y ago
      It is still a proposal, but it's one of the proposals most worked on atm, there's a lot of activity.
- imtringued 6y ago
  How would that work? Secure multi tenancy is a difficult problem in its own right. You would now have to build a security layer outside the JVM because the JVM is exposing too many interfaces. You can use containers but the amount of interfaces a container exposes is still high enough that a container escape is possible. Then you need a security layer on top of containers based on VMs. At this point rolling your own security solution is either going to be highly inefficient because you are allocating too many resources to individual customers or expensive because developing infrastructure management to stay secure doesn't make your company more profitable. Your last hope would be to use an off the shelf solution like firecracker to run each JVM in a VM. Alternatively you can just use a runtime that is sandboxed by default and avoid the cat and mouse game.
- 6y ago
sradman 6y ago
The underlying platform is ahead-of-time compiled WebAssembly but AssemblyScript, a variant of TypeScript, will be the only supported language: > Theoretically any language with a Wasm target can be supported, but the effort developers spend to conform to our API is better focused on solving problems for merchants. That’s why we’ve chosen to provide first class support to a single language that includes tools that get developers up and running quickly.
- johnnycerberus 6y ago
  Like always, browsers are a funny ecosystem and very unpredictable. In all this time I thought that I could see a rise in the adoption of C and Rust libs by the community through WASM but now instead we are building around AssemblyScript. Touche.
  - remram 6y ago
    We just have to compile Rust and C to AssemblyScript, à la asm.js, and come full circle (again).
  - coding_lobster 6y ago
    It's interesting that this seems on one hand "unpredictable" while also being logical. If a company has employees familiar with TypeScript (or even JS) and they have to make a choice between yet another flavor of that or a new language like C/Rust... well the choice is understandable. Once again the path of least resistance to a new web technology ended up being JavaScript - it just wasn't immediately obvious when WASM first emerged.
    - HoolaBoola 6y ago
      I know I'm deliberately misinterpreting you, but > a new language like C is a funny thought ^_^
    - woodpanel 6y ago
      A JavaScript SuperSet becoming the de facto standard of writing for WASM - I think one can file this under „worse is better“.
coderbe92 6y ago
Shopify is a waste of money. Use SendOwl with your own stack instead.

243 points by oedmarap 6y ago

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. :/

SingAlong 6y ago
They do allow merchants to sell subscriptions - https://help.shopify.com/en/manual/products/subscriptions https://help.shopify.com/en/manual/products/subscriptions
- rattray 6y ago
  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 https://apps.shopify.com/collections/checkout-subscription
  - TheGeminon 6y ago
    Yes, I work at Shopify and our first party subscription support just recently launched a few months ago.
    - rattray 6y ago
      Awesome! Very exciting. I recently launched a small business which has a natural subscriptions element (https://narwallmask.com 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...
      - ewalk153 6y ago
        Perhaps in the future (on the team that added subscriptions at Shopify)
xg15 6y ago
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...
- deleted 6y ago
  [deleted]
- gfxgirl 6y ago
  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.
  - marcosdumay 6y ago
    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.
    - gfxgirl 6y ago
      The Blazor tutorials just run (C#). It is trivial Same with Unity. Click build. Trivial I suspect others are similarly trivial
  - xg15 6y ago
    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.
sradman 6y ago
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.

CyberRabbi 6y ago

Technically you can accomplish the same thing using seccomp, I.e. the way most services run third party native code to process untrusted data, e.g. imagemagick. That’s what I would probably do since it’s more efficient and simpler. No need for a compilation step or an interpreter. No need to trust the (likely complex) webassembly runtime to be bug free. Edit: most responses are being made under the assumption that seccomp is the same as seccomp-bpf. The two are different and designed for different use cases. For example it is not possible to run a wasm JIT entirely under seccomp but is possible under seccomp-bpf. Seccomp was specifically designed for the use case described in this article by Shopify. You can read more about the differences here https://en.wikipedia.org/wiki/Seccomp https://en.wikipedia.org/wiki/Seccomp

xg15 6y ago
I think WASM has the added benefit of being platform-independent - which is generally a good thing but can even be a security feature: With native code, even if run without privileges, you need to expose a lot of details about your hardware that malicious users could use to find vulnerabilities. With WASM, the host can keep the actual hardware architecture and even the actual machine code that is generated a secret.
- CyberRabbi 6y ago
  Yeah but there’s a nearly 100% chance your server platform is x86 and in the case that it changes, it will be a gradual change in the long term. While it’s nice to have the platform independence, it has nearly zero practical utility here. If you’re making a security argument, using seccomp over a complex webassembly runtime reduces your attack surface.
- croes 6y ago
  Security by obscurity?
feanaro 6y ago
Shopify is already a known seccomp user (for running Ruby in the mruby VM), so I think there's no reason to assume the WebAssembly runtime is not in a seccomp jail too.

martin_drapeau 6y ago

Could someone eligthen me. Why not just use JavaScript? It is being used by Cloudflare on the edge, and AWS lambda. Why need to go to WASM?

enriquto 6y ago
The issue is quite symmetrical, isn't it? Somebody could ask: why not use just WASM? Why need to go to JavaScript? This is a better question, actually, if you already have a codebase in another language that can you can easily compile to wasm, but not to javascript.
- rattray 6y ago
  Because as the article states, JavaScript is widely used by their plugin developers, while AssemblyScript is still nascent (little-used, missing features, has bugs).
- runawaybottle 6y ago
  Like what? This is like me saying I have a mostly html/css/js website, and I just need it converted to a native Android app. Well no right? I have website. I don’t have mobile app that just needs to switch platforms. Do you have a website built in another language already? Then sure, all you need to do compile it via WASM. What I bet most of you have is a program for a totally different platform. In that case, you have to redo it, so why not just do it right.
alquemist 6y ago
* Predictable performance. * A wide ecosystem of mature language toolchains. * Simplicity: JS implementation contain sophisticated JITs, which are harder to prove correct compared to a simple ASM translator. * Portability: not tied to a specific HW architecture.
- rattray 6y ago
  For clarity, do you work at Shopify? These all sound like valid reasons, I'm just curious if they're the ones that motivated the Scripts team at Shopify.

peteretep 6y ago

> you cannot express anything malicious in Wasm This feels like a comment that will as age as badly as “you can’t get a virus just from looking at an email”

bagels 6y ago
Sounds like the promises made about the jvm.
- nih0 6y ago
  can u elaborate on these jvm promises?
  - officialchicken 6y ago
    The "sandbox" promise was/is still offered as the primary line of defense for Java. "The first version of Java was released by Sun Microsystems in 1995 [2]. One year later, researchers at Princeton University identified multiple flaws enabling an analyst to bypass the sandbox [3]. The authors identified weaknesses in the language, bytecode and object initialization, to name a few, some of them still present in Java at the time of writing."[0] [0] https://www.exploit-db.com/papers/45517 https://www.exploit-db.com/papers/45517 [2] http://www.oracle.com/technetwork/java/javase/overview http://www.oracle.com/technetwork/java/javase/overview [3] Drew Dean, Edward W. Felten, Dan S. Wallach. "Java security: From HotJava to Netscape and beyond." In Security & Privacy, IEEE, 1996
    - marcosdumay 6y ago
      The Java sandbox trusted any code signed with a SSL certificate by design, what didn't stop Sun from announcing it was secure and everything.
jedisct1 6y ago
You can’t express anything malicious in JavaScript either, yet vulnerabilities are constantly found in web browsers, including WebAssembly JITs. You can express malicious things in Go, yet the number of RCEs in Go apps is pretty much zero.

xtiansimon 6y ago

This is PR about Shopify’s use/promise of WebAssembly—cool. I get WebAssembly tech is cool. I’m interested why Shopify is practically the only sales platform that gets ‘airtime’ at HN. Is this because partner apps are using Ruby? Does it have something to do with the governance of Shopify? Community of Canadians on HN? I have some experience with Square, and a few others. I’m an interested party.

louis-paul 6y ago
Do Shopify's competitors produce similarly high-quality engineering content? (if you know some, please link!)
- bdcravens 6y ago
  Bigcommerce does have a developer blog, but it seems a bit more limited in scope: https://medium.com/bigcommerce-developer-blog https://medium.com/bigcommerce-developer-blog
christophilus 6y ago
Amazon gets lots of airtime and is a Shopify competitor. Stripe gets lots of airtime and is a Shopify competitor. Anyway, Shopify’s engineering blogs can be worthwhile, so they make it to the front page. They do interesting work at pretty big scale, provide in depth writeups from time to time, and folks like me enjoy reading them. I see nothing suspicious about it.
- hobofan 6y ago
  > Stripe gets lots of airtime and is a Shopify competitor. Barely. AFAIK Shopify Payments is built on top of Stripe. They only compete on their Capital products, though given that most of Shopify's financial products seem to be built on Stripe, I'm not even sure if that's true.
- xtiansimon 6y ago
  > "I see nothing suspicious about it." I didn't intend to imply anything of the sort. I gather from your response including Amazon you might have a different perspective. I'm interested in sales platforms for small business retail. Platforms which let business owners put a store on the web and maintain their own website design. Shopify's turn-key solution lets you have a stores without all of the Platform cruff. You can seel goods on Amazon, but you're just a another 'seller' under the branding of Amazon.com (unless there is another competing service I'm unaware of). Personally, I get to see a lot of small businesses from the Admin side. And Shopify's partner platform is one of the most robust. Pricing is competitive (for the businesss) and they're very developer friendly. No. I really like Shopify, and I was curious why others _like_ it so much. haha. I understand where you might default to thinking I'm suspicious. We're all suspicious. And I see a lot of businesses who go full-in on a platform (POS, online retail) and when it comes to getting financial reports or API access you might want, they are unhelpful and very costly. (Don't get me started on Third-Party Online Ordering Services like DoorDash or Ubereats).

azangru 6y ago

The article starts with "what is webassembly", but doesn't breathe the keyword WASI [0], although they are using a service that's implementing it? [0] https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/ https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...

lsaferite 6y ago
The linked page on Lucet does call out WASI if that make it any better.

gravitas 6y ago

Since we're here talking about Shopify - nearly every small shop (1-10 person makers) I buy from who uses the platform could not (in the past 30 days): (a) change the email address associated with an existing account with history, and (b) could not delete or change or transfer the orders from the old account to the new I'm working through an email change and have discovered the above via hundreds of my logins - Shopify by far is the largest defunct platform which locks your account in using an email address, neither the user nor admins can "fix" it. All shop owners indicate to me they've emailed Support and gotten no help, every solution has been "just make a new account".

tuwtuwtuwtuw 6y ago
What's the problem with making a new account? Should take a few minutes at most?
- gravitas 6y ago
  Losing years worth of order history with that vendor? Having ghost accounts in a vendor database you can't delete, which has your previous order's PII (home address, etc.) tied to? The problem is not making a new account, it's appropriately dealing with the one containing personal information you're leaving behind.
  - jeromegv 6y ago
    You can’t change the email on existing accounts however you can definitely delete it. See the docs https://help.shopify.com/en/manual/your-account/privacy/GDPR/processing-gdpr-data-requests https://help.shopify.com/en/manual/your-account/privacy/GDPR... Their account management is definitely poor. But you seem to make it a bigger deal than it is. You don’t have to lose the order history, even if you don’t have access to the email anymore nothing would prevent you from logging again with the user/pass. And the order history is really the only valuable info... you can also save the email with your receipt. It’s not ideal but again, how much it actually impacts your life is about close to nothing. Request the account to be deleted under GDPR and then save the emails with your order history.

twic 6y ago

So how about garbage collection? WASM doesn't have GC in the machine model, right? So either customers have to use a language with manual memory management, which is hard work, or use one with GC and then compile the collector into their binaries, which means bloat, and possibly a sub-par GC. I guess what I'm saying is that it seems like it would have been better to have used a JVM.

__s 6y ago
https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...
- twic 6y ago
  Something like this seems really important to (some branches of) the future of WASM, but this is still just a proposal, right?
  - azakai 6y ago
    It is still a proposal, but it's one of the proposals most worked on atm, there's a lot of activity.
imtringued 6y ago
How would that work? Secure multi tenancy is a difficult problem in its own right. You would now have to build a security layer outside the JVM because the JVM is exposing too many interfaces. You can use containers but the amount of interfaces a container exposes is still high enough that a container escape is possible. Then you need a security layer on top of containers based on VMs. At this point rolling your own security solution is either going to be highly inefficient because you are allocating too many resources to individual customers or expensive because developing infrastructure management to stay secure doesn't make your company more profitable. Your last hope would be to use an off the shelf solution like firecracker to run each JVM in a VM. Alternatively you can just use a runtime that is sandboxed by default and avoid the cat and mouse game.
6y ago

sradman 6y ago

The underlying platform is ahead-of-time compiled WebAssembly but AssemblyScript, a variant of TypeScript, will be the only supported language: > Theoretically any language with a Wasm target can be supported, but the effort developers spend to conform to our API is better focused on solving problems for merchants. That’s why we’ve chosen to provide first class support to a single language that includes tools that get developers up and running quickly.

johnnycerberus 6y ago
Like always, browsers are a funny ecosystem and very unpredictable. In all this time I thought that I could see a rise in the adoption of C and Rust libs by the community through WASM but now instead we are building around AssemblyScript. Touche.
- remram 6y ago
  We just have to compile Rust and C to AssemblyScript, à la asm.js, and come full circle (again).
- coding_lobster 6y ago
  It's interesting that this seems on one hand "unpredictable" while also being logical. If a company has employees familiar with TypeScript (or even JS) and they have to make a choice between yet another flavor of that or a new language like C/Rust... well the choice is understandable. Once again the path of least resistance to a new web technology ended up being JavaScript - it just wasn't immediately obvious when WASM first emerged.
  - HoolaBoola 6y ago
    I know I'm deliberately misinterpreting you, but > a new language like C is a funny thought ^_^
  - woodpanel 6y ago
    A JavaScript SuperSet becoming the de facto standard of writing for WASM - I think one can file this under „worse is better“.

coderbe92 6y ago

Shopify is a waste of money. Use SendOwl with your own stack instead.