Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Shopify implemented its secure authentication service

engineering.shopify.com

Post reply on HN
Print view View original

21–30 of 56 posts

Re: How Shopify implemented its secure authentication service

#21

Post by Nextgrid »

eropple wrote: post #19
Nextgrid wrote: post #15

Earlier quoted context omitted.

Remember that the hyped-up companies you hear about on HN & other social media aren't the entire world. There are plenty of companies out there that stay quiet and outside of the spotlight and use the language just fine. The same applies for PHP and other languages that are considered (unfairly IMO) "old-school".

PHP is rarely considered "old school." It's considered bad. And not without reason given its history of hostility to its own developers and the sysadmins who have to manage it. I think pretty much everyone has acknowledged that it's improved. Where opinions differ is in how much it has improved and whether that's enough to entertain its use (my answers to which are "not enough" and "not even if you paid me", respecti…

I agree that PHP is bad in certain ways, even though I started with PHP before transitioning to other languages.

But honestly, every language has to make some trade-offs. Even if PHP has some things that are bad design choices as opposed to trade-offs, it can still be worthwhile to put up with them if you have an existing codebase written in it or want to take advantage of libraries that don't exist in other languages.

As a result I don't consider any language as bad or old school. They might have downsides but 1) the upsides might outweigh them in certain use-cases and 2) any competent developer should be able to make something good with any Turing-complete language so I don't judge by the language alone, and especially not by the "hype factor" of the language.

Re: How Shopify implemented its secure authentication service

#22

Post by pm90 »

corford wrote: post #20
masonhensley wrote: post #12

Earlier quoted context omitted.

Been there, done that - wish it upon no one. If anyone ever brings up the idea of building out oauth or even vaguely user management, I try to point them to at least try a POC (Proof of Concept) with https://www.keycloak.org/ (Apache 2.0 License) or https://www.gluu.org/ (MIT License) before they considering building.

