6 ms·

He nails the problem: API bloat due to chaotic front end needs, but there is a much, much simpler solution: move the UI/DOM building back to the server side. T

He nails the problem: API bloat due to chaotic front end needs, but there is a much, much simpler solution: move the UI/DOM building back to the server side. This gives you a nice, secure environment to build your UI in with the full power of the query language your datastore provides, and it doesn't require any particularly complex architecture or discipline to maintain. And, of course, I would be remiss if I didn't mention my baby, http://intercoolerjs.org/ http://intercoolerjs.org/, as a tool to help you do it.

bicknergseng 11y ago
>>with the full power of the query language your datastore provides If your datastore exists in your server side rendering application. I would say that "chaotic front end needs" exist in applications that require data from multiple data sources: many different APIs and datastores that need to be independently queried. If that is true, is there really a big difference between having a server side or client side view model that wraps that complexity?
- carsongross 11y ago
  I don't know if I completely understand what you are saying, my comment doesn't rely on multiple data stores. I'm talking about a web application with a single (say, SQL-based) datastore. I am saying that without the full power of that data store on the client side (that is, an optimizable query language, update and insert statements) you will always be thrashing your API around to deal with chaotic UI needs. If you do expose the full datastore functionality on the client side (which GraphQL is a move towards) then you have a different problem: you are exposing your datastore in a fundamentally insecure environment. So you are screwed either way.
  - hnal943 11y ago
    Yes in that instance you are correct that server-side rendering is easier. It doesn't make it any easier to build a mash-up application in which you are relying on multiple sources of data that you do not control.
  - bicknergseng 11y ago
    That's exactly what I'm saying. If you have a web application with only one data source built in, then GraphQL is not for you. In fact, that whole post wasn't for you. You probably should stick with a monolith until you can't. If you have a large, complex web application that integrates data from many different sources, then an API aggregator or view model is essential. GraphQL is not an attempt to move the datastore clientside.
reitanqild 11y ago
Yes, yes, yes. Javascript is useful for web apps. When a blog has time to display a load animation in 2016 someone, somewhere should have their client side JS privileges withdrawn ;-)
- Touche 11y ago
  > When a blog has time to display a load animation in 2016 someone, Using JavaScript client-side doesn't necessitate this. You could inline the data into the page and you would not be able to tell if it was client-side rendered.
  - reitanqild 11y ago
    Only when one of the scripts is blocked and I get placeholders sprinkled from title and down, main content was readable though IIRC. Happened to me on a MSFT site recently :-]
  - Cthulhu_ 11y ago
    Which is exactly why sites like blogspot make me do a WTF.
aikah 11y ago
> move the UI/DOM building back to the server side > Intercooler responses are HTML fragments. I'd argue that, just like described at the end of the article, it's just shifting the burden on the server. It's a trade off. IMHO React gets a lot of things right : - DOM diffing - Components - 1 model as a unique source of truth And when one thinks about it, IT IS MVC in its purest form, since there is only one model, one big view(the tree of components) and one controller(using event delegation). What React nailed is an efficient way to rerender the view.
- carsongross 11y ago
  React doesn't solve the fundamental problem of either API churn or security issues in browser client code. It may be elegant (I don't think it is) but it is orthogonal to the issue at hand. Server side MVC and HTML as a transport has a huge number of advantages, not the least that HATEOS "Just Works" without anyone having to think about it, but even if it didn't, I would think that the API churn/security tradeoff would give the development community pause about heavy client-side logic.
  - Silhouette 11y ago
    React doesn't solve the fundamental problem of either API churn or security issues in browser client code. I'm not sure what problems you are referring to here, since you don't seem to have defined them anywhere. They sound like they'd be well outside the scope of a library like React, though, which is essentially just a declarative UI rendering tool.
  - xg15 11y ago
    And rendering on the server solves API churn by... having no API at all? Then what do you do once you'd like to add non-browser clients like native apps or an actual API for third parties? Additionally, I don't see how rendering on the server frees you from thinking about security or setting (and enforcing) proper permissions. All you gain is that the problem is less visible and your entities are obfuscated in chunks of redundant HTML. In fact, now you may open up new security holes like XSS that you can avoid easily with proper client-side widgets.
