-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
api and site should be separate? #2
Comments
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. |
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. |
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 |
@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. |
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 . |
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.
Versus :
If we want to make our generators useful to end-users, we are going to have to be proactive |
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 On a new install, I ran into this :
Instead of just having a single package.json that needs to be installed. |
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 :
What this seems to be is more in-line with :
|
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... |
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.
|
@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. |
splitting this into 2 generators. generator-seneca-rest and generator-fuge-static |
Use newly merged fuge generators fixes #2
Proposal:
api should use
restify
and tie directly into microservicessite 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.
The text was updated successfully, but these errors were encountered: