Announcing Lamdera Open Alpha

Show and Tell
1

After almost three years of design and development, I’m excited to announce the Lamdera Open Alpha!

What is Lamdera?

Developers have to deal with a lot of incidental complexity when building full-stack applications: bundling and deploying apps, serialising and deserialising data, handling network transports, interacting with databases, migrations, and so on. All this “glue code” costs development time, isn’t type-safe and increases the risk of bugs.

Lamdera’s goal is to empower you to write only the code that matters for the application logic of what you’re building; not by hiding complexity, but by removing it.

Lamdera is a type-safe full-stack web-app platform for Elm.

Hosting, deployments, migrations, networking, encoders/decoders and persistent storage are handled by Lamdera, so you can focus on your application logic, not glue code. I originally announced Lamdera in my keynote “Elm as a service” (40min) at Elm Europe 2019.

Lamdera also has a type-safe migrations system called Evergreen, which combined with the above features means new app deployments will live-reload for all connected clients while preserving state. I spoke about “Evergreen Migrations” (20min) at Elm Europe in 2018.

Lamdera Open Alpha

The Alpha is intended for Elm enthusiasts, keen to try a vision of “glue-less” full-stack web development, with an appetite for the bleeding edge!

The Alpha is not yet suitable for production use cases! It is for exploration and experimentation.

You can sign up here.

A huge thank you to all the people who have helped during the private Alpha and even before!

Why you shouldn’t use Lamdera

Lots of projects these days seem to advertise “Get started in just 3 nanoseconds!” but I don’t often see “Also, don’t waste your time if these pitfalls matter to you!” – I’m often left to decipher this myself.

Someone would eventually spend time writing a blog post; “Why you shouldn’t use Lamdera”.

So instead I’ve outlined why you shouldn’t use Lamdera, which you might want to read before going any further.

What people have built with Lamdera so far

Sometimes seeing is believing! Here is a small selection of Lamdera apps people have built so far. Some have generously shared their source code too!

These apps are written entirely in Elm, and all showcase how Lamdera abstracts away concerns around networking and persistence of data, enabling developers to focus on application logic, not glue code.

The Best Color

Martin built a fun game where people can fight over the best color, for the glorious right to background color domination… until someone disagrees!

try: the-best-color.lamdera.app, source: link

Game

Simon built a game called… “Game”. It’s a work-in-progress multiplayer world, where you can run your avatar around and chat with other players. It also has very satisfying graphics!

try: game.lamdera.app, source: link

Notes App

Jim built a searchable stash for your random notes. It supports Markdown, filtering notes by title, tags, full text, active links to the most-used tags, and even exports to JSON!

A special thanks to Jim for being the longest helping Alpha tester (almost a year!) and graciously suffering more data resets than anyone else!

try: notes.lamdera.app, source: link

Big Two Card Game

Ed built an online version of Big 2, a card game of Chinese origin. Find another 3 people, make a room, and give it a go!

Ed commented:

I wanted to make this game to play with friends during lockdown, but I didn’t have time to write the Elm frontend plus a separate backend and all the glue code. Lamdera made it really easy to get from idea to game in a few hours.

try: beat-the-big-two.lamdera.app

Planning Poker App

Egor built an app for doing planning poker estimates with his distributed engineering team.

They have been using it at work, and I’m told his team thinks it’s cool.

Egor commented:

I think it was quicker to write this app rather than search for alternatives if they exist.

try: plan-or-poker.lamdera.app, source: link

High-score Mogee

Andrey originally built Mogee, a WebGL platformer that fits into a 64x64px screen. I wanted to see if I could port it to Lamdera and give it a persistent high score leaderboard function!

Predictably, Andrey holds the high score title. Maybe someone can beat him though?

try: mogee.lamdera.app, source: link

Lamdera Dashboard

In the spirit of “eat your own dog food”, as much as possible of Lamdera is built on Lamdera.

The Lamdera dashboard features basic user accounts + auth system, emails via send-grid, and manages Lamdera app creation.

Getting started

The best way to get started is to signup and check out the documentation.

I hope Lamdera inspires you to build something you wouldn’t have built otherwise!

65 Likes
2

Yes! I was waiting for this to drop. I’ve written a few games with Jsonstore as a backend. Sadly Jsonstore got discontinued a few weeks ago and so all my old games stopped working. I mostly used the backend for multiplayer or highscores, so i’m guessing that this is the perfect use case for lamdera.

4 Likes
3

This is so so exciting! Well done @supermario. Such an awesome tool.

2 Likes
4

I want to add that I think it’s pretty cool that you’ve included a detailed “why you shouldn’t use Lamdera” document. Some people see limitations as a weakness but I think it’s fascinating to see what kind of trade-offs are made for various technologies.

Now excuse me while I get back to making Lamdera apps :smiley:

13 Likes
5

AhhhHHh, congratulations! :tada: :tada:

2 Likes
6

@supermario I’m impressed by how little it took to add persistent high scores to the game. And it is really persistent, it’s been two months since I set that high score — it’s still there!

Looking forward to folks making multiplayer games with Elm.

3 Likes
7

dang, setting the game down now (got up to 268) :laughing: There must be like one advanced tech/route that I’m missing to get to ~300 :thinking:

2 Likes
8

Does Lamdera support PWA? In particular Create-Elm-App.

1 Like
9

Not yet! It will likely be a future addition. If you could share more details of what you need from PWAs that would be helpful :blush:

1 Like
10

From what I understood from Create-Elm-App one actually only needs to add two things to index.html (to ensure that the app is installable on Mobile)

  1. A manifest.json
  2. A service-worker.js
    From what I can tell, one can actually just copy and paste the service-worker.js from Create-Elm-App.