jaegerpicker 11y ago
Client side logic and rendering has a HUGE number of advantages when done correctly. Most sites don't but it is possible. API Churn is simple to solve (graphql, mvvm pattern, or as a proxy api wrapper can all be used quite effectively to solve it) and if you build an universal (meaning progressive enhancement enabled) application you can pick up the advantages of a SPA without losing the very limited advantages that a true server rendered app gives you.
- carsongross 11y ago
  Heh. If you want to realize those advantages, you will end up introducing a "simple" solution like GraphQL. In an insecure environment. Read, man. Don't just react.
  - peterhunt 11y ago
    I think you misunderstand what GraphQL is. It's not direct access to the database. It is a view model abstraction on top of your database which includes permissions checks for each node and edge, so in many ways it's actually more secure than the alternative of securing each endpoint adhoc.
    - carsongross 11y ago
      I understand what GraphQL is: it's a step towards full datastore access on the client side. It exposes some security issues (what if you don't want a user to have access to some data and miss a security constraint, as you will, and they modify your GraphQL language to see it?) but it isn't the full security clusterfuck. Yet. Again, the tradeoff is touching your API (or security model) every time UX needs change, or exposing more and more security issues client side.
      - peterhunt 11y ago
        That's absolutely not true. For each node type and edge type in the graph, you provide a required canSee() function which controls its visibility. This granular access control leads to a more secure system than the alternative, which is doing access control at the endpoint level and then hoping that the endpoint doesn't fetch data it isn't supposed to.
esaym 11y ago
intercoolerjs just seems to be an inlined version of jquery .load()? (Which I use a lot) Or am I missing something?
- carsongross 11y ago
  At some level, no. But, at another level, yes: REST-ful dependencies, progress indicators, CSS transitions, history support, custom HTTP response headers for meta-actions and so on. You can check out the docs here: http://intercoolerjs.org/docs.html http://intercoolerjs.org/docs.html
dclowd9901 11y ago
I really like a middle-tier functional API (ideally, Node) that can make requests as needed to a dumb backend that is really just a DB endpoint and then runs functional computations (map/reduce) to marshall the data as configured for a view to a client. You don't have to hassle backend for expensive API updates on a heavyweight language that makes exposing an endpoint a pain in the ass (sorry, Java), and you get exactly the data you need in exactly the way you need.
drewrv 11y ago
You don't even have to go that far. Just let the 'front end' developer write json api's.
marcus_holmes 11y ago
I remember the days of 3-tier client-server computing. This exact problem. How much knowledge does your middle tier need to have about your presentation tier? Do you shape your database schema to your business logic, or provide stored procs that can translate your "pure" schema into the structures required by the middle tier? All of those questions. The key one we're asking here is "how much business logic do you need in your presentation layer?" Too little then you're round-tripping for simple form validation and your UI is unresponsive. Too much and your UI becomes tightly coupled to your business rules (and you start exposing too much attack surface). Modern SPA web apps are making a deliberate trade-off, moving more logic into the client so the app is more responsive. The problem of making the API schema "pure" or tightly coupling it to the UI is the same old "how much business logic sits in the database" debate. Ideally, of course, all endpoints would relate directly to application entities so that changes to the UI don't change the API. But this increases the number of round-trips and reduces responsiveness. Same for rendering HTML on the server - increased round-trips and reduced responsiveness. The answer depends on the trade-offs that the project needs. Is the API complex and used by lots of clients? Keep it pure. Is the API small and/or used by only one client? Tailor it to the client? Is responsiveness paramount? Put as much as possible client-side. Is security paramount? Put as little as possible client-side. IMHO there is no right answer that works across all situations, just as there wasn't back in the 3-tier day.
- carsongross 11y ago
  Yeah, but I see them making a lot of the same mistakes that were made back then and I can help but notice that, in the context of web applications, you have an opportunity to render the UI in a trusted environment where the code being executed is guaranteed to be written by a non-hostile by just rendering/executing server-side. If you throw HATEOS-without-thinking-or-arguing-about-it on top of that, it seems like a no brainer to bias toward that approach. I used to think that web apps were dumb and thick apps were obviously better in most cases, but I've changed my tune in the last few years as I've come to understand HATEOS and disentangle it from the JSON API quagmire it got into: http://intercoolerjs.org/2016/01/18/rescuing-rest.html http://intercoolerjs.org/2016/01/18/rescuing-rest.html

