5 ms·

I agree this is super exciting but those things come with a significant operational overhead that your traditional full stacks don't have. one vm => many lambd

by ljm 7y ago

I agree this is super exciting but those things come with a significant operational overhead that your traditional full stacks don't have. one vm => many lambdas/microservices react => server side rendering and state hydration, throw redux in there too prisma => you can't beat the DB with code. Learn SQL and remove the middleman. Jest => fair enough I guess, but I wouldn't use rspec when Ruby had minitest out of the box Caching/Static site => wut? ... wut? there's much more to caching than HTML. routes.js => probably great on the server, not so much on the browser. And the best for last... graphql => not a replacement for REST. You can do more with less by just making your client do the work or going with backend-for-frontends. If you don't understand your network then graphql is an easy vector for DOS (speaking from experience). Meanwhile I can spin up Laravel, Rails, Spring or Django up and get a solid application running in a fraction of the time while in JS land, client server arch is a seemingly unsolved problem. I sound bitter but I'm more incredulous. I don't actually enjoy writing for the browser any more, there are too many divergent trends.

deleted 7y ago
[deleted]
onion2k 7y ago
Meanwhile I can spin up Laravel, Rails, Spring or Django up and get a solid application running in a fraction of the time while in JS land, client server arch is a seemingly unsolved problem. This might be a slightly controversial opinion, but I don't think the time it takes to get an application running with a framework is a relevant metric. Being able to get an application up and running fast is only a useful benefit when you're first starting out and trying things. If you're choosing a tech stack and you're going to be working on something for months or years, the fact that you can see something on a screen after an hour or after 3 days is completely insignificant compared to how good it is to work with in the long term. Choosing a technology because you can start working on a new application quickly is the wrong way of thinking about your tech stack.
- hombre_fatal 7y ago
  I think your post summarizes a major reason why so many people ended up using small frameworks and appreciating glue code after using Rails/Django. My noob a-ha example is `rails generate devise:install` where I first thought, wow, what a time saver. Eventually I learned lessons like, perhaps authentication is too important to be hiding from your source code. In fact, maybe almost everything is.
  - mikeappell 7y ago
    I think it's important to learn and understand, absolutely. But a default installation/configuration which both works correctly and is easy to set up is pretty damn valuable.
    - onion2k 7y ago
      But a default installation/configuration which both works correctly and is easy to set up is pretty damn valuable. It can be, especially when you're learning or putting together lots of small projects, but my point is that people over-emphasis the benefit of that feature on a long term project. It might be fine that a framework takes a lot of time and effort to set up before you see any results, and it could actually be a good thing if that initial time means other things about the framework are better. All other things being equal it'd great to be able to spin up quickly, but things are never really equal between frameworks. So, to me, choosing a tech stack because it's quick to initialise a new project feels like you're optimizing for the wrong thing, and potentially you're making a less optimal choice because of that.
      - tekknik 7y ago
        There are a couple of reasons you want a “quickly spun up” framework. First it shows the API is thought through / not complicated. If it takes hours for you to add a basic route the framework was overengineered. The second is hiring. Rarely will you find devs with all the experience you require, so you’ll have to train. Making things overly complicated increases the cost of your devs, increases training time, and generally just slows you down. So I completely and wholeheartedly disagree. Frameworks should be as simple as they can be.
triangleman 7y ago
Favorited your post. Most projects are small and limited in scope. So I agree most of these extra layers are overkill most of the time.
joshspankit 7y ago
> If you don't understand your network then graphql is an easy vector for DOS (speaking from experience). When GraphQL came out I was quite honestly shocked that this didn’t get more attention. It’s essentially trivial to not notice that a query could cause the server to loop heavily. User > Friends > Friends = easily 10000 results, and that’s the simplest top-of-the-head example I can think of. When an object has even 3 or 4 possible relationships, there are exponentially more attack vectors. And on a minor note: the fact that objects are returned inline makes a query for duplicates that much larger in KB.
- highmastdon 7y ago
  When you would’ve worked with GraphQL, which I assume you didn’t given your comment, you’d know that the design stage of a schema is one of the most important ones. In this case getting friends of friends, one can easily enforce pagination on the results and force a maximum of x friends. Furthermore, it’s not like REST or any other tech is immune to this way of DOSsing the server, however with REST this is just pushed to the client to perform 1+n+n*n queries. So either way, you’ll have to fix that problem. Now, what does GraphQL _actually_ solve? For one, it gives proper documentation and ability to know what the client(s) are consuming. In turn allows client devs to develop their side much faster and independently from the backend. Where we used to have a lot of back and forth about the design of the api we can now model our interface according to the Business model and not have to accommodate for the limitations of a flatten structure. There are more advantages to GraphQL but it goes too far to elaborate in this comment

