Spring Python?

Recently, I was watching a very nice overview of integrating your project with Neo4j, MariaDB, and MongoDB put together by Jennifer Reif@Neo4j, and was thinking to myself... I sure wish she had done this in python (not particularly because it is my favorite, but more because it is the predominate language for netdevs these days), which got me thinking, "Is there something like spring for Python?" Turns out there is. Unfortunately, spring.io has not chosen to continue development as it does not support Python 3.x.

After doing a little reading, I gather that spring is not super popular because the python already lends to simple and easy interfacing with databases anyhow. It seems the java version is largely useful for simplifying an anotherwise difficult method of integration by way of spring's "Inversion of Control". For me, this looks largely like an abstraction layer which allows us to define an object (POJO) independent of the model it came from which is handy for switching to a different backend. This may be particularly useful when migrating from one backend to another, or maybe in a situation where you are porting code. Otherwise, it may not be worth the abstraction (remember that abstraction introduces complexity, and complexity is OK if and only if you are gaining some benefit that outweighs the complexity). In most cases with a python implementation, it may be simpler to not include the spring abstraction though.

Design Decisions

Generally, I think divorcing front end from the backend is always a good idea. Even if you are using a full stack framework, I think the framework should have autonomous front/backends (or even better autonomous model, view, and controller components.)

Some current or potential future complexities that may make adding an abstracted middleware (IoC) 'worth it' include:

• likelihood of replacing or adding a different front-end, back-end, or even data source
• Interest in reducing duplication and improving maintainability in your ecosystem (have multiple applications leveraging the same business logic for different applications)
• Any time your in the "change the wheels on the bus while its going down the road" situation. Very often there is a target architecture that we want to get to, but we have to keep everything running between here and there. Using a distributed architecture where functions of redundancy/resiliency, view, control, and model have been decomposed and run as autonomous systems working in concert, will allow you to focus on a function (aspect) of the larger system at a time.

That last bullet is really where IoC is most interesting.

Conclusion

As with most things I read about in Java, I conclude, "thats a nice concept, but seems a unnecessarily complex." If you really want to try to do this in Python, take a look at Depdency Injector, but I would recommend using an autonomous flask container serving CRUDL type endpoints first. While it is true you can get 'tighter coupling' and even better performance using https://grpc.io/ or pyro5, I think good old fashioned REST is most versatile and compatible for a middleware function. If you want to get fancy, have your container serve both REST and gRPC and let clients choose their poison.