Stator: A full-stack boilerplate – releases, deployments, enforced conventions(github.com)
github.com
Stator: A full-stack boilerplate – releases, deployments, enforced conventions
https://github.com/chocolat-chaud-io/stator
8 comments
Very cool. Node has been on my back burner to learn for years, but making the mental leap from tutorial-sized projects to anything more complex has been particularly difficult. Perhaps this will help!
Yeah this handles a lot of the complexity of setting up a complete project with TypeScript and has some nice examples. Try it out and let me know how it went ;)
It's funny how the author went for React for the frontend, even though Angular + Nest.js are a much more synergistic duo. He even structured the application like a typical Angular app.... Why not simply just go with Angular? :D
I'm working on a set of schematics that generate an Nx Workspace using NestJS and Angular. It uses GraphQL to communicate between frontend and backend and the data layer uses Prisma.
It's pretty much work in progress but you should be able to scaffold out a new working project.
Feel free to check it out. Happy to answer any questions
https://github.com/nxpm/stack
It's pretty much work in progress but you should be able to scaffold out a new working project.
Feel free to check it out. Happy to answer any questions
https://github.com/nxpm/stack
Very interesting, we should get in touch to see if there is a possibility of collaboration here. If interested, email me [email protected]
Totally biased opinion as I'm familiar with React, but if you want to learn more about the thought process behind the decision, I recommend reading this: https://yann510.hashnode.dev/creating-a-todo-application-usi...
maybe they were familiar with React and not with Angular?
Curious about your thoughts on TypeORM. Have you used it at scale at all? I rebuilt the API portion of an app using it a few months ago and instantly ran into issues with things like relationships and slightly more complex queries. I know it is an ORM and isn't suitable for every use case and definitely not super-complex queries, but it seemed very limited and unstable.
Honestly, I don't like any of the Node ORMs out there, especially when you compare them to more mature projects like Rails' ActiveRecord or Laravel's Eloquent.
Honestly, I don't like any of the Node ORMs out there, especially when you compare them to more mature projects like Rails' ActiveRecord or Laravel's Eloquent.
I haven't used typeorm for any real world projet yet. Although when I tried using the mongo driver, literally nothing worked. I also ran into problems from the generated migrations where I would get errors when trying to run them.
Even with these encountered problems, I'm still willing to give it a try for my upcoming project. I'll probably write an article on this if things go bad.
For sure, this is less mature then the others out there, but I think it has a bright future as it has a nice syntax and cool features.
Even with these encountered problems, I'm still willing to give it a try for my upcoming project. I'll probably write an article on this if things go bad.
For sure, this is less mature then the others out there, but I think it has a bright future as it has a nice syntax and cool features.
Check out Prisma. It generates lot more complex types and supports relationships pretty well
I've been really interested in checking out Primsa, but I was a little concerned about putting an extra layer between the database and the app. I should give it another look.
I will definitely check this out, thanks for sharing!
Nikolas from the Prisma team here :) let me know if you have any questions, always happy to help! (You can ping me on the Prisma Slack [1], I'm `@nikolasburk` there as well).
Also note that we've just opened up an early access program for Prisma Migrate [2] (which enables schema and data migrations), would love to hear your thoughts on our approach!
[1] https://slack.prisma.io
[2] https://www.notion.so/prismaio/Public-Documentation-for-Pris...
Also note that we've just opened up an early access program for Prisma Migrate [2] (which enables schema and data migrations), would love to hear your thoughts on our approach!
[1] https://slack.prisma.io
[2] https://www.notion.so/prismaio/Public-Documentation-for-Pris...
Awesome, will definitely check that out!
Am a data scientist and don’t do anything with JavaScript but I love seeing stuff like this just to get a feel for the lay of the land and how everything fits together.
Happy you like the stack :)
People in the web world frequently omit identifying their technology as being in the web world. For people outside the web world, like me, it's tedious to scan for key identifiers amongst the generic terminolgy like "template" and "application".
It's technically not necessarily a "web world" template. The Nest.js backend can be used to build any kind of server side application, not just web based.
> server side application
Certainly you understand my general sentiment, yes? Which is that the project page does not attempt to specifically define itself; Rather it assumes the reader understands it's purpose.
Server side application alone is a useful enough specifier.
The only relevant word in it's first few paragraphs is "stack" which has been claimed by the Web people ("full stack developer").
This is analogous to American's omitting the specifier that "America" because they assume all of their readers are also American.
I think the basic sin here is trading specificity for elegance. Your readme is very elegant, but it's not very informative for people from outside your target domain. This will include students and beginners to your target domain, which will ultimately hurt your adoption.
My point can be summed up as this:
"go-to template for the perfect stack" is jargon that only has meaning for a narrow subset of your audience.
"Perfect" is also overselling this thing. I respect tools that give me a clear idea of when to use it, and when not to.
This slogan ultimately says "Stator is a template"
What is a template? That term is far too overloaded to be useful.
I'd call this thing "an opinionated starting point for modern web applications". The most informative section of the document is the "Technical Stack" section.
Now what I'm trying to figure out is what aspect of this thing is not "glue" that holds these pieces together? Is it all glue?
Just to be clear, I think this repo has tremendous value. I'm giving you my stream of consciousness feedback in an effort to help you understand what the average developer's immediate response to this page is.
I think if you sent this link to any random developer on slack, their first response would be "what is it?". I think your readme can do a bit better job answering that question.
Certainly you understand my general sentiment, yes? Which is that the project page does not attempt to specifically define itself; Rather it assumes the reader understands it's purpose.
Server side application alone is a useful enough specifier.
The only relevant word in it's first few paragraphs is "stack" which has been claimed by the Web people ("full stack developer").
This is analogous to American's omitting the specifier that "America" because they assume all of their readers are also American.
I think the basic sin here is trading specificity for elegance. Your readme is very elegant, but it's not very informative for people from outside your target domain. This will include students and beginners to your target domain, which will ultimately hurt your adoption.
My point can be summed up as this:
"go-to template for the perfect stack" is jargon that only has meaning for a narrow subset of your audience.
"Perfect" is also overselling this thing. I respect tools that give me a clear idea of when to use it, and when not to.
This slogan ultimately says "Stator is a template"
What is a template? That term is far too overloaded to be useful.
I'd call this thing "an opinionated starting point for modern web applications". The most informative section of the document is the "Technical Stack" section.
Now what I'm trying to figure out is what aspect of this thing is not "glue" that holds these pieces together? Is it all glue?
Just to be clear, I think this repo has tremendous value. I'm giving you my stream of consciousness feedback in an effort to help you understand what the average developer's immediate response to this page is.
I think if you sent this link to any random developer on slack, their first response would be "what is it?". I think your readme can do a bit better job answering that question.
You are right that having a fresh eye on the project might be hard to grasp what it actually is. You easily become biased from working on a project, you make readers assumptions without even realizing it.
Although to your point that the jargon is too specific is a bit concerning to me. When I go on and discover a new project, if I don't understand specific terminology, I will go on and read about it to increase my knowledge of this topic. If you're not from the "web world" and you are not familiar with what full-stack means, you should go on and read on the subject simply out of curiosity!
Once again, I totally get your point that the project first few lines should be more informative as to what it is exactly and how it can be used.
I have in fact created an issue for it: https://github.com/chocolat-chaud-io/stator/issues/105
Although to your point that the jargon is too specific is a bit concerning to me. When I go on and discover a new project, if I don't understand specific terminology, I will go on and read about it to increase my knowledge of this topic. If you're not from the "web world" and you are not familiar with what full-stack means, you should go on and read on the subject simply out of curiosity!
Once again, I totally get your point that the project first few lines should be more informative as to what it is exactly and how it can be used.
I have in fact created an issue for it: https://github.com/chocolat-chaud-io/stator/issues/105
I appreciate you being receptive to my feedback.
Cool project! I like the building block approach.
Is optional graphQL support on your mind? I have seen working examples using typeorm models and some glue code/libraries.
Is optional graphQL support on your mind? I have seen working examples using typeorm models and some glue code/libraries.
We thought about it, but decided not to implement that for V1. Might be something we do in the future. If you'd like to see that, you could create an issue for it! :)
How long will this be good for?
Has the pace of library turn-over slowed over in JS land?
Last time I checked, express was still a thing for web services.
Last time I checked, express was still a thing for web services.
We've currently selected very hot and trendy libraries which are currently maintained. Although the goal of this project is to be used for projects in production. Right now we haven't tested anything large scale, but the goal would be to replace any technology that isn't suitable for production.
We will be testing stator out with a large scale production project (that's why we plan on implementing kubernetes support) and we will update the libraries accordingly.
We will be testing stator out with a large scale production project (that's why we plan on implementing kubernetes support) and we will update the libraries accordingly.
Why fastify and nest?
You can read this article to get all the details on the decision: https://yann510.hashnode.dev/the-best-node-web-framework-par...
Oh ok, I guess I forgot nest supports different "platforms", thanks.