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

31–40 of 45 posts

Re: System Design 101

#31

Post by gedy »

melvinmelih wrote: post #22
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…

To be fair, you don’t have this problem with REST either (any new properties can be safely ignored). Where it breaks down however (and this applies more to GraphQL because of its insistence of not being versioned) is when you want to deprecate some fields that a lot of clients depend on.

I agree with you, though I have worked with a lot of folks who insist new fields are worthy of a new version. I mostly use Javascript which is really forgiving, but sometimes people have these C++/etc client libraries that blow up with unexpected data apparently.

Re: System Design 101

#33

Post by Groxx »

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

If you want to make a breaking change, yeah - you need to version it somehow. No question. It's fairly flexible in how much you can change without it being breaking, but it's not magic.

Beyond that it's arguably "versionless" because it does nothing to address the problem. Which is essentially fine, and is what most protocols do: you make a completely new API or change the endpoint (e.g. http path) to gradually make breaking changes (expose both, migrate callers whenever), because something like that is basically always an option.

Re: System Design 101

#34

Post by danielvaughn »

triyambakam wrote: post #17
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…

What I find valuable is the distillation of a complex topic I’m unfamiliar with, to the point where I can easily understand what it is at a high level in just a few minutes.

This is easier said than done; there are plenty of technologies that have horrendous intro documentation that dives into all sorts of overly complicated and confusing shit. It’s really hard to stay on topic and present only what’s relevant for someone who’s never heard of the technology before.

Not everything needs to be a comprehensive deep dive.

Re: System Design 101

#35

Post by testermelon »

pylua wrote: post #27

This is a great overview and explains the subjects briefly but well. I definitely was surprised by seeing a whole section dedicated to payments.

I was also intrigued by that section. It's surely interesting but looks more like an important special case than a technical subject. Not complaining tho.

Re: System Design 101

#36

Post by kmiller96 »

xwowsersx wrote: post #30

ByteByteGo seems to almost be a content generation concept for a niche market. And the thing is, aspiring developers do, apparently eat this stuff up. Thing is though, you really don't truly assimilate these concepts from a simple diagram, not just because they are gross simplifications or crude approximations — they are — but because you need to "feel" what these systems are like in a real world scenario or at least…

Disagree. ByteByteGo is great for a 50,000ft view of a topic. It's useful to watch/listen/read ByteByteGo for a first pass at a topic and learn the correct terminology in that domain.

It's also useful for scratching the itch of "huh, how does that work?" without having to allocate 100 hours of "breaking your teeth" learning the concept.

IMO any knowledge is good knowledge, even if it's a simplification of the topic (and the reader is aware it's a simplification).

Re: System Design 101

#37

Post by harshalizee »

aprdm wrote: post #24
harshalizee wrote: post #19

Earlier quoted context omitted.

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

I think you're underestimating how much write happens in SO, and overestimating how much writes happens on 99% of the SaaS that have very few paying customers..

Currently work for a very large household name SaaS, previously on Salesforce. I'm willing to bet good money that SO does not remotely come close to the amount of writes in either of these systems.

Re: System Design 101

#38

Post by koonsolo »

xwowsersx wrote: post #30

ByteByteGo seems to almost be a content generation concept for a niche market. And the thing is, aspiring developers do, apparently eat this stuff up. Thing is though, you really don't truly assimilate these concepts from a simple diagram, not just because they are gross simplifications or crude approximations — they are — but because you need to "feel" what these systems are like in a real world scenario or at least…

Master in CS with 20+ years of professional experience chiming in here

> because you need to "feel" what these systems are like

I've done a lot of job hopping and seen a lot of technologies and companies. There is no way will you ever really experience even 10% of the information found on that page.

In my opinion, it seems like a great resource, and bookmarked it to go through it when I have some time.

Telling young devs to "gain experience" is pretty useless information. Learning theory is a large part of our job.

Re: System Design 101

#39

Post by tonyhart7 »

xwowsersx wrote: post #30

ByteByteGo seems to almost be a content generation concept for a niche market. And the thing is, aspiring developers do, apparently eat this stuff up. Thing is though, you really don't truly assimilate these concepts from a simple diagram, not just because they are gross simplifications or crude approximations — they are — but because you need to "feel" what these systems are like in a real world scenario or at least…

still better than nothing, because in YouTube there are really not a lot of content like this, most people that create content like this are faang employee and you still missing a lot of nuance

sure You cant really 100% translate it to your requirement but it give mind map to a lot of people to start

Re: System Design 101

#40

Post by namaria »

xwowsersx wrote: post #30

ByteByteGo seems to almost be a content generation concept for a niche market. And the thing is, aspiring developers do, apparently eat this stuff up. Thing is though, you really don't truly assimilate these concepts from a simple diagram, not just because they are gross simplifications or crude approximations — they are — but because you need to "feel" what these systems are like in a real world scenario or at least…

Maps won't teach you an intuition for tactics. Without maps tho, the best tactician is severely handicapped.
Post reply on HN