Open droganov opened 8 years ago
I'm up for this suggestion. Currently that's sort of how this scaffold operates, there is a data layer, a web layer, and a dev layer that are tied in to one gateway service. Putting them all in an app directory does make sense. I'll consider it.
I think you need to split only a client part. You have one server, which works in two modes (dev and production) I would suggest to start production mode as npm start
and dev mode as gulp
.
Also you have one facade (graphQL server) and some transports behind it, so no changes here.
But as for the client, you can have www app, android app (react native), 2 iOS apps, maybe admin corner. All them talk to single graphQL server.
So there is a strong need to reflect this in boilerplate structure. I'm working on a similar setup and can share some code with you.
I've made some tweaks to this setup in other projects that are more aligned with your suggestion, I'm going to formalize them and work them into this scaffold over the next week or two. The structure will look something like this:
app
---| client
---|---| build
---|---| config (client config)
---|---| src
---|---| dist
---| admin
---|---| build
---|---| config (admin config)
---|---| src
---|---| dist
---| data
---|---| lib
---|---| migrations
---|---| models
---|---| schema
---|---| seeds
config (global config)
interfaces
lib
will wait for the update
@droganov it is implemented in universal
branch https://github.com/cdebotton/react-universal/tree/universal
To run app you should do this steps (correct only on current date, because Cristian still in progress):
1) npm install express koa
(they absent in package.json)
2) copy folder [master]/data/schema
to [universal]/app/data/src/schema
(to fix graphQL errors, by mock data)
3) npm run dev
How I see there is problem with hot reload. But such beautiful app config structure and nice console output I'm never seen.
@nodkz thank you, will look into that!
By the way, I don't think the structure is dry enough, what's the reason to have src/build/dist in each app?
At my point of view dry structure should look like this.
Technically we have 1 server which runs several apps. So no point to store built data within the app folders.
Hello, you've came a long way, but please consider implementing the following app structure:
The idea is that we eventually run several apps at once on single server