Best Practices Morpheus says: "What if I told you things can get
simpler, more independent, and more testable, with a separation of concerns in a glorious holy land?"

WebCore is a WSGI nanoframework, a fraction of the size of competing “microframeworks”, and culmination of more than ten years of web development experience. It provides a clean API for standard points of extension while strongly encouraging model, view, controller separation. Being less than 400 source lines of code (SLoC of `web.core`; excludes comments and documentation) and containing more comments and lines of documentation than lines of code, WebCore is built to be insanely easy to test, adapt, and use, allowing any developer familiar with programming (not just Python programming) to be able to read and understand the entirety of the framework in an evening.

* Pypi Package:
* Annotated Source Documentation:
* Source Repository:
* Compatible with: Python 2.7+, Python 3.2+, Pypy, Pypy3
* Dependencies: WebOb, marrow.package
* 100% test coverage.
* Digitally signed release artifacts and commits.

WebCore adds a light-weight dependency-graphed extension layer to WSGI, offering points of extension which replace WSGI middleware, as well as callbacks difficult to implement in bare WSGI, while also supporting standard WSGI middleware both as an application and when treating WebCore as middleware itself. As the #1 thing a typical framework is responsible for is to resolve a URL to a controller to handle the request, this process has been standardized under a "dispatch protocol" ( which WebCore speaks. The Marrow Open Source Collective provide several framework-agnostic reference implementations covering regular expression-based routes, object dispatch (attribute descent), and traversal (mapping descent), as well as more abstract "meta-dispatchers" and "dispatch middleware".

        from web.core import Application

The rest is up to you, the developer. WebCore is as opinionated as a coma patient.

A request comes in, hits the WebCore WSGI Application or outermost WSGI middleware layer, dispatch resolves an "endpoint", the endpoint is executed if callable, and the return value (or endpoint if not callable) is used to find a view which populates the response. The example above relies on the fact that there is a default view to handle strings.

Namespaces, virtual dependencies (extras_require) and standard Python entry_points plugin registration are extensively utilized by the framework. You may place your own packages within the `web`, ``, `web.ext`, `web.server`, etc. namespaces if desired. WebCore is also "optimization aware" and will eliminate several expensive validation tests and all debug-level logging from production environments when run with -O or with PYTHONOPTIMIZE set. WebCore was designed to make use of under-utilized WSGI features such as chunked streaming responses and thus pairs naturally with the template engine "cinje" ( allowing for the ultimate in responsiveness. Where Django gets 2 generations per second on a 1000 row table test, cinje gets nearly 40,000; see the cinje wiki. Eliminate boilerplate and enjoy a snappier app today!

Please give WebCore (and cinje!) a try on your next project or experiment; see the README, many examples, and extensively documented source code to learn more. You may be pleasantly surprised to discover you won't miss those monolithic framework features you weren't using. Join us in #webcore on Freenode IRC if you have any questions or comments; we'd love to hear from you and will gladly assist users getting started using the framework or evaluating and integrating components.

Proudly developed in Montréal with the support of Illico Hodes (

Web-SIG mailing list
Web SIG:

Reply via email to