Looking for Architectural Advice

#1

I’m developing a point-of-sale (POS) system as a personal project during my spare time.

For the front end, I’ve chosen Deku and Hyrule, and so far, the experience has been excellent albeit a bit rough. I keep going back to Conal Elliot’s brilliant Rick Rubin-like talks about FRP. It seems to be the perfect UX layer for FP.

On the data side, I’ve prototyped a switchable JSON/HTTP API, and I feel confident that it’s perhaps solid enough to start considering the back-end architecture.

Initially, I aspired to keep the entire stack in Purescript, embracing its type safety and elegance. However, when I compare it to frameworks like Servant in Haskell, it becomes clear that Node.js’s limitations could hinder the scalability and performance of a back-end built entirely in Purescript.

This has led me to consider alternatives: how feasible would it be to run a PostgreSQL database with Purescript Chez Scheme in the future? Could the Chez Scheme back end—recently introduced to Purescript—offer a viable escape from Node.js’s constraints? The thought of leveraging Chez Scheme for the back end is exciting, as it opens up new possibilities for performance and architecture.

I wonder if the adoption of this backend by a significant enterprise could drive the development of critical tools, like a robust PostgreSQL module. Languages like Rust and Go are gaining traction, but it feels like the broader developer community hasn’t yet realized the potential of Purescript on the Chez Scheme backend. If more people understood the opportunities here, it could lead to a renaissance for Purescript, enabling truly end-to-end solutions without compromise.

The underlying question I keep coming back to is: when will the community and industry recognize (and leverage) the extraordinary performance and efficiency of the Chez Scheme backend? It rivals anything currently available, yet Purescript seems to have fallen off the radar for many developers. I believe this could be the spark to reignite interest in the language—and finally make my vision of a fully Purescript stack a reality.

So what do you all recommend for a SUPER fast and robust back end?

Right now, my plan is to go with PostgreSQL and Servant (glued together with Nix flakes) but I’d love to hear some opinions of those that have trodden this path for a considerable distance.
Ps. I am open to literally ANY suggestion. I’ve even considered Elixir and Erlang.

#2

What leads you to believe that a node backend wouldn’t be performant enough? You seem to be taking it as a given, but I’m not sure what your actual constraints are. Is raw performance a requirement, or just scalability (eg. Erlang as an alternative?).

I think a robust Chez Scheme backend would be great, but AFAIK it still seems to be what I’d consider a pre-alpha state, and I’m not aware of any actual programs written in it, or anyone relying on it for “production”. The only “production” backends I’m aware of are JS and Erlang.

Otherwise, if you like Servant, I’d say just use Haskell!

1 Like
#3

I don’t necessarily think it won’t be performant enough for my current use-case. Use-cases tend to expand into infinity though. I’m a guilty of excessive “feature creep” in my work. So (for better or worse) I’m often concerned with finding the Ferrari of programming languages that is also amphibious and flies and makes me dinner. :wink:

Frankly though, I just would possibly want the option to take advantage of the power of FP when leveraged toward parallelism and (from my current understanding unless I’m missing something) that just isn’t possible with node.

Anyway, I’ve started learning Servant.

Thanks so much for the reply, Nate! Your feedback and advice is always wise. :blush:

I’m sure I’m focused on running before I can even walk.

#4

TBH I think GHC’s runtime is the only production runtime to take advantage of this from a purity perspective, though I’m not sure how much usage the “spark” system gets in the wild. It’s neat to know that pure computations can be scheduled in parallel automatically, but I think in practice traditional parallelism techniques (eg. work stealing tasks) dominate even in GHC land.

FWIW, I have yet to see convincing evidence that single threaded PS-on-Chez is faster in practice than V8. However it does have true shared memory multi-threading (vs Node’s IPC workers).

1 Like
#5

It seems there is a prejudice (probably not completely ungrounded) that Node.js is slow, unreliable and generally not suitable for “serious” projects/tasks. There were stories that people migrated from node.js based Purescript to Haskell b/c of performance (and maybe other) reasons.

1 Like