I do it like @adambene. Putting the code into microservices.

That is, because of the corporate environment, I have to stay backend-agnostic. Google and other web crawlers can't parse our SPA's. Therefore, we don't need to care for SEO or having content inside of <noscript>. The first-page-hit looks a bit slow. But since we have our company CDN established, even that seems acceptable regarding speed. Additionally, we store web assets in HTML app cache. On corporate side we have 3000 office PC's across the globe, due to some routing issues, people can't judge if our side is slow due to Coding/Libraries/Frameworks or due to network issues.

On React.js Node.js apps, I am also not reusing much of the code. We cache web assets via service workers -> ponyfoo.com/articles/progressive-networking-servi… But we use a little different approach.

1. On page load -> opac overlay with loading spinner rendered from static index.html
2. Document ready -> Initialize the SPA
3. Check if something according to URL is in service worker cache
   • If not -> React render() HTML, store render() result in service worker
   • If yes -> React fetch cached HTML and render it, React render() semi opac overlay with loading spinner, fetch current data
   • On data received -> destroy overlay, React render() HTML, store render() result in service worker

It's still not SEO friendly and it's also not progressive-enhancement, but getting stuff done.

Applications these days rely on distributed, redundant and scalable microservices. Gone are the days when you could write an app in PHP with the Frontend and the Backend strictly coupled (PHP, seriously?)

I'll give you a simple model everyone uses these days: a frontend, usually written in AngularJS, Ember or React; a backend, say Node.js (because why not); a messaging stack, Redis or RabbitMQ. Personally, I prefer RabbitMQ and ZeroMQ for MQs. And a data tier: combination of volatile storage options, persistent storage options and what not.

If you're in a big team, sharing the code becomes redundant. I mean, seriously. If you see it in this way: frontend code is generally written for cross-browser compatibility; for server-side, stripping all of that code, re writing it for cluster management is a big pain.

However, there are times when you HAVE to use the code. Say, a database adapter or whatever. For that, I use the Universal Module Definition. Something like this:

( ( root, factory ) => {

    if ( typeof define === 'function' && define.amd ) {

        // 'define' is used in Async. Module Definitions
        define( [ '--Dependencies--' ], factory );

    } else if (typeof exports === 'object') {

        // Node/CommonJS export object
        module.exports = factory( require( '--Dependencies--' ) );

    } else {

        // Otherwise, attach it to the root object we provide
        root.attachedExports = factory( root.dependency );

    }

}( this, FACTORY_FUNCTION ) );

And then upload it to either a private NPM repo, or wherever I like. Works flawlessly across everything.

That was code sharing. If I have to share some services, I create a deployment pipeline, attached to the core process (the primary app requiring it) and then add some children (any other processes which want it). This eliminates a lot of security risk there is when sharing services and works very well.

Since these services are easy to deploy, it helps in scaling it as well.

I like Adam's (@adambene) answer. IMO, companies that are trying to build universal (isomorphic) SPAs will reuse a lot of code on backend and frontend. For example, Hashnode is a universal app. So, it's important for us to write components that can be rendered on both client and server. This is where you will need to reuse a lot of code between frontend and backend.

But when I used to build simple SPAs with Angular, I didn't reuse a lot of code on frontend. The only places where I reused code were form validations and other simple stuff. I don't think developers usually reuse a lot of code between client and server, unless they are building isomorphic apps.

I use angular in the forntend so I don´t share any code with my NodeJS Express backend. I also use Microservices and because all have there own Database. For some Databases I wanted some extra Methods that wrapp around the actual NodeJS wrapper, I wrote a libary which I use in my microservices, so that they all use the same "wrapper of a wrapper". Thats the only code I "share".

When I need to communicate from the Frontend with a service (only api-service with routes to other services) I use a REST API. For communication between services I also use REST API´s but currently I add async routes like AMQP and MQTT which will be priamry and prefered, only in special cases or when RabbitMQ is down the REST API is used.

In the age of single-page apps (like Hashnode itself) and microservices, backend and frontend are usually totally decoupled.

And decoupled components should have well-defined interfaces - usually REST APIs.

When I have to share some logic between frontend and backend, I usually put it in a microservice so it can be used without any technology restrictions. It can be used from a native mobile app or a single-page app. It has a very low cost to replace any of these microservices.