But I don’t actually know any details.

11

I actually meant more your own personal use case! Like what are you hoping to do, or already do, with PWAs? Is it about convenience (put it on my mobile home screen) or perhaps something combined with other offline features like local storage and asset caching? Offline mode? Something else?

12

I love to have my games as an App on my phone. Yes, that’s the reason.
Together with a service-worker that automatically updates and the evergreen system i feel like this would be great to have.

13

Hello!

Just tried out “hello world” like development with a friend. All in all we agreed it was a great developer UX already, and think you’ve done a terrific job of sewing it all together, we almost never got stuck, and there was a clear ‘this is what we should check for next’, and we just found the right thing to do. Super!

But we did gather some feedback on the small hurdles we tripped upon, here:

  1. We struggled a little with the installation on a Ubuntu 18.04 system, were the curl-command row was assuming storing the lamdera binary in /usr/local/bin or something like that. We had to change that row to specify the users’ ~/bin folder, and also do chmod +x lamdera after that.

  2. When implementing our first message from backend, the default implementation of updateFromBackend in Frontend.elm did not have a case statement, which caused us to derail from the great ‘compiler tells us what is next’-flow. We changed the implementation to have a case to get onto the flow again.

  3. We were surprised the Types.elm file contained a mix of state and message types. We both considered them different aspects of the app. The common thing between backend and frontend are the messages between backend and frontend. The other messages, in each ‘domain’, and the state types is something else (all of which could probably share some types, but that is a premature assumption). We guessed that this had something to do with the Evergreen migration system - which was a great experience to attend to!

  4. The type signature of sendToFrontend was a bit surprising. We would have guessed the message would come before the clientId. We ended up with implementing the sendToAll function reversing the parameter order:

     sendToAll : ToFrontend -> List ClientId -> Cmd a
     sendToAll message clients =
         let
             send m c =
                 sendToFrontend c m
         in
         clients
             |> List.map (send message)
             |> Cmd.batch
  1. On the commercial side of things: Both of us are a bit concerned with the closed source nature of the platform; but we agreed that if this gets popular enough, it will either get some (similar) competitor to avoid lock-in, or an open source stack implementation.

Very impressed in general!

2 Likes
14

Hey Olof – thank you for the detailed writeup! That’s really helpful. I’m thrilled you had a good experience.

15

Have you considered using something like, https://flink.apache.org/stateful-functions.html

It’d give you access to a durable, virtualized actor model in which to embed your elm code, and you wouldn’t have the hard scaling/storage limits you do now.

Other similarish alternatives:
open source:

16

Hey Max – not sure I fully understand what problem this solves? You mention “scaling/storage limits” but I’m unsure how that’s related. Is there a particular use case you’re thinking of that is done with these systems?

17

The scaling limitations I’m referring to are,

Lamdera has no external database currently. Backend persistence is directly part of the language/platform in order to strip away complexity, with a currently unknown cap on data size.

If you need sustained loads of much more than 1000/req/s, or large operational data-sets, Lamdera probably won’t work for you right now.

Lamdera as I understand it is running a single backend per customer, where that backend is effectively a durable actor, processing incoming messages in order to update some internal state, which gets persisted to disk. Correct me if I’m wrong!

This presents the following problems:

  • All persisted data must be able to fit in memory at the same time, thus storage limits.
  • Lack of scale (N=1 servers/customer) will create a bottleneck with respect to how much traffic can be served.

The above frameworks would allow you to address these problems by:

  • Providing the ability to assign multiple actors (across multiple servers) to each customer, while maintaining strong consistency guarantees. This is done by partitioning customer’s state across some keyspace, assigning actors uniquely to a partition, and then routing messages to the appropriate actor.
  • Providing “virtualized” actors, which get shunted to disk when their state doesn’t fit into memory, until the next time they are called upon.

Plus they handle a bunch of difficult problems out of the box that I’m sure you currently have to deal with e.g.

  • Changes to membership (how do you guarantee server uniqueness when one crashes and needs to be brought back online?).
  • Routing (how to make sure messages get sent to the right backend, and back to the right client?).
  • Message queuing (how do you ensure messages are not dropped when they are sent faster than the backend can handle?).
  • Actor durability (how and when do you persist the actor state to disk, in order to maximize efficiency and prevent data loss/non-determinacy).
18

Thanks for explaining Max! These are definitely interesting things to think about. I misunderstood and thought you were suggesting there was something out of the box that would improve things right now without further work.

What you’ve elaborated on is definitely in-part some of the ways I’ve been thinking about different use-cases in the future. It is some seriously non-trivial work though!

My gut feel based on my career is that there are an order of magnitude or more small scale projects than there are “web scale” or “big data” projects, and these projects are drowning in unnecessary complexity.

So “small”, “low data” and “low throughput” projects are where I’m focusing my attention right now. :blush:

For people interested from a business point of view – Egor’s plan-or-poker app I think is a perfect example of Lamdera’s current sweet spot. Non-business critical, it made something internal more efficient/pleasant, were able to build exactly what worked for them, might never have bothered doing it in a “classic stack” as half the time would have been spent on glue, and now only need to carry the Elm cost-of-ownership for maintenance/refactoring.

1 Like
19

@supermario Have you considered trialing Deno as a long term replacement to Node?

20

Hey Nick. I’ve looked at Deno, at the time it was still very experimental and didn’t have support for the bits that Lamdera needed.

I will definitely keep my eye on it, but my goal longer term is that something much more specialised/suited to Elm will replace the JS runtime. There seem to be various people/projects exploring this, so we’ll see!

1 Like