Project Management Software Built with Elm and Lamdera

[john_s]

I am developing Agile-native project management software built almost entirely with Elm (about 150 lines of JavaScript for Web Components) on both the front and back end with Lamdera as the platform. This post really has two audiences and two purposes:

1. I want to share for those looking for another Lamdera and Elm success story - especially people new to Elm or returning after a break.
2. I am also looking to see if anyone in this community would be interested in trying this out or knows someone else who is. I apologize for the shameless self-promotion.

Elm and Lamdera: Highly productive pairing

Context

• The project is around 69K LoC excluding unit tests (and since it is Lamdera there are presently no manually written Json Encoders/Decoders). Obviously LoC is a weak metric but it gives a ballpark representation of size/complexity.
• It features a Kanban board, drag/drop dependency visualizer, and a lot of custom visualizations.
• The application is highly collaborative thanks to Lamdera: changes appear immediately, you can see when someone else is editing, and during a Scrum event the team can see what the facilitator is looking at.

Nice attributes

All of the usual Elm stuff:

• The project has never thrown a run-time error.
• Very few bugs. Bugs are mostly design oversights / mistakes.
• Elm on the front and back end so I never need to switch language. Infrastructure handled by Lamdera so I can pretty much stay in the realm of domain and feature modeling. This helps me keep my mental flow states.
• No fighting with npm packages or versions.
• No fighting with an enormous fragmented tool chain.
• Lots of safe and descriptive data types. With opaque types and some phantom type markers in the domain layer the codebase is type safe and declarative / descriptive. The type system tells you exactly what a thing means, what state transitions are allowed, and obviously there are no hidden side effects.

The “success” is just how easy everything has been. I am grateful to the entire Elm community.

Early Customers

The software is ready to use today and I am looking for early customers to help shape where it goes next. Please do note that the software assumes a team following Agile principles and very likely Scrum or Scrumban flavored process.

• Product Page
• Speed run video - Please note that the video is of captures from about 5 weeks ago. The application looks considerably better today. I’ve got an automated system for screen grabs but not videos and I just don’t have time to keep recapturing videos.

If you know an engineering leader, product owner, Scrum master, founder, or team lead who is frustrated with their current software, I would appreciate if you could point them in my direction.

[ni-ko-o-kin]

This looks like a real cool product! Congrats!

1. Do you use Lamderas built in storage solution? Are complex database queries fast enough? Do you have computed live data?
2. How many active users can one Lamdera instance handle?
3. Did you write the “critical path” node editor yourself, is it open source?

[john_s]

Thank you for both the kind words and the questions!

A bit of context for the architectural choices: I have been optimizing for correctness, extensibility, and the ability to change features quickly.

TL;DR for the performance related questions: The product is interactive, but not in the game-server sense, on the order of one message per user every few seconds, not tens per second, so it benefits from Web Sockets but doesn’t have heavy message load requirements. The domain also has natural moments when it makes sense to shuffle information between hot working memory and cheaper / slower / larger storage. I got lucky that my application requirements naturally align with Lamdera. I have not had to solve a real scaling problem yet. I would be glad to have that problem.

Answering your questions out of order to address shorter ones first. Also, really fast, I have bulleted lists in this response… I hate that I have to say this but I have been heavily using bulleted lists for 20 years. This was not an AI written message.

Did you write the “critical path” node editor yourself, is it open source?

I did write it. It can (and probably should) become open source. There are probably half a dozen candidate packages: there is a pure, view-agnostic modeling module that turns dependencies into waves and computed edges, the view and interaction layer for the nodes, and other stuff. There are also some elm-review rules that could be published. I have not polished any of that for publishing because I am focused on the product. When I get a moment to breathe I will publish but I don’t know when that will be. Sorry!

How many active users can one Lamdera instance handle?

There are a few different facets.

• Connection count for Web Sockets is higher than I will need.
• Whether the backend can keep up is a function of average messages per second per user, size of the message, intensity and duration of bursts, and the complexity of message handlers. I have not load-tested this with production traffic. Lamdera’s Is it for me? page implies that on the order of 1000 requests/second is in bounds. Again, it depends on many factors. I have been paying attention to the distribution of message size and computational complexity and have yet to see anything that raises a concern.

On the per-user message rate: a worst case of about one message per second per user, and in practice closer to one every few seconds.

• Most edits are relatively infrequent. A Select sends immediately; a text field sends when the user leaves the field or finishes editing that entity. Even a text field that sends an update without a tab out remains relatively infrequent if debounced to two seconds.
• Drag/drop on the Kanban board or backlog sends a message when the operation starts and when it completes. It does not stream coordinates while the pointer is moving.

A single instance should be comfortable with hundreds of concurrent users.

Do you use Lamdera’s built in storage solution?

The working set lives in the backend model. Closed periods and aged backlog items are natural domain gates for moving cooler data to cheaper storage and loading it on demand. That path is designed, but I haven’t need to build it yet.

Are complex database queries fast enough?

They have been, because the domain lines up really well with a document-style representation. There is not a lot of pivoting along different dimensions or a need to spin data on children of roots.

Do you have computed live data?

Almost everything is calculated (not stored) from the one source of truth as needed. There is very little performance motivated de-normalization.

That said, when a Sprint (Scrum) or Cadence (Scrumban) completes, the software writes a statistical snapshot because completed work will move to external storage. Forecasting, the Monte Carlo simulation, and overview reports read those simplified snapshots. For the current open period, live data is converted into the same report shape and combined with the historical snapshots.

There are definitive moments in time - again compatible with the domain - when it could make sense to take other such snap-shots but there hasn’t been a need and I prefer not to store derivable data until there is significant motivation.