api and site should be separate?

[davidmarkclements]

Proposal:

├── fuge
│   └── compose-dev.yml
├── service1
├── service2
├── api
└── site
    └── public

api should use restify and tie directly into microservices

site should be anything defaulting to Hapi - but extremely minimal - mostly static, talks to api

The site part is the bit that will be most opinionated among dev/teams so should IMO be most sparse.

[mcollina]

The big problem is finding a good opinionated way for setting up the project. We'll all have our different ways of doing it.

I tend to be a big fan of chairo and lout. And personally I would keep it simpler, ditching both "api" and "site" for a "main" or "web" component.

[mcdonnelldean]

I'm also working on a ui that will plug directly into seneca and enable message based react components. The idea being there is no actual server. The frontend simply connects to each required service.

[lucamaraschi]

I would never "squash" an api and a website together if not just in the repo!Looking at the deployment these should be completely separated. For the framework of choice I think we should stay on something simple and more linear like restify, but we should enforce the pattern of not serving static files/assets from the app but from a reverse proxy.

[davidmarkclements]

I would be advocating the simplest possible default config - as minimal and normative as possible - we want to avoid devs having to work to undo things that always feels like a chore

[briandela]

@lucamaraschi I would have a concern about forcing the serving of static files/assets from a reverse proxy. While I completely agree with it from a best practice perspective, it essentially means PaaS setups like heroku and Azure websites are 'not supported' but the default setup.

[pelger]

We should come to some kind of consensus here. I think we should externalize the generators allowing individual projects to plug in their own variants. @lucamaraschi fair point but, remember that this is scaffolding i.e. a starting point only. That being said would be awesome if you could update the generator .

[AdrianRossouw]

Ok, so I agree with Mark's sentiment here that we should split the API and site folders.

The primary reason I feel that way is because the majority of the yeoman generators (and probably scaffolding tools in general) exist to bootstrap front-end apps. This means there are hundreds of different front-ends that can already be integrated.

All that's missing is some boilerplate that will take something we know is front-end only and wrap it in some http server. Which could potentially be swapped out for something that publishes to S3 or whatever. (I find front-end code in docker containers to be a devops code smell).

Having a generic way to take a generated front-end and strap it onto the backend of your choice is the best thing we can do for our potential users in this case.

• "i want a [restify | hap | express] back-end" click ...
• "i want an [react | angular | backbone ] front-end" click ...

Versus :

• "Find a generator that matches my back-end and front-end requirements exactly"...

If we want to make our generators useful to end-users, we are going to have to be proactive in flattening out the problem space. The requirements have too many variables which will end up with an explosion of scaffolding that is never quite right for anyone

[AdrianRossouw]

The code that needs to be generated for a hybrid (front-end + backend) service is also a lot more complex and finicky than it needs to be. Having multiple build processes that need to be kicked off is just inviting bugs.

On a new install, I ran into this :

Sikozu:fugetest adrian$ fuge build fuge/docker-compose.yml 
building...
building: frontend
[frontend - 7744]: npm[frontend - 7744]:  [frontend - 7744]: WARN [frontend - 7744]: EPACKAGEJSON site@0.1.0 No license field.
[frontend - 7744]: /bin/bash: line 0: cd: api: No such file or directory
building: service1
building: service2

Instead of just having a single package.json that needs to be installed.

[AdrianRossouw]

I should also mention, that while I don't know the history of this decision... I'm of the opinion that we shouldn't be creating any services when you initialize fuge at all..

I found the fact that it assumes that I even have a site to be both strange and frustrating. I can only see what it does now to be useful exactly once, and get in my way every other time.

What I wanted out of this was something like :

mkdir my-system
fuge init
fuge generate hapi backend
fuge generate react-webpack frontend

What this seems to be is more in-line with :

fuge generate fuge-demo-system

[pelger]

The initial generation implementation was always intended to just be a starting point. I agree @AdrianRossouw that it can be improved significantly - even perhaps to the point of awesome...

[jimthedev]

I'll throw this out there which lines up with what @AdrianRossouw wrote. This is perhaps a dream, but since this discussion is happening I want to make sure it is heard now rather than later. I'd love to be able to run something like the following to use koa-graphql and React Native graphql.

fuge generate koa-graphql backend
fuge generate react-native-graphql frontend

[AdrianRossouw]

@jimthedev precisely.

We need to have the ability to bring in services like that, and make it really really simple to maintain those scaffolds, so that we get a larger library of them that work flawlessly with our system.

[AdrianRossouw]

splitting this into 2 generators.

generator-seneca-rest and generator-fuge-static