4 ms·

Show HN: Lumie, an opinionated NPM module to create better apps and ship faster

21 points by AlexLevacher 8y ago

misterbowfinger 8y ago
So.... it's like Rails?
- bluehatbrit 8y ago
  It looks like it's just the rails routing, nothing else. It doesn't include any of the ORM stuff, or even any of the defaults. It's simply routing by convention. To say it's like rails is to say a skateboard is like a car because it has 4 wheels.
- AlexLevacher 8y ago
  You got it bluehatbrit! Yuchi is right in the sense that I got inspiration from ROR routing. But we are far away a large framework like ROR or even Sails.js, Lumie is not comparable to them, this is not the same usage, Lumie is helpful to keep organized while growing your controllers codebase.
ericpauley 8y ago
I've made the mistake of using "opinionated" libraries in the past. Usually what it means is that they lock you into a workflow designed by someone with different use cases from yours, to a fault. A product I'm working on is being choked by another opinionated framework as author's opinions no longer align with best practices and we're locked in.
- jmull 8y ago
  It's fair to point out the limitations of libraries like this, but it's only a mistake if you don't understand what you're getting into. There's a definite tradeoff: short-term productivity vs. long-term flexibility. I think there are certainly cases where it makes sense to choose short-term productivity, as long as you understand the potential tech debt you're incurring.
- AlexLevacher 8y ago
  maybe I was a bit clumsy with my title because this project was designed to not lock the user but to lead him to a nicely structured app architecture.
yuchi 8y ago
It’s not a module. It’s a package. Or a library. But definitely not a module.
- jmull 8y ago
  Tisk, tisk, if you're going to be pedantic, you should at least get it right: https://docs.npmjs.com/getting-started/packages https://docs.npmjs.com/getting-started/packages (In the context of node, it's both a package and a module.)
  - AlexLevacher 8y ago
    We could not have found a better source, thanks
  - yuchi 8y ago
    Been burned down to the last bit. Hats off.
jitl 8y ago
I like the idea of this package overall: reducing route-losing boilerplate and enforcing a convention are wins in my book. However I do have some notes and questions about the design. 1. In the structured example [0] (link to this is broken in the README, btw), filenames contain the directory name, which stutters: controllers/user/user.action.js. Why not either use index.js, or unprefixed names like action.js? 2. With file paths providing routes like this, one strength is that one can rename a route by moving files around. However, your example controller specs [1] have the route path hard-coded, including config like the Lumie prefix that a controller shouldn’t be concerned with at all. You should find a way to remove this inverted dependency. When I write express apps, I create a new app for each route, and then mount them all in the main app, so that no controller knows it’s own route, and controllers and routes are easy to relocate. You could do the same by expecting specs make their own call to Lumie.load with __dirname or something, to load just the controller they test at /. 3. You should provide an example of nested controllers routing, eg GET /users/:id/pets , /users/:id/pets/:id, as I’m unclear how to structure that with Lumie. [0]: https://github.com/Alex-Levacher/Lumie/tree/master/example/controllers/user https://github.com/Alex-Levacher/Lumie/tree/master/example/c... [1]: https://github.com/Alex-Levacher/Lumie/blob/master/example/controllers/user/user.spec.js https://github.com/Alex-Levacher/Lumie/blob/master/example/c...
- AlexLevacher 8y ago
  Thanks for the feedback, and for having took time to take a deep look into the project. 1. In the structured example, I decided to name my files this way because I felt it is more convenient, for example when you navigate in your code editor. Furthermore I got inspiration from Angular2+'s naming conventions. But in fact you can name your "actions" and "routing" files as you want, but you have to set in Lumie's configuration to not search for a "routing configuration" in those files. This is why a I told Lumie to exclude all .action files. So if you want to name all your actions files: "action.js", you have to exclude: "action.js". 2. You are right, this is a good point. This could be the object of my next PR 3. You can do it the same way as others, you can use whatever routes names you want. I'll add another example to illustrate it I've made the changes to fix the broken links. Don't hesitate if you have any others questions or tell me if I was unclear in my answers

