@peterg, I do have this code, that can be easily adapted to support virtualfields
The get_meta method need to be patched to support the discovery of virtualfields, and a VirtualFieldDescriptor need to be defined, passing the value getter function and the fieldtype to send to the UI
Frappe’s JSON structured DocType (especially frm.doc of front end javascript) can have 1 to 1 mapping with MongoDb Documents.
I mean, Frappe has this natively (unlike other frameworks which need add-ons like GraphQl). Yet instead of the natural - and currently on the rise - NoSQL database, Frappe only uses the incompatible SQL databases.
Hahaha! You hit the nail right on the head.
Frappe is allows us to benefit from NoSQL on the front end (javascript) and backend app-server (python), despite using SQL databases on the backend.
Frappe would be a lot more powerful with NoSQL databases.
Yes! Absolutely.
For me, I’ll prefer minimal unused functionality.
I really don’t need user table/collection in my code! Why keep non delete-able user in every Frappe app?
Probably I’ll further break the code down to smaller services or serverless functions if project succeeds.
I’ve used mongodb along with ERPNext like following,
Case: add million serial and track warranty in ERPNext
Problem: takes 12+ hours to enter 1 million serials. System already has 20 million+ serials. Gets slower as more serial are added. (40CPU, 96GB RAM)
My solution: took out serials and warranty to mongodb, enter 1 million serials with validation under 5 sec.
Result: Customer happy with value. I get worth the effort.
Whatever Frappe framework is, it is a great tool! We can try using it to build many things! Microservices can be one of them.
Just the problem with me is, if I find something readymade in FOSS ecosystem, I’ll try not to reinvent it with frappe framework.
I’ll put up some posts. I’ll have to write them down, it takes time.
I agree. I also write code in other setups like React and GraphQL, Flask, Django, and Springboot (Java / SpringTools).
I like the way Frappe permits me to get things done. There is a saying that a system is worth more than the individual value of its parts.
Honestly, for me, it is the reverse for Frappe and ERPNext. Lumping up the parts into one system seems to devalue the individual component.
For instance, like you say, you can very easily spin up a web page in Frappe with the data from the partner .py code file, and you don’t need the user / permission part.
However, at the same time, in another application, the Frappe user permission system can provide powerful authentication / authorization.
Frappe and ERPNext components are powerful. But together, they bloat.
One of the motivations behind building Frappe the way it is, is that you don’t want to use any other system. Some people love working on different dev environments for different pieces, but that is massive context switching. Frappe was designed to be “battries included”. Think of it as some kind of extreme DRY. You can support 800+ DocTypes in ERPNext because of this mindset.
On the topic of having a NoSQL backend, it is tough but not unthinkable. Anyone suitably motivated should be able to pull it off.
I think Frappe should maintain frappe/ERPNext as it is. This is the base for any fork scenario.
As we can see in the benchless instance, docker based, etc.
So… we can expect to see the forks on the low-level (system, framework, db, etc), not only on features and modules 
I think it is nice to shake things up a bit, especially at the beginning of a new version (14.0).
Respectful discussion is a value that the Open Source community bring.
I think when you see how Kubernetes brings things together by having clearly defined boundaries for needed functionalities, one may realize that Frappe / ERPNext has built in so many elements of Kubernetes. Yet, the value of these elements become devalued because they are quite tightly coupled with the other elements.
I think what @revant_one observed (especially coming from a Kubernetes background), is that Frappe includes batteries like ID (Authentication and Authorization), Web, etc.
If these elements became distinct in Frappe, someone who wants just the powerful web (bootstrap + jinja context) would not need the ID part. Thus, Frappe becomes even lighter.
This totally makes sense, especially that microservices/Kubernetes/Docker things may be too complex for us the target audience.
However, I also think in the context of ERPNext the monolithism is being pushed to the extreme to the point of becoming a burden to some users. Why should a school make an update when the hotel module has changed? My point here is to move domains from the core and define a clear interface of how domains interact with the core. This hopefully can give domain-focused communities room to flourish independently?
I have just a few notes about the NoSQL / SQL topic:
I think it would be great to explore the different storage options in more detail and see how different solutions can be supported for different use cases. I think the new virtual doctype is definitely a step in the right direction.
With Virtual DocType, Frappe/ERPNext is slowly becoming DB agnostic. Good stuff ahead
Some live examples to create virtual doc type connected with JSON, stored within our outside network will be helpful for functional users. thx
Not exactly on network but the example handles JSON. Another interesting use case is Google sheets as storage
I’m very interested in a cut-down version of Frappe for use with backend services, and would be happy to contribute both time and money as needed.
We use ERPNext exclusively and are a small team, however we want to launch a product and use Frappe/ERPNext as the backend with hundreds and hopefully one day thousands of concurrent users. Hence our front-end or UI requirements can easily be handled with a singular monolithic architecture, our API requirements would be more suited to a microservice architecture. We can’t be the only ones.
Ideally I would love to see a version of Frappe/ERPNext or better yet a command like bench microservice that strips out the backend elements of the product (with apps) and can be deployed to AWS Lambda via the CDK (I suppose in a virtualenv), it would have no cache or queue, just API runtime and DB connectivity. That way those of us addicted to the DocType framework can build customised API frontends and share a database with the monolithic ERPNext.
From my point of view it solves a medium term need, but also long term it provides a stepping stone to splitting up ERPNext into modular components that would be well suited to microservice architecture. I’m not a fully-fledged convert to microservices, in fact for the majority of users (myself included) the existing structure is perfect. However in looking at this approach it does provide an opportunity to re-work ERPNext for each use-case, for example the education module just simply doesn’t need to be installed for most businesses, there are so many doctypes in our database with no rows and so many modules that are never used. Imagine how great ERPNext would be if it focused on the installation of a bare-bones featureset upon installation, with a catalog of additional modules (or bundles) that can be installed that encompass those elements you require. A choose-your-own-adventure open source ERP, a world beater!
Enough of me ranting (day-dreaming). If anyone would like to chat about putting together a microservice backend just reply below.
Frappe is just a python library, create virtual environment, install frappe and start using in any python project.
Use standard ui to build doctypes. Use the doctypes in any other app by importing frappe and initialising it.
Something like Serverless function using Frappe Framework
My thoughts exactly! You don’t have to install ERPNext… Just use Frappe
I think, much of this confusion stems from the fact that EASY-INSTALL automatically packages Frappe and ERPNext together.
The new installation steps using pip3 of python 3, enables the developer to install the python-level frappe-bench, and have a clearer understanding that you only need Frappe for app development. ERPNext itself is a Frappe app.