Do the examples use too many modules? about http-framework HOT 6 OPEN

To get the point of csrf across, you should only use modules that are relevant to show how csrf works. The example on the csrf-lite readme only uses 3 modules.

from http-framework.

I guess it depends what you're trying to demonstrate. It seems to me like examples with lots of dependencies are as you would probably find them in production, which is valuable in one sense, but also confuses the demonstration of a particular concept. For example routes-router isn't necessary in an example demonstrating csrf, but you would probably find a router in a production server. It could be worth having both a light demonstration of a feature and a working production-ready example implementation to go alongside it.

from http-framework.

So I have put a lighter example of csrf-lite in the README.

I think the README documentation should have light examples.

I feel like its nice to have a "production-ready" set of examples in the examples folder but im still curious whether or not I'm going too far.

from http-framework.

More generally, most of these examples are way too heavy in furtherance of feature parity with existing featuresets provided by frameworks like express, which misses the point of using tiny modules in the first place. Tiny modules are easy to wrap your head around and you can drop them into an application incrementally as you build it.

So for example, the auth example at https://github.com/Raynos/http-framework/blob/master/examples/auth/server.js is really gigantic because it has feature parity with some existing express example, but that's not a good survey of the multitude of approaches in solution space. For example, if you take on a different set of trade-offs for doing auth you might end up with something like the persona-id example which is pretty tiny and even includes all the browser code necessary.

I think this collection of examples would be much more convincing if the lines of code present were severely limited and abstracted into modules that encapsulate the roles of multiple related modules more. You can do that with modules and you can always take a step back to use the primitives that the higher-level modules are depending on but you can do it piecemeal when you need to.

from http-framework.

@substack that's an interesting viewpoint. See, when I came across this "feature parity" you mention, I presumed it was intentional. Like, you can achieve what express achieves just without express. To me it would seem like you would need feature parity to make that assertion. I don't think http-framework should be striving to make that assertion, but it feels like it is because it has "example partity", if you want to call it that, with competing frameworks. I presume if we set out to prove that you can do everything express does then then we actually have no quarrel with what express does and how it achieves it, and we were only simply misaligned on some feeling of modular composition. It is indeed a more powerful notion to stay true to the essence of the small modules when promoting the modular approach and to reject the need to do what express does.

from http-framework.

@substack does that conflict with #2 ?

the examples show how to glue multiple modules together to do generic web cruddy stuff. Like having password solution, sessions, forms, session messages on POST REDIRECT GET is a useful example of a generic web cruddy thing.

Maybe we should have a persona-id example as well?

I do want to demonstrate you can do everything. the current approach is porting existing demonstrations of everything. I dont know what all the webby things you might want to do are. I'm using other frameworks for examples.

from http-framework.