by ljm 7y ago

deleted 7y ago

[deleted]

onion2k 7y ago

Meanwhile I can spin up Laravel, Rails, Spring or Django up and get a solid application running in a fraction of the time while in JS land, client server arch is a seemingly unsolved problem. This might be a slightly controversial opinion, but I don't think the time it takes to get an application running with a framework is a relevant metric. Being able to get an application up and running fast is only a useful benefit when you're first starting out and trying things. If you're choosing a tech stack and you're going to be working on something for months or years, the fact that you can see something on a screen after an hour or after 3 days is completely insignificant compared to how good it is to work with in the long term. Choosing a technology because you can start working on a new application quickly is the wrong way of thinking about your tech stack.

hombre_fatal 7y ago
I think your post summarizes a major reason why so many people ended up using small frameworks and appreciating glue code after using Rails/Django. My noob a-ha example is `rails generate devise:install` where I first thought, wow, what a time saver. Eventually I learned lessons like, perhaps authentication is too important to be hiding from your source code. In fact, maybe almost everything is.
- mikeappell 7y ago
  I think it's important to learn and understand, absolutely. But a default installation/configuration which both works correctly and is easy to set up is pretty damn valuable.
  - onion2k 7y ago
    But a default installation/configuration which both works correctly and is easy to set up is pretty damn valuable. It can be, especially when you're learning or putting together lots of small projects, but my point is that people over-emphasis the benefit of that feature on a long term project. It might be fine that a framework takes a lot of time and effort to set up before you see any results, and it could actually be a good thing if that initial time means other things about the framework are better. All other things being equal it'd great to be able to spin up quickly, but things are never really equal between frameworks. So, to me, choosing a tech stack because it's quick to initialise a new project feels like you're optimizing for the wrong thing, and potentially you're making a less optimal choice because of that.
    - tekknik 7y ago
      There are a couple of reasons you want a “quickly spun up” framework. First it shows the API is thought through / not complicated. If it takes hours for you to add a basic route the framework was overengineered. The second is hiring. Rarely will you find devs with all the experience you require, so you’ll have to train. Making things overly complicated increases the cost of your devs, increases training time, and generally just slows you down. So I completely and wholeheartedly disagree. Frameworks should be as simple as they can be.

triangleman 7y ago

Favorited your post. Most projects are small and limited in scope. So I agree most of these extra layers are overkill most of the time.

joshspankit 7y ago

> If you don't understand your network then graphql is an easy vector for DOS (speaking from experience). When GraphQL came out I was quite honestly shocked that this didn’t get more attention. It’s essentially trivial to not notice that a query could cause the server to loop heavily. User > Friends > Friends = easily 10000 results, and that’s the simplest top-of-the-head example I can think of. When an object has even 3 or 4 possible relationships, there are exponentially more attack vectors. And on a minor note: the fact that objects are returned inline makes a query for duplicates that much larger in KB.

highmastdon 7y ago
When you would’ve worked with GraphQL, which I assume you didn’t given your comment, you’d know that the design stage of a schema is one of the most important ones. In this case getting friends of friends, one can easily enforce pagination on the results and force a maximum of x friends. Furthermore, it’s not like REST or any other tech is immune to this way of DOSsing the server, however with REST this is just pushed to the client to perform 1+n+n*n queries. So either way, you’ll have to fix that problem. Now, what does GraphQL _actually_ solve? For one, it gives proper documentation and ability to know what the client(s) are consuming. In turn allows client devs to develop their side much faster and independently from the backend. Where we used to have a lot of back and forth about the design of the api we can now model our interface according to the Business model and not have to accommodate for the limitations of a flatten structure. There are more advantages to GraphQL but it goes too far to elaborate in this comment