Finch has just reached version 0.7 and we're still months from the first "stable" version (in quotes, since Finch has always been pretty stable: minimal and reasonable API changes, no major bugs/regressions found since 0.1) but's a very good time for us to look around and see where to swim.
This write-up is not a roadmap for 1.0, it's mostly an attempt to analyze Finch's Future and to choose a direction in wich the roadmap to 1.0 will be defined.
While, Finch is built using purely functional abstractions, it's still might be described as "low-level" framework or library. Finch doesn't give the developers an answer on very simple question: "How to organize my codebase?". Frameworks usually answer it pretty well - "Here is the controller class. Implement those methods and you're all set.". Helping the developers with this sort of questions is clearly a major priority for Finch. Although, this doesn't mean that Finch will be a framework one day. The project philosophy will always be sticking with a the concept of "purely functional library", not "enterprise framework".
Given that there is no "high-level" version of Finch shipped by default, users have started playing with their own concepts and ideas of what it might look like. As for today, there are at least two good examples of such experiments:
- CRUD-like Finch (codename
finch-crud) - Jersey-like Finch (codename
finch-meta)
Both of the directions look promising, which brings to the table a very reasonable question: "Why not to choose one of them and make it Finch 1.0?".
The idea of moving towards one of the mentioned framework-like approaches has its own pitfals. Whatever approach is chosen, there would be a group of users who won't like it, who would prefer working either with original Finch abstractions or sticking with another framework style. Moreover, there is an army of Finch users who decided to use the project because it's a library, not a framework.
Keeping that in mind, we can paraphrase the question as "Why not to support both styles then?". The answer to that question is "Future Finch".
The Future Finch is library platform built on top of purely functional finch-core with lightweight packages representing micro-frameworks, i.e. finch-meta and finch-crud. Finch users will a have a choice: write their programs using a functional style (functions and types) with finch-core and take care about organizing a codebase or use one of the provided micro-frameworks, which restrict some style but still use all the well-tested and performant Finch primitives underneath.
The main requirement here would be to keep those micro-frameworks as simple as possible. They should solve just one problem. They should provide a style guide for developers while keeping the functionality unchanged. Thus, micro-frameworks should be able to substitute each other.
Micro-frameworks will unlikely happen before 1.0. For now, the highest priority for Finch contributors and maintainers is to build a robust, composable and well-tested core, on which micro-frameworks will be based in future.
This micro-frameworks approach might sound pretty undoable, but not for awesome Finch community, which has alrady proved that things can be done (one year ago Finch was just a 40-line Gist file).