4 ms·

"If this feels “so 2015” to you, we did start building the app in early 2015 and went down the centralized RESTful API route." If the author considers that rou

by Confiks 11y ago

"If this feels “so 2015” to you, we did start building the app in early 2015 and went down the centralized RESTful API route." If the author considers that route to be "so 2016", what would the 2016 Newest Thing be?

treve 11y ago
Another symptom of how rotten the javascript ecosystem is. If I'm picking a technology stack for a business, I want to pick one that will last me 10 years.
- civilian 11y ago
  Good luck with your Java Web Start app!
  - lmm 11y ago
    Java Web Start is much nicer technically, and JavaFX UIs can be pretty nice. I honestly wish a lot of webapps were shipped that way.
  - deleted 11y ago
    [deleted]
  - warmwaffles 11y ago
    Nice retort. 10/10 would subscribe again.
  - spinlock 11y ago
    I wrote a Space Invaders applet in Java back in 1997. It was multi-threaded.
- BinaryIdiot 11y ago
  > If I'm picking a technology stack for a business, I want to pick one that will last me 10 years. What? Why wouldn't JavaScript last you 10 years? It's been around for over 20 already and is certainly not going anywhere... You don't have to upgrade to the newest fad every 6 months like you seem to imply. Most modern languages have crazy fads (just maybe not as fast as JavaScript does) and no one jumps on them every single time they're released, why would JavaScript be different?
sync 11y ago
2016 would be the rise of GraphQL or Falcor backends, where you write exactly what you are looking for on the frontend and send that request to the backend instead of REST endpoints. http://graphql.org/ http://graphql.org/ http://netflix.github.io/falcor/ http://netflix.github.io/falcor/
- steven777400 11y ago
  This is a pretty neat idea. It seems like it would be a lot harder to reason about than REST endpoints. I'm particularly thinking about validation (beyond the type-level, like when other data could conflict with a change) and security issues. What kinds of techniques are used to approach these concerns? Both examples seem to be completely JavaScript-centric on the server side, but it seems like there's no reason it shouldn't work with different backend languages.
  - andrewingram 11y ago
    GraphQL servers exist in multiple languages, many of them have more mature implementations than the reference (JavaScript)server. Sangria (the Scala implementation) is particularly impressive. And one of the Elixir implementations, Absinthe, is coming along very nicely. The main security concerns are: * Data leakage, the GraphQL schema reveals the overall capabilities of your system, which may not be desirable. It may still be necessary to split into private/public implementations. * Denial-of-service. Unless you take steps to mitigate it (there are a few approaches out there), it's often trivial to construct a query that could bring down a server. The two main approaches i've seen are white-listing queries at build time (so clients can't construct arbitrary queries), and adding cost/complexity heuristics to the server and rejecting any query over a certain threshold. * Authentication. Not actually a new concern, because the issue is basically the same as with REST. But you do need to get authentication and permissioning properly designed on the backend, it's not something you can really defer until a later date.

by Confiks 11y ago

treve 11y ago

Another symptom of how rotten the javascript ecosystem is. If I'm picking a technology stack for a business, I want to pick one that will last me 10 years.

civilian 11y ago
Good luck with your Java Web Start app!
- lmm 11y ago
  Java Web Start is much nicer technically, and JavaFX UIs can be pretty nice. I honestly wish a lot of webapps were shipped that way.
- deleted 11y ago
  [deleted]
- warmwaffles 11y ago
  Nice retort. 10/10 would subscribe again.
- spinlock 11y ago
  I wrote a Space Invaders applet in Java back in 1997. It was multi-threaded.
BinaryIdiot 11y ago
> If I'm picking a technology stack for a business, I want to pick one that will last me 10 years. What? Why wouldn't JavaScript last you 10 years? It's been around for over 20 already and is certainly not going anywhere... You don't have to upgrade to the newest fad every 6 months like you seem to imply. Most modern languages have crazy fads (just maybe not as fast as JavaScript does) and no one jumps on them every single time they're released, why would JavaScript be different?

sync 11y ago

2016 would be the rise of GraphQL or Falcor backends, where you write exactly what you are looking for on the frontend and send that request to the backend instead of REST endpoints. http://graphql.org/ http://graphql.org/ http://netflix.github.io/falcor/ http://netflix.github.io/falcor/

steven777400 11y ago
This is a pretty neat idea. It seems like it would be a lot harder to reason about than REST endpoints. I'm particularly thinking about validation (beyond the type-level, like when other data could conflict with a change) and security issues. What kinds of techniques are used to approach these concerns? Both examples seem to be completely JavaScript-centric on the server side, but it seems like there's no reason it shouldn't work with different backend languages.
- andrewingram 11y ago
  GraphQL servers exist in multiple languages, many of them have more mature implementations than the reference (JavaScript)server. Sangria (the Scala implementation) is particularly impressive. And one of the Elixir implementations, Absinthe, is coming along very nicely. The main security concerns are: * Data leakage, the GraphQL schema reveals the overall capabilities of your system, which may not be desirable. It may still be necessary to split into private/public implementations. * Denial-of-service. Unless you take steps to mitigate it (there are a few approaches out there), it's often trivial to construct a query that could bring down a server. The two main approaches i've seen are white-listing queries at build time (so clients can't construct arbitrary queries), and adding cost/complexity heuristics to the server and rejecting any query over a certain threshold. * Authentication. Not actually a new concern, because the issue is basically the same as with REST. But you do need to get authentication and permissioning properly designed on the backend, it's not something you can really defer until a later date.