3 ms·

Is code sharing actually a thing between the front-end and back-end? I find that almost all interesting code "re-use" comes from libraries.

drcode 8y ago
It's pretty awesome now that graph query languages (graphQL, etc) are so popular: Lots of reuse possibilities when you use the same query language for updating the browser state and also updating server side actions.
dustingetz 8y ago
The question is motivated by the observation that a set of REST webservices, and a set of React views that consume them, are so different that there isn't any code reuse. I'd ask you to note the parallel structure between them. They are two sides of the same data sync problem. Yes, of course there are common bits that can be factored out. The problem is that most people have never so much as thought about it, because of the language barrier, and other barriers – for example teams are structured around this artificial divide of frontend and backend. You need a new architecture to take advantage of the parallel structure. GraphQL is just the beginning.
- deleted 8y ago
  [deleted]
- dustingetz 8y ago
  React.js, if you squint, is also a step in this direction – React.js on the client can bind to a DOM, or run in Node and stream strings to a socket. In other words React decoupled HTML rendering from platform APIs by making it data driven. Data is universal and can be manipulated on any platform, even pencil and paper. What other platform APIs can be replaced by something data driven? I know from my study of Haskell that the answer is probably: all of them.
  - threatofrain 8y ago
    I'm quite curious as to when types and methods are going to be shared across boundaries.
    - dustingetz 8y ago
      I think that is a mistake, because data is universal but types and methods are not. Consider a value {"a": [42, 43]} - it could be mutable, immutable, persistent, optimized for ordered traversal, optimized for random access lookups, optimized for insertions.
      - threatofrain 8y ago
        From one perspective types and methods aren't universal, but data is, because once information arrives over the wire you aren't even initially sure if it is what you think it is. However, when backend and frontend code exists in the same context for analysis, aren't there enough certainties to know the space of possibilities for what you're going to receive? How much uncertainty precludes the useful sharing of types and methods?
        dustingetz 8y ago
        Well if I have EDN or JSON on the wire, and have the same portable Clojure library running on both sides, doesn't that pretty much accomplish the same thing as serializing actual object instances? Or is that what you meant all along?
fulafel 8y ago
You can have the shared source files in the same project with the CLJS front-end and Clojure back-end. This way, at development time, there is no friction related to updating different projects or release artifacts, you just live-reload the updated namespace in frontend & backend. A common use case for the shared code is manipulating the application's domain data structures. Sharing the code for these manipulations is routine. In SPA apps you frequently do more than just render views for the backend, and then you typically want to have the backend's internal representation of the data at hand even at the frontend. You can call it a library use-case of course, depending what unit of modularity you choose to call a library. But this way you don't have to update 3 projects for each change (app-backend, app-frontend, app-shared) and you can very flexibly refactor stuff into the shared namespace without breaking the normal flow of development.

drcode 8y ago

It's pretty awesome now that graph query languages (graphQL, etc) are so popular: Lots of reuse possibilities when you use the same query language for updating the browser state and also updating server side actions.

dustingetz 8y ago

The question is motivated by the observation that a set of REST webservices, and a set of React views that consume them, are so different that there isn't any code reuse. I'd ask you to note the parallel structure between them. They are two sides of the same data sync problem. Yes, of course there are common bits that can be factored out. The problem is that most people have never so much as thought about it, because of the language barrier, and other barriers – for example teams are structured around this artificial divide of frontend and backend. You need a new architecture to take advantage of the parallel structure. GraphQL is just the beginning.

deleted 8y ago
[deleted]
dustingetz 8y ago
React.js, if you squint, is also a step in this direction – React.js on the client can bind to a DOM, or run in Node and stream strings to a socket. In other words React decoupled HTML rendering from platform APIs by making it data driven. Data is universal and can be manipulated on any platform, even pencil and paper. What other platform APIs can be replaced by something data driven? I know from my study of Haskell that the answer is probably: all of them.
- threatofrain 8y ago
  I'm quite curious as to when types and methods are going to be shared across boundaries.
  - dustingetz 8y ago
    I think that is a mistake, because data is universal but types and methods are not. Consider a value {"a": [42, 43]} - it could be mutable, immutable, persistent, optimized for ordered traversal, optimized for random access lookups, optimized for insertions.
    - threatofrain 8y ago
      From one perspective types and methods aren't universal, but data is, because once information arrives over the wire you aren't even initially sure if it is what you think it is. However, when backend and frontend code exists in the same context for analysis, aren't there enough certainties to know the space of possibilities for what you're going to receive? How much uncertainty precludes the useful sharing of types and methods?
      - dustingetz 8y ago
        Well if I have EDN or JSON on the wire, and have the same portable Clojure library running on both sides, doesn't that pretty much accomplish the same thing as serializing actual object instances? Or is that what you meant all along?

fulafel 8y ago

You can have the shared source files in the same project with the CLJS front-end and Clojure back-end. This way, at development time, there is no friction related to updating different projects or release artifacts, you just live-reload the updated namespace in frontend & backend. A common use case for the shared code is manipulating the application's domain data structures. Sharing the code for these manipulations is routine. In SPA apps you frequently do more than just render views for the backend, and then you typically want to have the backend's internal representation of the data at hand even at the frontend. You can call it a library use-case of course, depending what unit of modularity you choose to call a library. But this way you don't have to update 3 projects for each change (app-backend, app-frontend, app-shared) and you can very flexibly refactor stuff into the shared namespace without breaking the normal flow of development.