21 points by AlexLevacher 8y ago

misterbowfinger 8y ago

So.... it's like Rails?

bluehatbrit 8y ago
It looks like it's just the rails routing, nothing else. It doesn't include any of the ORM stuff, or even any of the defaults. It's simply routing by convention. To say it's like rails is to say a skateboard is like a car because it has 4 wheels.
AlexLevacher 8y ago
You got it bluehatbrit! Yuchi is right in the sense that I got inspiration from ROR routing. But we are far away a large framework like ROR or even Sails.js, Lumie is not comparable to them, this is not the same usage, Lumie is helpful to keep organized while growing your controllers codebase.

ericpauley 8y ago

I've made the mistake of using "opinionated" libraries in the past. Usually what it means is that they lock you into a workflow designed by someone with different use cases from yours, to a fault. A product I'm working on is being choked by another opinionated framework as author's opinions no longer align with best practices and we're locked in.

jmull 8y ago
It's fair to point out the limitations of libraries like this, but it's only a mistake if you don't understand what you're getting into. There's a definite tradeoff: short-term productivity vs. long-term flexibility. I think there are certainly cases where it makes sense to choose short-term productivity, as long as you understand the potential tech debt you're incurring.
AlexLevacher 8y ago
maybe I was a bit clumsy with my title because this project was designed to not lock the user but to lead him to a nicely structured app architecture.

yuchi 8y ago

It’s not a module. It’s a package. Or a library. But definitely not a module.

jmull 8y ago
Tisk, tisk, if you're going to be pedantic, you should at least get it right: https://docs.npmjs.com/getting-started/packages https://docs.npmjs.com/getting-started/packages (In the context of node, it's both a package and a module.)
- AlexLevacher 8y ago
  We could not have found a better source, thanks
- yuchi 8y ago
  Been burned down to the last bit. Hats off.

jitl 8y ago

I like the idea of this package overall: reducing route-losing boilerplate and enforcing a convention are wins in my book. However I do have some notes and questions about the design. 1. In the structured example [0] (link to this is broken in the README, btw), filenames contain the directory name, which stutters: controllers/user/user.action.js. Why not either use index.js, or unprefixed names like action.js? 2. With file paths providing routes like this, one strength is that one can rename a route by moving files around. However, your example controller specs [1] have the route path hard-coded, including config like the Lumie prefix that a controller shouldn’t be concerned with at all. You should find a way to remove this inverted dependency. When I write express apps, I create a new app for each route, and then mount them all in the main app, so that no controller knows it’s own route, and controllers and routes are easy to relocate. You could do the same by expecting specs make their own call to Lumie.load with __dirname or something, to load just the controller they test at /. 3. You should provide an example of nested controllers routing, eg GET /users/:id/pets , /users/:id/pets/:id, as I’m unclear how to structure that with Lumie. [0]: https://github.com/Alex-Levacher/Lumie/tree/master/example/controllers/user https://github.com/Alex-Levacher/Lumie/tree/master/example/c... [1]: https://github.com/Alex-Levacher/Lumie/blob/master/example/controllers/user/user.spec.js https://github.com/Alex-Levacher/Lumie/blob/master/example/c...

AlexLevacher 8y ago
Thanks for the feedback, and for having took time to take a deep look into the project. 1. In the structured example, I decided to name my files this way because I felt it is more convenient, for example when you navigate in your code editor. Furthermore I got inspiration from Angular2+'s naming conventions. But in fact you can name your "actions" and "routing" files as you want, but you have to set in Lumie's configuration to not search for a "routing configuration" in those files. This is why a I told Lumie to exclude all .action files. So if you want to name all your actions files: "action.js", you have to exclude: "action.js". 2. You are right, this is a good point. This could be the object of my next PR 3. You can do it the same way as others, you can use whatever routes names you want. I'll add another example to illustrate it I've made the changes to fix the broken links. Don't hesitate if you have any others questions or tell me if I was unclear in my answers