Skip to content

Southern-Exposure-Seed-Exchange/Order-Manager-Prototypes

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

SESE Order Manager Prototypes

This repository contains very rough prototypes of various web frontends and backends for an ERP/Order Manager. Prototypes for Django Rest Framework, Ember.js, Elm, Purescript Pux, Servant, Spock & Yesod exist. A Purescript Halogen prototype is planned, and others may be included.

Implemented

  • CRUD Categories/Products
  • Listing Product Variants.

Todo?

If we want to get more in-depth with these, maybe something like this:

  • Create/Update/Delete/View Products/Variants
  • CRU Customers
  • CR Inventory
  • CR Orders

Backends

sudo pacman -S ghc alex happy cabal-install stack

Django

cd django
pip install -r requirements
createdb om-django
./manage.py migrate
./manage.py runserver 0.0.0.0:3000

Servant

cd servant
createdb om-servant
make

Spock

cd spock
make

Yesod

cabal install yesod-bin

cd yesod
cabal sandbox init
cabal install --only-dependencies
yesod devel

Frontends

sudo pacman -S npm bower

Elm

cd elm
npm i -g elm
npm i
npm run dev

Test Runner:

npm i -g elm-test
npm run -s test-runner

Ember

cd ember
npm install
bower install
ember serve --proxy 'http://localhost:3000'

Purescript Pux

cd pux
bower i
npm i
npm run dev

Purescript Halogen

cd halogen
bower i
npm i
npm run watch
open dist/index.html

Vue

cd vue
npm install
npm run dev

Performance

Backends

Django

  • Cat/Prod/Variants import takes ~2 seconds.
$ siege http://localhost:3000/products/ -c 20 -t 60s -b

Lifting the server siege...
Transactions:		         378 hits
Availability:		      100.00 %
Elapsed time:		       59.09 secs
Data transferred:	      176.84 MB
Response time:		        3.05 secs
Transaction rate:	        6.40 trans/sec
Throughput:		        2.99 MB/sec
Concurrency:		       19.54
Successful transactions:         378
Failed transactions:	           0
Longest transaction:	        5.40
Shortest transaction:	        1.25

Servant

  • Cat/Prod/Variants import takes 0.6 seconds
$ siege http://localhost:3000/products/ -c 20 -t 60s -b

Lifting the server siege...
Transactions:		        1082 hits
Availability:		      100.00 %
Elapsed time:		       59.64 secs
Data transferred:	      625.14 MB
Response time:		        1.09 secs
Transaction rate:	       18.14 trans/sec
Throughput:		       10.48 MB/sec
Concurrency:		       19.74
Successful transactions:        1082
Failed transactions:	           0
Longest transaction:	        4.07
Shortest transaction:	        0.36

Frontends

Ember

  • Displaying the Products Page with a table of 1441 Product rows takes 9.8s of scripting time & 0.5s of rendering time.
  • Un-hiding 1855 Variants on the Products Page takes 2.9s of scripting time & 0.4s of rendering time.
  • Hiding 1855 Variants on the Products Page takes 1.1s of scripting time & 0.1s of rendering time.
  • Loading directly into a Product Details Page takes 1.7s of scripting time.

Elm

  • Displaying the Products Page with a table of 1441 Product rows takes 0.5s of scripting time & 0.1s of rendering time.
  • Un-hiding 1855 Variants on the Products Page takes 0.4s of scripting time & 0.3s of rendering time.
  • Hiding 1855 Variants on the Products Page takes 0.3s of scripting time & 0.2s of rendering time.
  • Loading directly into a Product Details Page takes 0.1s of scripting time.

Retrospective

After building multiple prototypes, my favorite combination is a Servant backend with Elm or Purescript as the frontend. Elm would be way easier than Purescript for people not familiar with statically typed, functional programming languages - but Purescript provides additional ways of abstracting and reducing boilerplate code. But both are so much better than classical JS frameworks that either seem worth it. Servant/Haskell gives me a lot more confidence in the backend code, and it's easier to understand the API architecture versus Django. The same applies to Elm/Purescript, you can look at the top-level calls and follow the messages/views down to the actual code, while Ember feels more like a scavengar hunt.

The purescript-pux library is basically The Elm Architecture in Purescript. In both, there's some boiler plate of hooking up nested mesages, updates and views but it feels much more organized & learnable. It's like learning one pattern and then repeating it at different scales.

Ember and Django hook up very well together, since both have JSON-API support. With other options, we'd have to hookup our own api schema, error handling, and pagination.

Ember

Pros

  • Easy to learn
  • Plain JS
  • Lots of libraries, large community

Cons

  • Hard to debug
  • Slow
  • Hard to determine best practices or performance improvements
  • Hard to reason about

Elm

Pros

  • Statically typed, functional
  • Obvious/enforced best practices(The Elm Architecture) - less freedom to do whatever you want but easier to understand & write
  • Elm Format automatically makes code super legible & a standard style
  • Performance improvements are easy & don't affect program architecture
  • Semantic Versioning of dependencies keeps upgrades easy & builds from breaking
  • Easy integration w/ Websockets
  • Fast
  • Awesome Compiler Messages
  • Much more maintainable, refactoring is easy & guided by compiler

Cons

  • Small but growing community
  • Interacting w/ JS is a bigger process but safer.
  • Possible breaking changes in future
  • Lack of typeclasses adds some boilerplate code
  • Most language development by single person.
  • Might have to write some 3rd-party integrations ourself(e.g., if we want to show stripe payments)

Purescript

Pros

  • Statically typed, functional
  • Can replicate Elm Architecture, but is not limited to it
  • Syntax almost identical to Haskell, tougher than Elm for webdevs but easy for Haskellers
  • Has typeclasses and more powerful abstractions than Elm
  • Language development by group larger than Elm's
  • Much more maintainable, refactoring is easy & guided by compiler

Cons

  • Small community
  • Somewhat cryptic compiler messages
  • Easy interactions with JS
  • Dependency versioning is not great, bower caused some pain points
  • Possible breaking changes in future
  • Might have to write some 3rd-party integrations ourself(e.g., if we want to show stripe payments)

Django

Pros

  • Easy to learn, easy to write
  • Lots of libraries, easy to interact w/ 3rd party services
  • Lots of Django users
  • Django-Rest-Framework has cool features like a web frontend with a built in API client.

Cons

  • Requires extra work for websockets(Django Channels)
  • Slow performance
  • Needs lots and lots of tests for program verification
  • Harder to completely trust refactorings without many tests
  • No type checking or compile-time guarantees - relies more on documentation & programmer responsibility

Servant

Pros

  • Statically typed, functional
  • Way faster than Django(~6x)
  • Type system/classes allow easy, uncomplicated abstractions
  • Can automatically generate API clients
  • Compiler is better than Purescript but not as awesome as Elm's
  • Much more maintainable, refactoring is easy & guided by compiler
  • Library to allow subscriptions to resource updates via websockets
  • Can integrate w/ Swagger, but not as simple as Django-Rest-Framework
  • Integrated & Type-Checked API Docs - invalid API docs won't compile!

Cons

  • Not as many libraries as Django/Python, may have to write a couple ourselves
  • Smaller community
  • Harder to learn