Another solution is OpenLDAP (or JumpCloud) at the root and then supporting software: OpenLDAP ├── PrivacyIDEA (TOTP/MFA with LDAP auth backend) ├──---└── SAML iDp (e.g. SimpleSAMLphp or Shibboleth) for SSO: AWS, Google, Github, Atlassian, Snowflake, Azure etc. ├── Dex (https://github.com/dexidp/dex) for anything that wants Oauth flow ├── Native LDAP for apps that support it (e.g. Metabase, Grafana) ├── Any other cus…

I don’t think anyone building a modern identity solution should base it on openldap. LDAP is amazing as an identity provider in a data center, but does not offer support for modern authentication methods like oath and oidc. As such, it’s not a very good base for creating your organizations identity.

I’m happy to be proven wrong about this. I love open standards and protocols.

Re: How Shopify implemented its secure authentication service

#23

Post by kenrose »

uyuioi wrote: post #17
stickfigure wrote: post #8

Earlier quoted context omitted.

Funny you mention this. I just today had to implement a painful workaround for Shopify's insanely short timeout on product image uploads. On submitting an image url, you apparently get 4s to complete the whole transfer. I found hundreds of people complaining about this in the community forums, going back years. If you're dynamically generating images, or on a congested network, 4s is far too short. Since this is a si…

I do a lot of developing with Shopify and it’s a mess. One of the worst development experiences of all time. Because they’re so monolithic focused. The API’s you can use are pretty sluggish and poorly documented. Rails is just not meant for heavy transactional load. And e-commerce needs async to handle what can be a huge load. Taobao is java or php and they handle load far greater without fault. Shopify is much bette…

> One of the worst development experiences of all time... The API’s you can use are pretty sluggish and poorly documented.

Can you elaborate? Shopify released their GraphQL Admin API in 2018, which has built in documentation, as well as an interactive IDE (Graphiql) that you can run on your shop. As long as you're not doing anything too crazy that exceeds the throttle (e.g., syncing 1000s of products), they're pretty good about listening to developer requests.

https://help.shopify.com/en/api/graphql-admin-api

> Rails is just not meant for heavy transactional load.

Shopify has invested heavily in their sharding setup so that it can be handle high load and scale quickly. e.g., flash sales where baseline traffic will 3x in a matter of seconds. See the discussion of pods:

https://engineering.shopify.com/blogs/engineering/e-commerce...

> And e-commerce needs async to handle what can be a huge load.

Long running processes are async. However, having commerce modeled by a transactional database that provides atomicity is a boon for simplicity. You don't want to deal with eventual consistency when updating inventory or placing orders.

Note: Am ex-Shopify. Ran the API team.

Re: How Shopify implemented its secure authentication service

#24

Post by yellow_lead »

keithwhor wrote: post #5
noodle wrote: post #4

Earlier quoted context omitted.

IIRC there are still many large companies using Ruby/Rails still, they've just also diversified their tech stacks (as larger companies tend to do). AFAIK the list includes: GitHub (MS has a few Rails-based acquisitions now), Airbnb, Groupon, Square, Cookpad, Kickstarter, Hulu, etc..

Pretty sure Stripe is a Ruby shop as well.

Gitlab too it seems.

Re: How Shopify implemented its secure authentication service

#25

Post by planetzero »

eropple wrote: post #19
Nextgrid wrote: post #15

Earlier quoted context omitted.

Remember that the hyped-up companies you hear about on HN & other social media aren't the entire world. There are plenty of companies out there that stay quiet and outside of the spotlight and use the language just fine. The same applies for PHP and other languages that are considered (unfairly IMO) "old-school".

PHP is rarely considered "old school." It's considered bad. And not without reason given its history of hostility to its own developers and the sysadmins who have to manage it. I think pretty much everyone has acknowledged that it's improved. Where opinions differ is in how much it has improved and whether that's enough to entertain its use (my answers to which are "not enough" and "not even if you paid me", respecti…

"PHP is rarely considered "old school." It's considered bad"

PHP hasn't been considered 'bad' for a few years now. It has been battle tested on many large-scale websites.

Now, One of the main issues is that anyone can write a few lines of code and call themselves a developer, so you have horrible code bases still out there...but this has more to do with the developer than the language.

"my answers to which are "not enough" and "not even if you paid me", respectively

I love hearing answers like this. This is why I'm still paid so well to write PHP code after 15 years in the industry.

Re: How Shopify implemented its secure authentication service

#26

Post by chrisseaton »

uyuioi wrote: post #18
Thaxll wrote: post #11

Earlier quoted context omitted.

They're moving slow parts to Go.

Hopefully crystal Lang will make its way into these ruby heavy shops. They’ll get 100x performance without needing to really think in a whole different programming experience.

> without needing to really think in a whole different programming experience

But Crystal has entirely different semantics to Ruby. They look vaguely similar at a superficial level, but the semantics are not even remotely similar.

Re: How Shopify implemented its secure authentication service

#27

Post by save_ferris »

uyuioi wrote: post #18
Thaxll wrote: post #11

Earlier quoted context omitted.

They're moving slow parts to Go.

Hopefully crystal Lang will make its way into these ruby heavy shops. They’ll get 100x performance without needing to really think in a whole different programming experience.

I would love to see this happen, but I don't think it's realistic anytime soon.

Crystal just doesn't have the community that ruby has, and as teams reconsider certain aspects of their applications, languages like Elixir and Go make way more sense.

Creating a compiled language with similar syntax to Ruby is great, but there's so much more involved than just that if you're talking about building a serious, commercial product. And unfortunately, I just don't see Crystal getting that kind of traction in the short term.

Re: How Shopify implemented its secure authentication service

#28

Post by itake »

noodle wrote: post #4
ivankolev wrote: post #2

So is Shopify the biggest fish still on the Ruby stack? Nice article detailing how they did an upgrade to openId connect to allow SSO on multiple shops within a client company.

IIRC there are still many large companies using Ruby/Rails still, they've just also diversified their tech stacks (as larger companies tend to do). AFAIK the list includes: GitHub (MS has a few Rails-based acquisitions now), Airbnb, Groupon, Square, Cookpad, Kickstarter, Hulu, etc..

Insiders at Airbnb told me they are (almost) completely off Rails now. They moved their website to the jvm.

Re: How Shopify implemented its secure authentication service

#29

Post by navs »

kenrose wrote: post #23
uyuioi wrote: post #17

Earlier quoted context omitted.

I do a lot of developing with Shopify and it’s a mess. One of the worst development experiences of all time. Because they’re so monolithic focused. The API’s you can use are pretty sluggish and poorly documented. Rails is just not meant for heavy transactional load. And e-commerce needs async to handle what can be a huge load. Taobao is java or php and they handle load far greater without fault. Shopify is much bette…

> One of the worst development experiences of all time... The API’s you can use are pretty sluggish and poorly documented. Can you elaborate? Shopify released their GraphQL Admin API in 2018, which has built in documentation, as well as an interactive IDE (Graphiql) that you can run on your shop. As long as you're not doing anything too crazy that exceeds the throttle (e.g., syncing 1000s of products), they're pretty…

Kudos to you for the work you and your team did.

I've had a love/hate relationship with the Shopify platform but when it comes to the API it was all love.

Re: How Shopify implemented its secure authentication service

#30

Post by stickfigure »

kenrose wrote: post #23
uyuioi wrote: post #17

Earlier quoted context omitted.

I do a lot of developing with Shopify and it’s a mess. One of the worst development experiences of all time. Because they’re so monolithic focused. The API’s you can use are pretty sluggish and poorly documented. Rails is just not meant for heavy transactional load. And e-commerce needs async to handle what can be a huge load. Taobao is java or php and they handle load far greater without fault. Shopify is much bette…

> One of the worst development experiences of all time... The API’s you can use are pretty sluggish and poorly documented. Can you elaborate? Shopify released their GraphQL Admin API in 2018, which has built in documentation, as well as an interactive IDE (Graphiql) that you can run on your shop. As long as you're not doing anything too crazy that exceeds the throttle (e.g., syncing 1000s of products), they're pretty…

I'm the GP, not the parent, but I'll give you some of my complaints (other than the already mentioned infuriating timeout).

* The Metafields feel both over-engineered and difficult to use. Stripe did a great job - metadata is a set of string key/value pairs that are always fetched when you fetch a thing. Shopify's metafields are typed and need to be fetched explicitly from the REST API. You can't get a list of Products and their associated metafields; you have to fetch each Product's metafields one at a time. It's a critical facility and yet works very poorly.

* The API for metafields is inconsistent. Want to get metafields for a variant? /admin/products/#{id}/variants/#{id}/metafields.json Want to get metafields for a product image? /admin/metafields.json?metafield[owner_id]=#{id}&metafield[owner_resource]=product_image WAT?

* Variants (and images) have unique ids, but you always have to reference them as /products/123/variants/456. Variants should be /variants/456.

* Suffixing all the requests with .json is annoying and not RESTy. We have content negotiation headers for that.

* Yes, I know you can work around some of this with GraphQL. Does Shopify intend to deprecate the REST API? I am not personally a big fan of GraphQL, but if the REST API is getting dustbinned, I'd like to know about it.

Mind you, this is just what I noticed from a few days of working with the API.

PS IMO, 3x isn't much of a flash! 300x, now we're talking :)

Post reply on HN