Folder for server + middleware

[korczis]

Hi,
what about creating dedicated folder (src/server) for server implementation?

Also what about moving middleware into dedicated folder (src/server/middleware) and file(s)?

For example:

src/server/middleware/compression.js
app.use(compression());

src/server/middleware/favicon.js
app.use(favicon(path.join(__dirname, '..', 'static', 'favicon.ico')));

What is your opinion?

[erikras]

What does this achieve, exactly?

[korczis]

Why to move src/server.js to src/src/server.js?

Because I would like to split server implementation in multiple files but have them in same (non-src-root) folder.

src/server <-- folder with server implementation
src/server/middleware <-- folder with middleware implementation

Or do you suggest to have everything in one file (server.js) ? Or to have all stuff in root-src-folder?

[erikras]

I'm still not understanding. You're talking about express middleware? This project uses almost no express middleware in server.js. Unless you're wanting to easily flip on and off individual middleware libraries, I still don't see the point. You might have that need in your own project, but for an example library, it seems excessive.

[korczis]

I would like to have anything related to server side in one folder. Express middleware, api implementation, etc.

In my opinion this is valuable even for small project. Why? If somebody forks your project he/she can modify it and easily merge updates from upstream (your repo) with almost no hassle.

This is also reason why I created #97

I can move server implementation to another folder and change just one path instead 5 of them (literally).

[bdefore]

i'm a little wary of src/src but i'm definitely fond of things that make upstream merges easier. i think there's two competing objectives that this repo takes on: 1) a base from which to build an isomorphic react project off of and 2) an example project that provides implementations of common use cases like authentication and forms. it'd be nice to be able to merge into the features of the first without having to prune out things from the second.

[sseppola]

May I suggest that we just separate the API from the rest of the app?
The reason is that we can decouple the API from the universal app we make it an implementation detail.

This repo could then function as a great starting point for building universal apps independent of the API implementation, and would allow people to:

1. Build universal apps against existing APIs.
2. Use the API in this repo as a starting point for their API.
3. rm -rf ./api

I'm not saying that this is not possible, nor difficult to do now, but it would encourage this separation and make point 1 and 3 easy.

My use case is that I'm building an app based on this repo that I want to scale horizontally, and I'm planning on "dockerizing" the api and the "app server" separately.

If this is of interest for this repo I can give it a shot and create a pull request.

[LarryEitel]

I looked at MANY react redux projects and have settled on this one from which to build from. I too am working on how to talk to a remote backend API. I too like the idea of making a separation of API from rest of the app IMHO. :)

[codepunkt]

Seems like a smart move 👍

[erikras]

Fixed by #190.

[erikras]

Actually, #190 did not address the original middleware issue. Sorry.

[lycon2014]

All are corect in the matter. 1. Dedicated server. with the functionality to bridge merge and split when needed. with manual on an off or switch merge with split API toggle.. if possible I don't know portals run all as one or at ones choice depending on its pertinent intended individual propose. Apps and folders. Partial front and rooted backend romote one core backbone infastrutcre spider .Web like branches/ /vertebra extention. Off the top of my HEAD. .Middelware purpose is as dual second mind hive like attribute CORE MAKING IT UNIVERSAL

[lycon2014]

If plausible.maybe tangible .programing coding wise..I dont..

[lycon2014]

Know. FOOD for thought..