3 ms·
Yeah, you can't jump on every hype. I started in web dev almost 20 years ago (did some Visual C++ before that). First job was everything XML. We had our open
by mcv 3y ago
Yeah, you can't jump on every hype.
I started in web dev almost 20 years ago (did some Visual C++ before that).
First job was everything XML. We had our open source CMS that stored all documents as XML and used XSLT to transform it into the HTML we needed. Was pretty cool, but there's always something that didn't fit that paradigm. Some coworkers went a bit overboard and used XSLT to generate the XSLT to create the HTML. But it all works as long as you cache aggressively.
Second was Ruby on Rails with JQuery. And eye-opener for me. Very cool to work with. Third job was similar, but using Groovy instead of Ruby. After that, I ended up in SPA-land: first Angular, then Vue, now React. Backends in either Java or Node.js.
I'm still doing that, only now everything needs to be in Docker and Kubernetes.
I still don't know why I should ever need microservices. Our GraphQL. We actually considered GraphQL for previous project, and decided not to because it looked way too complicated. It sounds like it might fit with using a Graph DB (I'm a big fan of neo4j), but it doesn't. At my current project, they made that decision before I joined, and they've since realised that they don't need GraphQL after all, but it's in there now, so they just work around it.
Some of the hypes worked very well for me (XML, jQuery, Ajax, SPA), others seem to work well for others but not me (docker, kubernetes), and some I really don't see the point in (microservices, GraphQL), but I assume there are use cases where they shine.
But don't blindly adopt everything. First check if it actually fills a need you have. And how it will fill that need.
- Blaiz0r 3y agoMicroservices are more an organisational thing than a recommended pattern, when a project grows and wants to hire more staff to increase its bandwidth then microservices are a great way to support that, the additional benefit is that they work great in a CI/CD setup so you can release seamlessly. GraphQL from what I can tell supports web developers rewriting their APIs when they need to instead of waiting on back-end teams to support them.
- mcv 3y agoMost of my projects have just a single team in charge of a single code base, so there seems to be no need for microservices at all, and yet some people keep bringing up that we should really look into microservices. My impression is that GraphQL is great if you're building an api that's going to be used by lots of different teams with different needs and the api developer doesn't know what they are. Again, with a single team doing everything, there's no need for it at all. But we're using it anyway. Also, they keep talking about a Single SPA Application, and I can't tell if that's just a redundant way to say SPA, or if it's really something new, or if they're just messing with me.
- noisy_boy 3y ago> My impression is that GraphQL is great if you're building an api that's going to be used by lots of different teams with different needs and the api developer doesn't know what they are. This has been my experience as well. It provides flexibility to the consumers of the API to structure things how they want and fetch only what they need. E.g. if you add a new field, there isn't any impact on existing users to make any changes since they are not specifying it in their current request anyway. To certain extent, that also helps with things being somewhat future proof because even if you knew what the users want today, you can't predict what they will want tomorrow. Having done a bunch of REST and GraphQL APIs, the only thing I would say for GraphQL is to avoid re-inventing the wheel and use a stable third-party library to do as much heavy lifting as possible so that you can focus on the logic side of things.
- throwaway2037 3y agoDid you ever try the Microsoft Visual Studio XSLT debugger from DotNet? The first time I tried it from C# was mind-blowing. Suddenly, it became possible to manage complex XSLT scripts!
- mcv 3y agoNever used it. We used Eclipse.
- pookha 3y agoSomewhere out there in the known universe theirs cobalt developers that have avoided CSS, SOAP, Oracle J2EE, reactivesvelteinangularvue's, javascript servers, shitty facebook ideas, nine thousand line YML files, micro bullshit (microsoft, microservers), "containers" (and solaris zones before that) AND there's nobody pining to replace them with LLM models.
- spiralx 3y ago> First job was everything XML. We had our open source CMS that stored all documents as XML and used XSLT to transform it into the HTML we needed. Docato/XHive? Been there as well.