bicknergseng 11y ago

>>with the full power of the query language your datastore provides If your datastore exists in your server side rendering application. I would say that "chaotic front end needs" exist in applications that require data from multiple data sources: many different APIs and datastores that need to be independently queried. If that is true, is there really a big difference between having a server side or client side view model that wraps that complexity?

carsongross 11y ago
I don't know if I completely understand what you are saying, my comment doesn't rely on multiple data stores. I'm talking about a web application with a single (say, SQL-based) datastore. I am saying that without the full power of that data store on the client side (that is, an optimizable query language, update and insert statements) you will always be thrashing your API around to deal with chaotic UI needs. If you do expose the full datastore functionality on the client side (which GraphQL is a move towards) then you have a different problem: you are exposing your datastore in a fundamentally insecure environment. So you are screwed either way.
- hnal943 11y ago
  Yes in that instance you are correct that server-side rendering is easier. It doesn't make it any easier to build a mash-up application in which you are relying on multiple sources of data that you do not control.
- bicknergseng 11y ago
  That's exactly what I'm saying. If you have a web application with only one data source built in, then GraphQL is not for you. In fact, that whole post wasn't for you. You probably should stick with a monolith until you can't. If you have a large, complex web application that integrates data from many different sources, then an API aggregator or view model is essential. GraphQL is not an attempt to move the datastore clientside.

reitanqild 11y ago

Yes, yes, yes. Javascript is useful for web apps. When a blog has time to display a load animation in 2016 someone, somewhere should have their client side JS privileges withdrawn ;-)

Touche 11y ago
> When a blog has time to display a load animation in 2016 someone, Using JavaScript client-side doesn't necessitate this. You could inline the data into the page and you would not be able to tell if it was client-side rendered.
- reitanqild 11y ago
  Only when one of the scripts is blocked and I get placeholders sprinkled from title and down, main content was readable though IIRC. Happened to me on a MSFT site recently :-]
- Cthulhu_ 11y ago
  Which is exactly why sites like blogspot make me do a WTF.

aikah 11y ago

> move the UI/DOM building back to the server side > Intercooler responses are HTML fragments. I'd argue that, just like described at the end of the article, it's just shifting the burden on the server. It's a trade off. IMHO React gets a lot of things right : - DOM diffing - Components - 1 model as a unique source of truth And when one thinks about it, IT IS MVC in its purest form, since there is only one model, one big view(the tree of components) and one controller(using event delegation). What React nailed is an efficient way to rerender the view.

carsongross 11y ago
React doesn't solve the fundamental problem of either API churn or security issues in browser client code. It may be elegant (I don't think it is) but it is orthogonal to the issue at hand. Server side MVC and HTML as a transport has a huge number of advantages, not the least that HATEOS "Just Works" without anyone having to think about it, but even if it didn't, I would think that the API churn/security tradeoff would give the development community pause about heavy client-side logic.
- Silhouette 11y ago
  React doesn't solve the fundamental problem of either API churn or security issues in browser client code. I'm not sure what problems you are referring to here, since you don't seem to have defined them anywhere. They sound like they'd be well outside the scope of a library like React, though, which is essentially just a declarative UI rendering tool.
- xg15 11y ago
  And rendering on the server solves API churn by... having no API at all? Then what do you do once you'd like to add non-browser clients like native apps or an actual API for third parties? Additionally, I don't see how rendering on the server frees you from thinking about security or setting (and enforcing) proper permissions. All you gain is that the problem is less visible and your entities are obfuscated in chunks of redundant HTML. In fact, now you may open up new security holes like XSS that you can avoid easily with proper client-side widgets.

jaegerpicker 11y ago

Client side logic and rendering has a HUGE number of advantages when done correctly. Most sites don't but it is possible. API Churn is simple to solve (graphql, mvvm pattern, or as a proxy api wrapper can all be used quite effectively to solve it) and if you build an universal (meaning progressive enhancement enabled) application you can pick up the advantages of a SPA without losing the very limited advantages that a true server rendered app gives you.

