I want to learn ELM (not started yet) while simultaneously producing something of value in the form of an open-source project. I plan to read this korban.net elm book in parallel to a simple project.
A local coffee shop has asked for a very basic POS. They literally need their 2-3 waiters/waitresses to tap on ordered items on their phones / ipads and it would generate an order.
This project, EpPos, is good enough and is what I have installed to start with.
One behavioural attribute I am contemplating changing is, it requires a central API running on the local server to do the calculations. It is a solid approach but requires an always on box in a cupboard and if that goes down, so does the system.
I was thinking about whether it is possible to have the entire system running locally in a web app.
The way I am thinking, 2 or 3 devices with my POS web app installed called interact to manage the current value of the till register. All calculations would be complete on the device (simple additions and subtractions).
I think this kind of distributed system would be nice but would interfere with my learning. For starters I am going to keep to a Django REST API as a centralised backend because I know it (later I would like to learn more about whether GraphQL could solve some problems I might have with REST) and I could inherit from the EpPos project linked to above, except write an Elm frontend for it.
Do you think this is a good tinkering project to do in Elm?
Any feedback and discussion about the potential pitfalls in my idea are very much welcome. I am not married to any ideas.
Sounds good to me, maybe also do the frontend with https://package.elm-lang.org/packages/mdgriffith/elm-ui/latest/ to keep everything in the elm world?
Elm is THE language for going into front-end programming when you are leaving server-side rendering behind. To me, the type-safeness and immutable, centralised model, has been the major helpers in writing robust and bug-free code.
Of course you could store the order locally on the device and send it over to the central server when available. I believe that is the idea of a service-worker but this is nothing I know about, although I’d really like to know.
If by “till register” you mean the live finances of the shop you will most definitely have to ensure all transactions are ACID so that outages or race conditions don’t leave the money in an inconsistent state. Elm’s excellent advice to have only “one source of truth” also applies to multiple parallel apps on different devices: another reason to leave the till calculations on the server.
Alternatively you could explore using something like a blockchain to maintain multiple parallel truths that eventually become the same truth?
This is a repo of some examples of Elm-JS interop: https://github.com/MattCheely/elm-port-examples . It may help if you want to see what the code would be like or need some similar functionality.
But I agree with perty that you can get rid of HTML and CSS entirely by using Elm (especially with Elm-UI package https://package.elm-lang.org/packages/mdgriffith/elm-ui/latest/).
Yeah, I was thinking along lines of local blockchain. But that is quite ambitious. I will complete a centralised server implemention first before I attempt a decentralized one.
So you’d do peer-to-peer networking using WebRTC? That’ll definitely require JS, and seems pretty complicated. There’s also no real safe way to store data in a browser (that survives “clearing cookies”).
I think the simplest option when you don’t want to worry about the backend is probably a BaaS like Firebase. With Firebase you can get realtime messaging too, though you’ll have to install the Firebase JS client and connect it to Elm with ports.
I would definitely not want it online though. Internet can be flaky out where I live (rural South Africa, place called Kosi Bay)
Looks like a local backend server is the obvious choice for simplicity!
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.