Skip to content

Latest commit

 

History

History
300 lines (234 loc) · 7.39 KB

README.md

File metadata and controls

300 lines (234 loc) · 7.39 KB
Raw

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