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

System Design 101

github.com

Post reply on HN
Print view View original

11–20 of 45 posts

Re: System Design 101

#11

Post by gedy »

gedy wrote: post #10
victor106 wrote: post #7

Good Stuff, About GraphQL, I read that GraphQL is versionless, is it really versionless? If so, how? The link below says you will still need to version but we have some Graphql fans at work and they insist that it does not need to be versioned. [0] https://medium.com/swlh/no-graphql-doesnt-magically-fix-api-...

It's not versionless per se, but given you ask for the specific fields you want (e.g. user { name }), you don't have to be anal about bumping the version every time a new prop is added to a response, such as in REST, e.g. GET /users/1234 However, if you change the data schema around, like `user` is now `person` or something, or a mutation call changes the required params, there's no magic, you either update the clien…

And if not clear GraphQL is not "SQL on the web", so just because your DB schema changes, your GraphQL API doesn't have to change (basically like REST)

Re: System Design 101

#12

Post by artimaeis »

JSavageOne wrote: post #9

> Stack Overflow serves all the traffic with only 9 on-premise web servers, and it’s on monolith! It has its own servers and does not run on the cloud. This is contrary to all our popular beliefs these days. Love this part. I wonder how much of the complexity of microservices and various cloud services are actually adding value on a net basis vs. resume-driven development of some bored backend engineer.

I also love this anecdote -- but the SO engineering team that made that possible is _not_ your average LOB engineering team in my experience. Those guys were like C#/SQL technomancers. SO is a great example of just how much is possible with a .NET monolith, but very few teams are going to be capable of driving the machines that hard.

Re: System Design 101

#13

Post by tynorf »

gedy wrote: post #11
gedy wrote: post #10

Earlier quoted context omitted.

It's not versionless per se, but given you ask for the specific fields you want (e.g. user { name }), you don't have to be anal about bumping the version every time a new prop is added to a response, such as in REST, e.g. GET /users/1234 However, if you change the data schema around, like `user` is now `person` or something, or a mutation call changes the required params, there's no magic, you either update the clien…

And if not clear GraphQL is not "SQL on the web", so just because your DB schema changes, your GraphQL API doesn't have to change (basically like REST)

This is a very important point.

I'd argue all these "publish your DB schema as a GraphQL endpoint" frameworks that seem to proliferate have done a lot of damage to GraphQL's reputation. Strongly coupling data to presentation seems like such an obvious anti pattern, yet tools doing just that seem to be very popular for some reason.

Re: System Design 101

#14

Post by gtirloni »

danielvaughn wrote: post #4

ByteByteGo is one of the best YouTube channels I've come across. Really well done content, all explained very clearly.

I find it very shallow. Sometimes I wonder if the person presenting it actually has deep knowledge or is just reading bullet point articles.

Re: System Design 101

#15

Post by gedy »

tynorf wrote: post #13
gedy wrote: post #11

Earlier quoted context omitted.

And if not clear GraphQL is not "SQL on the web", so just because your DB schema changes, your GraphQL API doesn't have to change (basically like REST)

This is a very important point. I'd argue all these "publish your DB schema as a GraphQL endpoint" frameworks that seem to proliferate have done a lot of damage to GraphQL's reputation. Strongly coupling data to presentation seems like such an obvious anti pattern, yet tools doing just that seem to be very popular for some reason.

Agreed, the reason I really like GraphQL is you can map different parts of your schema "tree" to different backend systems, APIs, etc. This makes your API plane/BFF nicely decoupled from those details like DB tables, etc.

Re: System Design 101

#16

Post by wutwutwat »

artimaeis wrote: post #12
JSavageOne wrote: post #9

> Stack Overflow serves all the traffic with only 9 on-premise web servers, and it’s on monolith! It has its own servers and does not run on the cloud. This is contrary to all our popular beliefs these days. Love this part. I wonder how much of the complexity of microservices and various cloud services are actually adding value on a net basis vs. resume-driven development of some bored backend engineer.

I also love this anecdote -- but the SO engineering team that made that possible is _not_ your average LOB engineering team in my experience. Those guys were like C#/SQL technomancers. SO is a great example of just how much is possible with a .NET monolith, but very few teams are going to be capable of driving the machines that hard.

As I understand it, SO sites are mostly read traffic and they keep something like 2/3 of all of their data in cache at any given time. When your entire dataset is sitting in ram, you can handle insane amounts of traffic with few machines using any programming language, because most of the traffic is never even touching any code you wrote. Still impressive though!

Edit: I'd be curious how they hold up to a redis `flush all` or memcached `flush_all`. I wonder if they've ever game day'd such a scenario.

Re: System Design 101

#17

Post by triyambakam »

danielvaughn wrote: post #4

ByteByteGo is one of the best YouTube channels I've come across. Really well done content, all explained very clearly.

There is a dead comment in reply to the above that says that it is very shallow. Maybe it is too crudely worded, but I also have been left feeling disappointed with the ByteByteGo videos. They actually do feel more like bullet point lists. I don't mean to say it was not a lot of work to produce (especially the animations), but they are not deep dives. It could be a good resource for learning where to start, but it's not what I would call comprehensive or authoritative.

Re: System Design 101

#18

Post by 0xbadcafebee »

This is bizarre. A tiny bit of information about incredibly complex subjects. And this is "interview prep" ? Like for those "consultants" that try to bluster their way into a 6 figure gig?

Re: System Design 101

#19

Post by harshalizee »

artimaeis wrote: post #12
JSavageOne wrote: post #9

> Stack Overflow serves all the traffic with only 9 on-premise web servers, and it’s on monolith! It has its own servers and does not run on the cloud. This is contrary to all our popular beliefs these days. Love this part. I wonder how much of the complexity of microservices and various cloud services are actually adding value on a net basis vs. resume-driven development of some bored backend engineer.

I also love this anecdote -- but the SO engineering team that made that possible is _not_ your average LOB engineering team in my experience. Those guys were like C#/SQL technomancers. SO is a great example of just how much is possible with a .NET monolith, but very few teams are going to be capable of driving the machines that hard.

Stackoverflow is a much simpler mostly read only, easily cacheable site compared to a workflow heavy SaaS. They're not even remotely comparable.
Post reply on HN