For a while I have been thinking to make a standalone cross platform app for the Point-of-Sale, and the reasons are:
- For offline: efficient caching and secure storage using SQLlite instead of browser local cache where the user can temper with (and if you are wondering then yes its easy to prevent a user from uninstalling the app on Android, iOS, windows…etc).
- Allow to directly to interact with connected devices link thermal printer without annoying browser boxes
- Better user experience especially if the App is native
Through my search to find the best candidate platform to develop such app is to use React Native for the following reasons:
- The app compiles to native iOS and Android apps
- It also compiles to native Mac and Windows Apps (Still not added to the official Microsoft MacOS)
I started this topic to gauge the interest in the community, I also wanna hear from the frappe team and foundation members if we pursue such development would you accept it into the core (mainly migrating the POS code to React)?
@rohit_w @netchampfaris sorry to tag but I just wanna pick your brain. do you think this approach is the best to easily provide cross platform POS app?
Also I’m planing to hire a developer to migrate the current POS to ReactJ as first step to allow reusabule components before start working on ReactNative for the cross platform apps, would you accept a pull request in this case?
Creating a seperate POS local app that communicates with frappe/ERPNext is an interesting idea. All of the points that you listed are really valid. A few questions:
1: Any reason to pick React Native vs Electron?
2: Wouldn’t a standalone app be able to transparently communicate with no (or minimal) changes to the main frappe/ERPNext branch via REST?
I personally prefer locally installed apps with web/network sync ability over purely cloud hosted apps. Thats just my preference though and is dictated by my clients limited requirements. Please us informed on your progress.
@System19 for your questions
1- Electron is more of like flash for desktops. but react natives compiles to platform specific natively. Also on react native beside covering the desktop, you also can get the mobile apps for the iOS and Android all for almost the same code base. Here is a good read Building cross-platform user interfaces in 2017
2- yes it can be done without changing the current POS app; however, my suggestion for migrating the POS app to react is also to somehow reuse the code between the web pos and the desktop apps so you don’t maintain to completely different structures and maintaining it will be much easier. This and also the fact the pos in ERPnext is written directly in js and not using the doctype structure so migrating it to react shouldn’t be trouble
This is my humble opinion and my limited understanding, thats why I open this topic to see different point of views or someone can correct me if my understanding is wrong
Ok I see that frappe team going to introduce ERPNEXT Desktop which is based on electron, so I will close this topic for now until gets more details
@ganas This is interesting. It is true that if you want secure offline apps, native is the way to go.
So this can live as a separate app that connects to erpnext via REST, and it shouldn’t go in the core.
thanks @netchampfaris ok let me rephrase my question, if we contribute iOS and Android apps for the POS built on React native (right now considering Electrode Native as platform), is it ok then later to also start migrating the POS component in ERpnext web to react in order to maximize code reusability and lower thea headache of maintaining the web pos and the apps. It is not a big deal I’m just wondering if this is a possibility
BTW react native is just one suggested framework. Also I’m considering NativeScript which will make the job of adapting POS into an app much easier (but it is only for iOS and Android which for me personally is enough since I don’t care about desktop apps) so if you know a different framework that is better suited then let me know
Yes, we should maximise code reusability, since we already have a new implementation of POS, we don’t want to do that in the future.
I’ve not followed offline POS story. But I guess you have worked with HTML5 offline abilities. There are several databases (for example NeDB, PouchDB…) abstracting HTML5 features like IndexedDB. But main problem will always be synchronization and conflict resolution…
@Yakulu I investigated the possibility of using such structure
PouchDB at the Client synchronizes with CouchDB at the server (since syncing is what PouchDB is best for) then CouchDB is connected with MariaDB
PouchDB<=> CouchDB<=> MariaDB
However, such structure is extremely complicated since you will be syncing between nonSSL and SQL data base. However, we can enable easier more efficient synchronization using SQLite and thats where I’m doing my research right now
You have simpler infrastructure with PouchDB server-side (as ERPNext already has Node dependencies). That said, I agree with you, this is a little complex in order to achieve offline and sync. Too bad that WebSQL database was abandoned because it was lacking multiple implementations…
PouchDB is meant for client side only and it can only sync with CouchDB, so those type of offline enabling model are good for system that already use nonSQL structure. For us, the natural way is to use SQLlite which is will supported in both iOS and Android. Also there are some works that manage synchronization SQLite with MySQL.
Pouch is server side too but yes, I agree, SQLite is much more close to current MariaDB schema. Not sure about synchronization simplicity because there are still two different engines with no included sync and conflict management between them (but there may be open source libraries to help here). Will be interested to see how you will deal with that (and how have done Frappé team with current offline POS). Good luck !
Keep in mind that for the POS there is no much of two way synchronizations. you are basically caching many tables that are not changing at the POS app like item_data, price_list_data, pricing_rules, serial_no_data, item_groups…etc as they will just be used for validating the business logic
when the POS is online you are just going to push back api calles to create sales invoices, added new customers in the system
and here is the local storage caching in the current implementation
There are so many new frameworks, platforms and stacks today it makes my head spin.
I didn’t know that React Native was heading towards supporting desktops.
I agree that compiling to native should produce faster, smaller apps. (Not sure about more secure, but I guess the run time is another attack vector?).
The ideal platform for most POS deployments is a touch screen device so iOS and Android are a perfect fit. Although I do see a lot of shops using touch enabled windows devices for POS though.
An electron OSX desktop app starts at about 50MB just for the runtime. After that it s pretty efficient though. As for speed electron has improved a lot over the year. Atom editor is a good example.
DB sync and conflict resolution is a major. For a lot of retail situations the only conflicts I can think of are the number of items still in stock? There is a popular POS cloud app called vend. It might be worth signing up for 30 day trail and see what DB sync method they use?
You may add Kivy to the list, Python touch friendly framework which can run on desktops and mobile devices. About Electron / Flash comparison, not sure about that. Electron is mostly packaged Chrome browser alongside NodeJS, not a specific runtime with its own stack.