carsongross 11y ago
Heh. If you want to realize those advantages, you will end up introducing a "simple" solution like GraphQL. In an insecure environment. Read, man. Don't just react.
- peterhunt 11y ago
  I think you misunderstand what GraphQL is. It's not direct access to the database. It is a view model abstraction on top of your database which includes permissions checks for each node and edge, so in many ways it's actually more secure than the alternative of securing each endpoint adhoc.
  - carsongross 11y ago
    I understand what GraphQL is: it's a step towards full datastore access on the client side. It exposes some security issues (what if you don't want a user to have access to some data and miss a security constraint, as you will, and they modify your GraphQL language to see it?) but it isn't the full security clusterfuck. Yet. Again, the tradeoff is touching your API (or security model) every time UX needs change, or exposing more and more security issues client side.
    - peterhunt 11y ago
      That's absolutely not true. For each node type and edge type in the graph, you provide a required canSee() function which controls its visibility. This granular access control leads to a more secure system than the alternative, which is doing access control at the endpoint level and then hoping that the endpoint doesn't fetch data it isn't supposed to.

esaym 11y ago

intercoolerjs just seems to be an inlined version of jquery .load()? (Which I use a lot) Or am I missing something?

carsongross 11y ago
At some level, no. But, at another level, yes: REST-ful dependencies, progress indicators, CSS transitions, history support, custom HTTP response headers for meta-actions and so on. You can check out the docs here: http://intercoolerjs.org/docs.html http://intercoolerjs.org/docs.html

dclowd9901 11y ago

I really like a middle-tier functional API (ideally, Node) that can make requests as needed to a dumb backend that is really just a DB endpoint and then runs functional computations (map/reduce) to marshall the data as configured for a view to a client. You don't have to hassle backend for expensive API updates on a heavyweight language that makes exposing an endpoint a pain in the ass (sorry, Java), and you get exactly the data you need in exactly the way you need.

drewrv 11y ago

You don't even have to go that far. Just let the 'front end' developer write json api's.

marcus_holmes 11y ago

I remember the days of 3-tier client-server computing. This exact problem. How much knowledge does your middle tier need to have about your presentation tier? Do you shape your database schema to your business logic, or provide stored procs that can translate your "pure" schema into the structures required by the middle tier? All of those questions. The key one we're asking here is "how much business logic do you need in your presentation layer?" Too little then you're round-tripping for simple form validation and your UI is unresponsive. Too much and your UI becomes tightly coupled to your business rules (and you start exposing too much attack surface). Modern SPA web apps are making a deliberate trade-off, moving more logic into the client so the app is more responsive. The problem of making the API schema "pure" or tightly coupling it to the UI is the same old "how much business logic sits in the database" debate. Ideally, of course, all endpoints would relate directly to application entities so that changes to the UI don't change the API. But this increases the number of round-trips and reduces responsiveness. Same for rendering HTML on the server - increased round-trips and reduced responsiveness. The answer depends on the trade-offs that the project needs. Is the API complex and used by lots of clients? Keep it pure. Is the API small and/or used by only one client? Tailor it to the client? Is responsiveness paramount? Put as much as possible client-side. Is security paramount? Put as little as possible client-side. IMHO there is no right answer that works across all situations, just as there wasn't back in the 3-tier day.

carsongross 11y ago
Yeah, but I see them making a lot of the same mistakes that were made back then and I can help but notice that, in the context of web applications, you have an opportunity to render the UI in a trusted environment where the code being executed is guaranteed to be written by a non-hostile by just rendering/executing server-side. If you throw HATEOS-without-thinking-or-arguing-about-it on top of that, it seems like a no brainer to bias toward that approach. I used to think that web apps were dumb and thick apps were obviously better in most cases, but I've changed my tune in the last few years as I've come to understand HATEOS and disentangle it from the JSON API quagmire it got into: http://intercoolerjs.org/2016/01/18/rescuing-rest.html http://intercoolerjs.org/2016/01/18/rescuing-rest.html