Unicorn: The Pseudo Framework
A few days ago I posted this joke tweet…
I’ve spent over 15 years being involved in the tech industry and in that time, I’ve seen many different frameworks come and go, each one with a sizeable following and each one thinking that they have “got it right”.
However, in the past few years, the concept of Agile and minimalism in the framework has become more and more important. The idea of lean startups means that if you build on a behemoth of a system, then you cause problems later on. I can’t begin to tell you how much of a hassle it is building on top of Wordpress (other ridiculous startup choices as a tech platform are available — although Wordpress can be the right solution sometimes).
Nobody (as far as I know) has really made the leap to creating what would be a “pseudo” framework though — something not actually real but that could be developed in any language and give you the ability to use technical skills across the board rather than being forced down the “Only X technologists please” route.
Why a “pseudo” framework?
Because it’s difficult to build a complete framework from the ground up on multiple platforms. The idea is to develop the pseudo framework with the rules around that framework
What would be in it?
I don’t know exactly, but here’s my thinking so far (in no particular order)…
Simple! Any language, you get the same documentation with code samples for each (like a multi-language SDK)
Simple regex based routing
The singular most useful thing that we’ve built into web frameworks in the past few years.
API-ification of the framework (microservices)
The most important thing is separation of front end and back end in my view. Making the framework a microservice by default is how I would approach this. Simply put, the routing (above) is essentially putting out a JSON API. Adding in a simple in-built documentation solution for this API would be superb.
Automatic generation of SDKs
Complete separation of front and back end
Given the above, this is obvious I think, but each interface is different, and I would essentially want to remove the idea of forcing anyone to use any specific front end. With SDKs in built, then you can build whatever front end you want. Maybe the SDK would provide you with “in built” generators for major platforms e.g. you want it angular.js? Here’s the beginnings of the angular solution you need... oh you need an android app? Here’s a generator for that too.
Cloud scalability out-of-the-box
Some frameworks have this already, but this is often missed. Too often, the tutorials define the development environment, and this is then followed by the other tutorials from “real people” that tell you how to “actually” put it into production. And then the tutorials get old, and people follow the old tutorials.
Simply put, this is something like “here’s the command to create your docker (other containers are available) container(s) for this app”.
Simplified Data Layer
We all love ORMs and they are vital nowadays. We’ve actually lost the art of developing correct data layers now though. The number of times I see a startup just “chuck” their data into a terrible data structure is too numerous to mention. And the gratuitous use of things like MongoDB for when a SQL based database would be far more sensible is so widespread that it makes me cringe. Just because you use a NoSQL database, doesn’t mean your system is “better” by default.
Coming back to this point though, the data layer is key, and the ability to interact in both a simple (ORM) way and a more integrated approach between tools (such as Redis and PostgreSQL for example). It’s not about telling people what to do, but on a pseudo-level giving them “best practices” about the way data should be integrated.
Models are key here — but I’m not advocating MVC/MVT/MVW or anything. I’m simply saying that if you generate a model and (say) want to move it from the RDBMS you are using to a NoSQL solution, you should be able to simply migrate and continue, rather than recode and rework.
Initial administration in-built
One of the things I really miss in non-django frameworks is the ability to generate an “out of the box” solution for administering the data layer.
It’s not perfect, and is not always what is needed (you often build another admin layer after the initial work) but it saves you having to do it in the first place. Admin systems are mostly a waste of time and effort specifically on prototyping. Remove that, and then you can build the service to learn from uses and build the right interface later on.
In-built automatic tests (TDD/BDD/etc)
Given the above, it would make sense (would it not) to at least give the developer some help when writing tests. Tests are great, but they are not the “be all and end all” especially when working on prototyping. If you build an API you should be able to at least “guess” what kind of tests might be needed for some of those and be able to then test it. Doesn’t remove the need to to proper testing over time, but it’s a start.
Um… just because it’s awesome. But a framework defining properly how to work with distributed teams would be of value. Build this into the way of working and it would be easier to onboard a person onto a project.
Continuous Integration as a requirement
CI is an interesting issue. The number of times I see people say “we do CI really well — we have Jenkins” and then I look and find that it’s just a box they have ticked in their “We do CI”-ness is too numerous. Essentially some form of compilation of the project should require a step like this.
Simple integration between two instances of the same framework
Basically, if you build a solution in this framework in Java and another in Python, then they should be able to easily talk to each other in a few lines of code. A simple way of “chaining” solutions together would be of real value.
Version based best practices/docs
I love Stack Overflow (and it’s equivalents elsewhere). If I’m stuck, it’s the first place I go (sorry to burst the aura of invincibility for you non-techies — it’s where to go to get the answers). BUT the answers are not version specific (unless they say so). Django is the best platform I’ve used for managing it’s documentation. If you’re stuck, you go there and specify the version you’re using and voila! You get the right documentation. No other framework I’ve seen does it as well. It’s invaluable.
So whatever this framework does, you should be able to provide a set of best practices (not just documentation) for each major version of the framework. That way, if you’re a newbie or an experienced dev, you end up with a pretty good idea of how to do something with a quick search.
Because open source
Superb on boarding
Because if you can’t take a person easily from no knowledge to being able to deliver, then nobody would use it. Some frameworks are great at on boarding for a simple idea and leave you flailing. Others are great at “in depth” on boarding, but the learning curve is extraordinarily hard. Combine the two, and you should be fine.
Why call it Unicorn?
I know it won’t ever be real
At least, not in this format. The more I think about it, the more I realise it’s more than one person could develop anyway. The idea is to get framework makers to think a little harder and to stop saying “our language is best“ and to start thinking about best practices and future proofing their frameworks.
The worst frameworks to work on now, are the ones with pre-cloud legacies and an extensive “old-school” (this is how we’ve always done it) user base. Unfortunately, they are the ones that have extensive docs, books, people etc and are still sold into clients as “current” because they have a new version out. Just for reference: never use PHP as a framework to build a prototype — it’s a bad idea!
The best frameworks are yet to be built, but they are the ones that support your development, support the delivery and provide you with tools to get you going fast.
Hope you like my nuts little idea…
P.S. If anybody wants to fund this effort get in touch!