Thoughts on increasing Frappe Framework adoption

Current State

There are 5 websites in Alexa Top 1 million which use FF(Frappe Framework). There are 1300+ sites in total which are publicly accessible.

GitHub insights show 34K+ clones in the last 2 weeks.

Most of these clones might be due to CI, dev setup etc. There might be another 5K to 10K sites which are running on top of FF.

Improving FF discovery

Most of these users discover and use FF through ERPNext.

FF is bit hard to discover in Python ecosystem and the entry barrier is too high for anyone to get started with FF quickly.

I am just writing down some thoughts on this here. We can see how this discussion goes and take actions based on it.

• Publish FF to PyPI

PyPI has “framework” trove classifier. Clean up setup file and then publish every release to PyPI. We can even setup GitHub Action to automate this. This makes it easy to discover for people who are looking for frameworks.

Currently, by default bench init uses git clone and fetches develop branch. Bench should pip and fetch latest stable version of FF from PyPI.

This will also make it easier to track all the frappe apps. We can use https://libraries.io/ or other tools to track dependants.

Lowering entry barrier

• Reduce dependencies

Currently, FF has 70+ dependencies and many of them are optional dependencies.

Everyone doesn’t need dropbox or google auth or razorpay packages. So, classify the dependencies and update extras in setup file.

With this, users should be able to install “slim” or “full” dependencies as needed.

$ pip install frappeframework # installs only mandatory dependencies 
$ pip install frappeframework[full] # install all dependencies 
$ pip install frappeframework[payments] # install payment related dependencies. (Optional - Just to enable categories if needed)  

This needs some changes at bench too.

• Make redis/cache optional

Currently, caching is tightly integrated with FF. We need to setup a flag(?) or some mechanism to make cache optional so that users can plug in when required.

• Ability to re-use existing virtual environments

Creating virtual environments using venv or virtualenv is a standard practice in managing Python projects. Users should be able to install FF in an existing environment.

• Write/Make tutorials

Currently, we have a library tutorial for users who are getting started with FF. We need to make full length tutorials on how to build a real world application. I have started a tutorial called “How to build Twitter clone with FF”. It is in draft state. Will try to finish that up.

We need to make few other tutorials so that users can “see” what FF has to offer.

If you have any ideas on how to improve FF adoption, please share it here.

[nikkothari22]

We’ve used Frappe for a project management system built for a World Bank agency - and here are a few things that we encountered:

1. Documentation does not cover a lot of the hidden features in the framework - or at least doesn’t have enough tutorials. For example, Frappe supports Realtime listeners (like Firebase and Supabase, but way more advanced) - but the documentation does not cover a lot of use cases (eg: realtime chats/status).
2. The frontend tooling or documentation surrounding it is mostly jQuery based. I think Frappe supports Vue, but there’s not a lot of guides out there. We’re planning on using NextJS with Frappe for our enterprise software - and we are basically going to use it the way Frappe Cloud is built. With modern frontend tooling, Frappe could be the best tool that frontend devs use to make a full-stack application.
3. Moreover, the Frappe codebase is not well documented with JSDocs or Typescript. I think the developer experience would be absolutely insane if we get JSDocs or Typescript in the framework.

