Comments by "Vincent Jenks" (@VincentJenks) on "ByteByteGo" channel.

  1. Kafka is one of my favorite pieces of technology. I’ve successfully used it in several projects as a streaming queue and event bus, in a microservices setting, and it’s a joy to work with. Since it tracks what has been consumed with an offset, it greatly simplifies distributed, high-volume writes, and gives you great confidence in data consistency (eventually) ;) Highly recommend!
    19
  2. To me, BBG is brilliant in this respect. There’s so much for us to know, learn, and keep up with. These are great mental “bookmarks” to point you towards pinpoint searches, to find the depth you need elsewhere. I get what you’re saying though. A great addition in this channel, would be links to in-depth, or just follow-up videos with more depth on each topic, alone. Then you could go down each rabbit hole from the high level video, as needed.
    14
  3. Ha! Ew.
    5
  4. In a smooth CI/CD setup, I find feature toggling via feature flags, the safest and easiest way to go. The smaller the feature, the better. He’s right though - if you’re not diligent about deleting old flags, code, tests, etc, your tech debt will pile up. Something teams generally need to work hard to prevent, regardless.
    4
  5. That's my biggest takeaway. When I've been in consulting, comprehensive automated tests are a tough sell for a lot of clients. It's the first thing to get cut. It's just tough to tell a client that yes, we may add 20% (just throwing a hypothetical, SWAG number out there) - but your code quality will be much better and we'll spend less time putting fires out. Add to that, writing and maintaining tests can be a drag. Having a virtual assistant to tackle that is like having a junior dev just hanging around, picking up the slack where you need and want it most.
    3
  6. Not quite. There are many advantages to Kafka, which you can find through searching for comparisons.
    3
  7. Being serious, this is the proper answer to any over-engineering effort. 👍
    2
  8. It’s not a tutorial, it’s a quick familiarization. Use it to direct your own learning.
    2
  9. Ah, The Great Debate. I’ve hunkered around many a whiteboard and heard endless iterations of passionate arguments for all approaches. Regardless of what you personally prefer, it all comes down to the project, your team, and what works for everyone. There’s no hard and fast rule and all approaches have their merit.
    2
  10. Yeah, gotta get the smallest bits possible, into production s as quickly as possible, and clean up on your next pass.
    2
  11. There’s also the concept of a distributed monolith, where many distributed services utilize a single database. It can work in your favor in some scenarios, or be a complete anti-pattern if not implemented well. Similar to a modular monolith, always build out with a clean separation of concerns, so you can more easily distribute the data, later on.
    2
  12. Yeah, I’m gonna go looking for overly-simplistic examples of these in action, in a language I can follow…like JavaScript. I need to see implementations to really internalize the concept.
    2
  13. Ahh, the Hail Mary strategy. 😉
    2
  14. We successfully implemented Redis (Redis Stack/RedisJSON/RediSearch) for simple, fast full-text searchable cache, in a microservices setting. It was a joy to work with. It has its quirks, but all systems do. Looking forward to utilizing Redis Cloud for the same purpose in a new project!
    1
  15. Great reminder that engineers are gonna over-engineer. Even senior professionals are often too quick too chase the shiny new hotness, and do what’s trendy. Monoliths are fine for far more than they get credit for, and usually a good way to start a project, at the very least. Keep design and tooling simple, and minimalistic, with the idea that you might break the monolith up, later on. We’re drowning in trends, tooling, configuration, overly-complex architecture, and general over-engineering. Very few of us are building anything that requires all this stuff. We’re not all Google and Amazon!
    1
  16. An often go-to "but...but...but!" for these tools, is the legal angle. Yes, companies are hesitant to use AI tools, and rightfully so. You're sharing IP and potentially using someone else's IP. It's the wild west in AI right now and it'll take some time for that to settle. There are lots of amazing tools and extensions being built, some of which take this into account, allowing offline/on-prem or isolated models for your teams. This market will be huge, the potential is endless...and we should definitely embrace it!
    1
  17.  @jackwinnfield  It's not exactly meant to be used "sparingly". You either utilize it or you don't bother w/ the effort. As the video mentions, it's an effective data bus for microservices. If you're not decoupling your microservices properly, you're setting yourself up for a lot of pain as development scales out, as you'll have a lot of "spaghetti services" that can't be deployed independently, cause cascading failures when one link in the chain goes down, and generally loses the ability to be fault-tolerant. If you're making direct calls between your services and it's holding up well, you likely over-engineered to begin with, and don't truly need microservices architecture to begin with.
    1
  18. Call me old school, but I’m struggling to see the advantages of a monorepo. Less tooling and flexibility is a good thing, and microrepos scale better, IMO. For most projects, shared code, like utility modules, can simply be referenced via npm, or whatever package manager you’re using. Regardless of approach, good documentation, management, and communication cannot be optional. I feel like we devs are drowning in configuration and tooling these days, and it’s wise to avoid any complexity that you can.
    1