Finalising the spec

[saurabhnanda]

While writing up the JSON API spec based on the original spec outline, I realised that I was biting off more than what could be chewed. Therefore this is to discuss and finalise a spec that covers all functional aspects, allows us to discover a "minimum viable webapp architecture", and requires minimal development effort.

[saurabhnanda]

@sudhirvkumar what do you think of https://github.com/vacationlabs/haskell-webapps/blob/26474934fd364237f37f50bb8e35f0b9ab2ade8b/SPEC.md#things-to-cover-in-the-spec Can anything be added to it?

[saurabhnanda]

Planning to implement only the endpoints documented here

Stuff that can be added:

• PDF generation: The classic use-case is generating a PDF invoice, but given that we're limited ourselves only to products (and not extending to orders), shall we just generate a PDF flyer of product details?
• More details on testing related requirements
• many:many associations: any ideas on how a realistic case for many:many associations can be built with minimal effort?

[sudhirvkumar]

@saurabhnanda

Before I make comments on the SPEC document. I just want to collect my thoughts and also share them with you. So that you know my perspective. I believe I will be helpful only partially in helping draft the spec.

Why Haskell and PureScript?

• Pure Functions
• Typed
• Immutability
• Type Classes -> Simplicity
• Managed Side Effects
• Better error handling

I want to use Haskell only for a part of the Applications. I have no desire to go end-to-end with Haskell. like using GHCJS, will go with PureScript instead. Use Ruby where it makes sense.

How I plan to use Haskell?

• JSON REST API
• DB communication
• Websocket
• Business Logic
• Workers (Some of the workers, mostly involving data processing, talking to other services like emailing, oauth etc..)

Where I am not planning to use Haskell?

• PDF generation (Will use Ruby Worker which will wait for a job from queue with JSON data and a pre-defined template to generate PDFs)
• Other situations where Haskell lacks Mature Libraries.

Where I am planning to use PureScript?

• Front End
• Electron Apps
• React Native Mobile Apps

Will avoid (for now...) PureScript in these cases

• Node.js Apps (Will relook at this use case in a later date, mainly because of the huge ecosystem of javascript libraries)

If at all... I need (makes my life easy?) then will use them as Micro Services for some parts of the App!

I believe with Pure Functions, Types, Type Classes, Monads, Monad Transformers... We will be able to avoid at least 80-90% of the issues we have been having with RoR.

Mainly..

• Reliability
• Maintainability
• Debugging (its horrible as we have to jump from one file to another to even understand the logic because data can be mutated anywhere...)

So I am not really looking to use Type System for anything else other than taking care of Logic, Input and Output for now.

I am going to continue to depend on Team Collaboration, Processes, Unit Tests, Refactoring and Code Review to build Applications.

[saurabhnanda]

@sudhirvkumar have you already started working with Purescript or is that still in research phase? How similar is Purescript syntax to Haskell? Can Purescript integrate with the jQuery widget eco-system out there? Or are you planning to write Purescript with React? In which case, how mature are the React UI widget libraries?

Btw, I'm not a big believer of micro-services unless you hit true "web scale". In the end it's a tradeoff, which doesn't have a single correct answer. Would you rather deal with orchestrating micro-services in production and dealing with a distributed system OR would you put extra effort in closing the library gap in Haskell?

[sudhirvkumar]

@saurabhnanda

We have already started working with PureScript and we are using PureScript Pux (https://github.com/alexmingoia/purescript-pux).

PureScript is very close to Haskell. Its not Lazy though!

https://github.com/purescript/purescript/wiki/Differences-from-Haskell

We are using React and React has a lot of components and with PureScript we can use jQuery widgets too. There are a lot of components for React too!

https://github.com/brillout/awesome-react-components

One thing is... we need to understand how Virtual DOM works, so that debugging and building libraries is easier.

Microservices are a no brainer when we are using Haskell.

1. We define REST endpoint
2. We define the handler
3. We compose the endpoints and handlers to create the server

So if we separate a few endpoints and re-use them then we will be able to scale parts of the app horizontally. Also use different databases for parts of the App!

Anyway, when we use Haskell and Servant. We will always find it easy to split them into micro services in the later stages of development. So I wouldn't worry too much right now. Docker/CoreOS/rkt makes it easy to manage all the services too.

[sudhirvkumar]

Would you rather deal with orchestrating micro-services in production and dealing with a distributed system OR would you put extra effort in closing the library gap in Haskell?

As things are, we are cool with the libraries which are available for now. Will work on other libraries later and as and when its required.

Micro Services makes good sense for my Product and Services!

[sudhirvkumar]

@saurabhnanda

I am having second thoughts about using Tests vs Type System to enforce correctness.

I am more concerned about being able to jump right into the projects along with the team and tests made more sense then.... Now... I am thinking about Types and Compiler / Development time guarantees.

So I am going to spend some time today to learn. If you already have some resources then please do share.