I am planning on creating some tutorials and libraries (already made Frappe JS SDK - https://github.com/nikkothari22/frappe-js-sdk) to help more devs adopt Frappe. I can also help integrate JSDocs/Typescript in the codebase starting with the most used frontend tools in the framework - just need a starting point for this. This would help me and my team a lot as well - since I need to onboard them to Frappe framework and they’ll get the documentation right in VSCode.

[gavindsouza]

This is something I’d written down around February 2021. Just a quick/rough note primarily for what I’ve wanted to / and am focussing on widely.

---

Increase Adoption of the Frappe Framework

to cultivate a strong dev community, making frappe more adaptable for all sizes of projects. making it the developer’s choice of framework for starting a new project.

what are the issues faced by existing devs?

1. frappe setups are very heavy

   • Even basic CRUD apps need to have socket, caching, hundreds of database tables due to existing stack
   • Very big memory footprint for even the smallest apps

2. complicated dependency requirements & inital setups

   • mariaDB is still hard to install. python versions are coming out faster than we can evidently adapt
   • other companies have growingly started using frappe docker for frappe based development which is expensive as it is for non linux systems. eg: finaxar has given their employees 16G windows laptops and dedicated 8G to docker vm. a heavy requirement like this is enough for the common devman to turn away from this

3. too much friction to get started

   • could be primarily attributed to bench init giving everyone latest frappe develop by default which is generally unstable
   • bugs that we’ve learnt to live with, but might seem hard problems to fix for new devs [like random reloads and refreshes that take ages, New button missing after creating new doctype (this is fixed)]
   • docs lying about something or missing info
   • missing onboarding for devs (try setting up a project with any mainstream framework and you’ll know what I’m talking about)
   • missing features for ease in development (hot reloads, for instance)

4. too many unknowns

   • can frappe do this? is it supposed to do this? what are the “known” bugs? what are the goals of the project?
   • simple but incomplete answer to this problem: documenting everything. but things aren’t as simple as that. even documented content is all for naught without proper structure. the documentation needs to be designed from the POV of a non frappe dev.
   • we dont follow conventions for a lot of things. starting from ‘tabs over spaces’, going over to the bench structure, vendoring apps and lack of packaging and how our version tags and releases work. these things certainly do make the slope much steeper for getting in.

5. does this minor version update break my apps?

   • we break APIs and change things that have been happening from ages in the blink of an eye. Recent example, being having to whitelist controller methods which is going to be a part of the next “minor” release?
   • missing deprecation warnings (which other projects give WAY ahead of time so that devs have enough time to prepare)
   • missing migration path for frappe apps. How to make your app compatible with v14.x.x or something more specific like migration path from v12.x.x to v13.x.x. These things make it easier to develop apps and make things less chaotic…makes it fun to use the framework, and your users will be more appreciative. ref: Django Official docs: How to upgrade?

how simple should it be to use frappe?

pip install frappe==13.1.0

just this command should be enough. it should download its assets and setup the bench CLI on your machine. You shouldn’t have to worry about database setups, if its required, could be managed by bench. If you want SQLite, use that. No extra setup needed.

All frameworks have basic hello world Then db setup They sockets Then cache Then workers Then more complex things For Frappe you just need the complex thing installed to start

^ Feedback from a community Frappe dev

dx++ for frappe

this would require

1. easier entry point to frappe development
2. smoother onboarding for frappe devs
3. speed up development of building frappe apps
4. modular frappe setups
5. better resources for help
6. better developer experience

this would lead to

1. more number of active frappe projects/apps
2. entry point to marketplace

realised steps

1. better tracking for frappe installs?
   • track # of people using frappe for development/production envs
   • current available metrics of repo clones of frappe, bench and downloads from PyPI, docker hub image pull counts dont make sense since there are usually duplicated clones and CI installs
2. easier getting started with frappe. reduce time to setup frappe
   • easier setup scripts? one curl to setup everything (docker based setup)
   • better FAQs and docs resources
   • cheaper costs for getting started
   • modular setups?
     • setup frappe-socket, frappe-cache only if your apps need it!
     • install frappe modules on the fly as needed. not while creating new sites. smaller site footprints
3. cheaper setup reqs & faster/less comp exp assets builds
   • install only whats needed?
   • builds using esbuild
4. standardized, stable CLI
   • fully tested
   • fully documented
5. better documentation
   • easier entry points for integrating external tools with frappe
   • ive been reading documentations of other frameworks over the past couple of years. developed a good enough idea about the missing features
6. app/in-site customizations management
   • build systems that give app developers more control over their apps. eg: AppConfig
   • export web pages as static files in dev mode
7. database
   • plug any database you want natively!
   • no db/site setups
   • beautiful ORM with query builder
8. full circle in getting all frappe products together
   • the CLI that onboards you to frappe, has options for publishing your app to the marketplace
   • manage deployments of all your apps. develop locally and push to production on FC

the minor milestones of this project would be each sub-step in the above-mentioned steps. major would be the titled steps.