Roadmap?

[sigrlami]

Is there any vision on how the framework will be developed after 1.0? What problems should be addressed, which new features in need? Maybe it's documented somewhere?

ping @mightybyte @gregorycollins @imalsogreg

[imalsogreg]

Good question! Some things that just came to mind that I would like:

• Performance & benchmarking
• HTTP2
• New commandline options api (https://github.com/snapframework/snap-server/tree/commandline)
• Abstracting the Auth snaplet to allow a user-defined auth type (rather than AuthData)

[sigrlami]

I think, I would like to see

• Benchmarks
• Proper HTTPS/SSL support
• Proper Role base management (probably related to external AuthUser, and abstracting this type in general)
• minor - updated official website + some learning materials

I think making Snap first choice for most Haskell web projects is a nice goal.

Maybe we should make community survey on what people most interested in?

[mightybyte]

@sigrlami Thanks for your input. HTTPS/SSL support should be working. I commented on your issue with something to try.

Regarding role based access control...I have implemented that before in a proprietary project and it ended up being VERY complex. We decided not to open source it because it was pretty customized to our use case and it required sophisticated database-fu. With Snap, we made a very intentional choice to make everything database-agnostic. So I would not develop something like that as a part of the core Snap Framework.

I think this is one area where Snap (and Haskell in general) differs from web frameworks in other languages. We are more loosely connected. We don't choose, say, a form package for you. You can use digestive-functors, reform, or anything else. The same thing goes for database libraries and many other things. Many people think of Servant as a web framework in and of itself, but you can even use Servant with Snap via the servant-snap package!

I completely agree with you on website, learning materials, and overall goal. I'm all for a survey to see what users are interested in.

My personal efforts lately have been focused on integration with the more recent Haskell web developments such as Groundhog, Reflex, and Servant. So I am working to lower the barrier to entry to building apps based on these technologies. While this work is most definitely related to Snap, most of it is taking place outside the core Snap Framework. The biggest piece that is a part of the framework is the auth snaplet generalization mentioned by @imalsogreg.

[nurpax]

Is role-based access control something people have asked for? It sounds like something that's complicated to do generically but can also be pretty easy if your app doesn't need very sophisticated roles. At least I'd probably just roll my own if I was developing an app that needed that.

What about sessionless authentication like JWT? I developed a prototype JWT-based authenticator snaplet for one of my projects in https://github.com/nurpax/snap-reactjs-todo/tree/master/src/Snap/Snaplet/SqliteSimple. It felt like shoehorning it into the Auth backend interface would've been quite a bit of work, and I wasn't sure if you can do without sessions. However, it'd still be nice to use some of the Auth functionality like password resets etc.

I'd also prefer the Auth module not to depend on Heist.

+1 for learning materials & updated website.

[sigrlami]

@mightybyte Thank you for response. I understand your position.

While it's nice to have very abstract framework, newcomers might not see what set of technologies best suited for building modern web application with Haskell. I'm in favor of Reflex and Servant, using them myself in company projects. Then framework docs/materials should recommend best possible set of libraries and note that it can be applied with any desired compound.

Is there anything else you want to see included?

I'll prepare a survey and share it with you. Maybe we need another communication channel?

[sigrlami]

@nurpax I think abstracting Auth datatype can lead to easy sessionless authentification. Removing Heist as dependency also a good point.

@mightybyte @nurpax I have custom made role-based subsystem, that I'm tweaking between 3 projects. While I can do in-house abstraction, I thought it's something most modern application need and will be useful to have. But I can't tell currently how hard it is to abstract.