3 ms·

> I recently worked on a project with 2 devs that took 3 months with a modern stack. The prototype in a standard MVC stack I'd made to demo to the client took 2

by bko 5y ago

> I recently worked on a project with 2 devs that took 3 months with a modern stack. The prototype in a standard MVC stack I'd made to demo to the client took 2 days. Can you expand on the modern stack and that standard stack? Is the "standard stack" you propose easier to work with now than it was 15 years ago? I guess the "standard stack" is just out of fashion? My preferred stack (aws serverless BE, nextjs front end or just aws app sync) keeps me in one language (typescript), with some stuff like GraphQL that you have to know. But the tooling around that helps keep my errors in compile time for the most part.

pc86 5y ago
Is being in one language really that much of a benefit? I've worked on several large production apps with node backends and I'd rather use almost any other backend language. And I take issue with saying you "have to know" GraphQL, that's a pretty specialized tool for pretty specific problems. Most things are not graph structures.
- jokethrowaway 5y ago
  Maybe I'm biased because I've been using node.js for 10+ years but node.js has a decent API. Simple, slightly opinionated. You just need to be careful of dependencies and what kool kids are doing these days. GraphQL is a complete nightmare. If you don't transpile anything and are conservative with your dependency you're golden.
mattmanser 5y ago
In that case it was a simple .Net core MVC stack, Vs an angular/Web API stack. For some inscrutable reason you can no longer do a simple 3 page form with a results page without making a SPA these days without getting someone claiming you're doing it wrong, it's nuts. Worse still, the angular app has all sorts of weird bugs. Auto-complete somehow screws with the validation of inputs, back button doesn't work properly as you lose all your data, URLs dont work, etc., etc., etc. There's also all sorts of craziness like the whole admin frontend is bundled with the client-facing part as the front-end developer didn't know how to split them up. Utterly preposterous. The problem is often that very skilled Devs give advice about incredibly specific stacks that only someone of their abnormally high-skill level can maintain. Throw in a few juniors or a few mediocre developers and the whole project turns into a complete and utter mess. And don't get me started on your stack that's mainly inappropriate for most applications. GraphQL. Talk about the next NoSQL fiasco in the making. Perhaps you missed the whole saga of everyone doing new development in NoSQL and then a few years later we had the flurry of blog posts about "Why are we losing data? I didn't realize ACID was so important..."
- native_samples 5y ago
  What is it you don't like about GraphQL? It seems to do what it was designed to do pretty well. I take it the issue is more with the pseudo-databases it's used as a front-end for?
  - mattmanser 5y ago
    Because it's now the 'right' way to do data. Even though it's not 90% of the time.
    - native_samples 5y ago
      Huh interesting. I'm not that plugged in to tech fashions, but was looking at GraphQL just the other day. My conclusion was that it didn't fit though, mostly because I wanted something that supported truly ad-hoc querying and mutation. With GraphQL it's really more like an RPC protocol, so you have to figure out your queries ahead of time, there was nothing like SQL's ability to do ad-hoc querying.

by bko 5y ago

pc86 5y ago

Is being in one language really that much of a benefit? I've worked on several large production apps with node backends and I'd rather use almost any other backend language. And I take issue with saying you "have to know" GraphQL, that's a pretty specialized tool for pretty specific problems. Most things are not graph structures.

jokethrowaway 5y ago
Maybe I'm biased because I've been using node.js for 10+ years but node.js has a decent API. Simple, slightly opinionated. You just need to be careful of dependencies and what kool kids are doing these days. GraphQL is a complete nightmare. If you don't transpile anything and are conservative with your dependency you're golden.

mattmanser 5y ago

In that case it was a simple .Net core MVC stack, Vs an angular/Web API stack. For some inscrutable reason you can no longer do a simple 3 page form with a results page without making a SPA these days without getting someone claiming you're doing it wrong, it's nuts. Worse still, the angular app has all sorts of weird bugs. Auto-complete somehow screws with the validation of inputs, back button doesn't work properly as you lose all your data, URLs dont work, etc., etc., etc. There's also all sorts of craziness like the whole admin frontend is bundled with the client-facing part as the front-end developer didn't know how to split them up. Utterly preposterous. The problem is often that very skilled Devs give advice about incredibly specific stacks that only someone of their abnormally high-skill level can maintain. Throw in a few juniors or a few mediocre developers and the whole project turns into a complete and utter mess. And don't get me started on your stack that's mainly inappropriate for most applications. GraphQL. Talk about the next NoSQL fiasco in the making. Perhaps you missed the whole saga of everyone doing new development in NoSQL and then a few years later we had the flurry of blog posts about "Why are we losing data? I didn't realize ACID was so important..."

native_samples 5y ago
What is it you don't like about GraphQL? It seems to do what it was designed to do pretty well. I take it the issue is more with the pseudo-databases it's used as a front-end for?
- mattmanser 5y ago
  Because it's now the 'right' way to do data. Even though it's not 90% of the time.
  - native_samples 5y ago
    Huh interesting. I'm not that plugged in to tech fashions, but was looking at GraphQL just the other day. My conclusion was that it didn't fit though, mostly because I wanted something that supported truly ad-hoc querying and mutation. With GraphQL it's really more like an RPC protocol, so you have to figure out your queries ahead of time, there was nothing like SQL's ability to do ad-hoc querying.